SPF-record te veel lookups: zo los je de limiet van 10 lookups op

Een SPF-record (Sender Policy Framework) dat "too many DNS lookups" teruggeeft, zit boven het plafond van 10 lookups uit RFC 7208. Ontvangende mailservers beschouwen dan het hele record als kapot, niet alleen het deel boven de limiet. De oplossing is je include:-mechanismen te flattenen of samen te voegen, zodat het totale aantal lookups weer onder de 10 komt, zonder dat er ongemerkt een verzendbron verdwijnt.

Waarom de SPF-limiet van 10 lookups bestaat

RFC 7208 §4.6.4 beperkt de SPF-evaluatie tot 10 DNS-lookups per controle, en elk record dat er meer nodig heeft, moet een permerror teruggeven. Dat is geen vrijblijvende waarschuwing. Een permerror betekent dat het ontvangende systeem je beleid niet betrouwbaar kan bepalen en daarom terugvalt op lokale regels. In de praktijk belandt het bericht dan vaak in de spam of wordt het direct geweigerd.

De mechanismen en modifiers die meetellen voor het budget van 10 lookups zijn:

• include
• a
• mx
• ptr
• exists
• redirect

Mechanismen die niet meetellen, omdat ze zonder DNS-query worden afgehandeld:

• ip4
• ip6
• all

Dat onderscheid is de hele basis van "flattening": je vervangt mechanismen die een lookup vereisen door de IP-ranges waar ze uiteindelijk naar verwijzen. Het aantal lookups daalt dan, terwijl er niets verandert aan wat er daadwerkelijk geautoriseerd is.

Waarom records zo makkelijk over de limiet gaan

De meeste domeinen komen hier niet terecht door bewust tien verzenddiensten toe te voegen. Een handvol gangbare integraties is al genoeg:

• Google Workspace of Microsoft 365 voor de primaire mail
• Een helpdesktool (Zendesk, Freshdesk) voor supportantwoorden
• Een marketingplatform (Mailchimp, HubSpot) voor campagnes
• Een transactionele verzender (SendGrid, Mailgun, Postmark) voor app-e-mails
• Een CRM- of e-signingtool die ook namens jou verstuurt

Elk daarvan wordt meestal als één include: toegevoegd, maar veel grote providers nesten hun eigen includes meerdere lagen diep. Drie of vier populaire diensten toevoegen kan op zichzelf al gemakkelijk 8-10 lookups opleveren, zeker als je geneste include-ketens en eventuele mx- of a-mechanismen meetelt.

WarningEen record kan er in een teksteditor prima uitzien en in productie toch falen, omdat de telling van 10 lookups elke recursief opgeloste geneste include meetelt, niet alleen de includes die zichtbaar zijn in je eigen TXT-record.

Daarnaast is er een aparte limiet van 2 void lookups: een void lookup is elke query die NXDOMAIN of geen antwoord teruggeeft. Verouderde of verkeerd gespelde include:-doelen van een dienst die je niet meer gebruikt, kunnen deze limiet overschrijden, zelfs als je zichtbare aantal lookups onder de 10 lijkt te liggen.

Zo controleer je je huidige aantal SPF-lookups

Begin met het opvragen van het ruwe record en loop elke include: handmatig na, of haal het door onze gratis SPF-generator. Die valideert een record en markeert mechanismen die het over de limiet duwen. Je kunt de onderliggende DNS ook inspecteren met onze DNS-lookuptool om precies te zien waar elke include: naar verwijst voordat je beslist wat je gaat flattenen.

Een record dat op problemen afstevent, ziet er vaak zo uit:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net include:sendgrid.net include:mailgun.org include:helpscoutemail.com ~all

Zes include:-mechanismen die elk mogelijk nog meer includes bevatten: een realistische manier om met maar een handvol diensten ruim over de 10 lookups te gaan.

SPF flattenen: includes vervangen door IP-ranges

Flattenen betekent dat je elke include: herleidt tot de ip4/ip6-ranges waar die op dit moment naar verwijst, en die vervolgens hard in je record zet met ip4:/ip6:-mechanismen in plaats van include:. Omdat IP-mechanismen gratis zijn (ze tellen niet mee voor de limiet), kan een record met een tiental IP-ranges nog steeds ruim onder de 10 lookups blijven.

v=spf1 ip4:198.51.100.0/24 ip4:203.0.113.10 ip6:2001:db8::/32 include:_spf.google.com ~all

Hier worden de minder belangrijke verzenders geflattend naar IP-adressen en blijft alleen de provider met de meeste wijzigingen (in dit voorbeeld Google) als live include: staan. Providers wisselen namelijk hun verzendranges, en een volledig geflattend record moet je bij elke wijziging handmatig bijwerken.

TipFlatten de providers die hun IP-ranges zelden wijzigen, en laat de providers die vaak wisselen (grote ESP's, cloudmailplatforms) als include:-mechanismen staan. Zo houd je het aantal lookups en de onderhoudslast in balans.

Opschonen in plaats van flattenen

Voelt flattenen te kwetsbaar om door je team te laten onderhouden? Schoon dan eerst op:

• Verwijder include:-regels voor diensten waarmee je niet meer verstuurt.
• Voeg dubbele mechanismen samen: twee include:-statements die naar dezelfde onderliggende provider wijzen, tellen snel op.
• Controleer of een dienst één smallere SPF-include aanbiedt in plaats van de standaardinclude die ook ongerelateerde infrastructuur binnenhaalt.
• Controleer of je niet meer dan één SPF-TXT-record op het domein hebt: RFC 7208 §3.2 vereist er precies één, en twee records veroorzaken ook een permerror, los van het aantal lookups.

Een redirect-modifier kan een volledig record vervangen door het beleid van een ander domein, maar volgens RFC 7208 §6.1 hoort die alleen te worden gebruikt als er geen andere mechanismen in dat record staan. Als je redirect combineert met je eigen include:/all-mechanismen, wordt de evaluatie onvoorspelbaar.

Wat er gebeurt als je het negeert

Een permerror is niet neutraal: de meeste ontvangers passen daar hun lokale beleid op toe. En omdat DMARC-alignment afhangt van een geslaagde SPF-controle, breekt een kapot SPF-record vaak ook de DMARC-alignment, zelfs als DKIM nog klopt. Die combinatie is een veelvoorkomende, onopvallende oorzaak van mail die in de spam belandt. Ben je deliverability breder aan het onderzoeken, lees dan waarom je e-mails in de spam terechtkomen voor het totaalbeeld, verder dan alleen SPF.

Snel overzicht: wat telt mee voor de SPF-limiet

Houd je record in de gaten zodra het gerepareerd is: SPF-drift sluipt er weer in telkens wanneer een team een nieuwe verzendtool toevoegt zonder het bestaande budget te controleren. Beheer je DNS bij meerdere registrars en providers, dan bieden onze tools voor DNS-beheer je één plek om elk record te bekijken en te bewerken voordat het ongemerkt je maillevering breekt.