Wat is een spf record? Syntaxis, limieten en storingen

Een spf record is een enkele DNS TXT-record op je domein die vastlegt welke servers mail mogen versturen met dat domein als envelopafzender. Een ontvangende server leest die record, vergelijkt het IP-adres van de verbinding met de lijst en geeft een resultaat terug: pass, fail, softfail of neutral. Een spf record controleert het verzendpad, niet het bericht zelf, en zegt niets over het From-adres dat de ontvanger te zien krijgt. Dat onderscheid verklaart het grootste deel van de SPF-tickets die we in traces tegenkomen.

Een spf record is een toegangslijst van verzenders, in DNS

SPF staat voor Sender Policy Framework en is beschreven in RFC 7208. De record is een TXT-entry op het root van het domein die begint met v=spf1. Een minimale variant ziet er zo uit:

example.com.  IN  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.provider.example ~all"

Lees hem van links naar rechts. De ontvanger controleert elke term in volgorde en stopt bij de eerste match. De laatste term all vangt alles op wat eerder niet paste.

Het gecontroleerde domein is niet het From-veld. Het is het domein in het SMTP-commando MAIL FROM, ook envelopafzender of Return-Path genoemd. Is die leeg, zoals bij bounces, dan valt de ontvanger terug op de HELO-naam.

Elke term is een mechanisme, optioneel voorafgegaan door een kwalificatie. Zes mechanismen dekken bijna elke echte record:

• ip4: / ip6: matchen een vast adres of CIDR-bereik. Ze kosten geen lookups.

• a matcht de A- of AAAA-records van een domein. Dat kost één lookup.

• mx matcht de hosts in de MX-records van het domein. Dat kost één lookup plus één per host.

• include: matcht wat de SPF-record van een ander domein matcht. Dat kost één lookup plus alles wat daarin genest zit.

• exists: matcht een A-record voor een samengestelde naam. Dat kost één lookup.

• ptr matcht op de reverse DNS van het verbonden IP. Dat kost lookups, en RFC 7208 raadt het af.

Kwalificaties bepalen het resultaat bij een match. + is pass en is de standaard, - is fail, ~ is softfail en ? is neutral. -all betekent dus "wijs alles af wat niet vermeld staat", en ~all betekent "accepteer, maar markeer".

Gebruik ip4: en ip6: waar je het adres zelf beheert. Ze kosten nul lookups en kunnen niet breken wanneer de DNS van een ander verandert.

De limiet van 10 DNS-lookups breekt echte records

RFC 7208 begrenst één SPF-evaluatie tot 10 termen die een DNS-query veroorzaken: include, a, mx, ptr, exists en de modifier redirect. Geneste includes tellen mee. Boven de 10 is het resultaat permerror, en de controle faalt definitief in plaats van terug te vallen.

Er is een tweede limiet die minder aandacht krijgt. Termen die een leeg antwoord of NXDOMAIN geven, heten void lookups, en de specificatie stopt bij twee. Een verouderde include: naar een leverancier die je vorig jaar hebt uitgeschakeld, is een void lookup waarvoor je nog steeds betaalt.

Zo raken teams het plafond in de praktijk. Google Workspace telt voor één include. Een transactionele provider telt voor één. Een marketingplatform telt voor één en nest er drie in. Een helpdesk, een CRM en een factuurtool voegen er nog vier toe. Dan zit je op 11, zonder iets bijzonders te hebben gedaan.

De fout is stil. Mail wordt nog steeds verzonden, en sommige ontvangers leveren het nog af, maar SPF authenticeert dan niets meer voor je. Als je op DMARC-alignment via SPF vertrouwt, is die route weg zolang je de record niet afvlakt of verzenders verwijdert.

Er zijn drie oplossingen, in volgorde van voorkeur:

1. Verwijder verzenders die je niet meer gebruikt. Controleer de includes tegen je DMARC-aggregaterapporten van de laatste 90 dagen.

2. Verplaats bulkverkeer naar een subdomein zoals mail.example.com, met een eigen SPF-record en een eigen budget van 10 lookups.

3. Vlak includes af naar vaste ip4:-bereiken, maar alleen met automatisering. Leveranciers roteren hun IP's, en een met de hand afgevlakte record veroudert zonder dat je een alarm krijgt.

Publiceer precies een spf record per domein

Een domein mag niet twee SPF-records publiceren. Vindt een ontvanger twee v=spf1-TXT-entries, dan is het resultaat permerror, net als bij de lookup-limiet. Dit gebeurt wanneer iemand een record toevoegt voor een nieuw hulpmiddel terwijl er al een staat.

De oplossing is mechanisch. Voeg de termen samen in één record, met één v=spf1 aan het begin en één all aan het eind. Alles wat de documentatie van een leverancier je vraagt toe te voegen, komt als extra include: in de bestaande record, nooit als nieuwe TXT-entry.

Twee kleinere valkuilen. Een TXT-string van meer dan 255 tekens moet je splitsen in meerdere quoted strings binnen dezelfde record, wat de meeste DNS-providers voor je doen. En houd het hele antwoord waar mogelijk onder ongeveer 450 bytes, want grotere antwoorden kunnen van UDP naar TCP terugvallen, en sommige resolvers verwerken dat slecht.

Softfail of hardfail: kies op basis van wat je ziet

Het all-mechanisme is een beleidsverklaring, en het standaardadvies ("gebruik -all") slaat het deel over dat ertoe doet. Een hard fail is alleen veilig als je elke legitieme verzender kent.

Onze vuistregel na het lezen van traces:

• ~all zolang je verzenders nog aan het inventariseren bent, of als je mail doorstuurt en het pad niet kunt beheersen.

• -all zodra DMARC-rapporten een paar weken laten zien dat elke legitieme bron slaagt.

• Nooit +all, want dat autoriseert het hele internet, en nooit ?all op een productiedomein.

In de praktijk is het verschil kleiner dan veel mensen verwachten. De meeste grote ontvangers zien SPF als één signaal naast andere, en met een DMARC-beleid bepaalt het DMARC-oordeel de uitkomst. Toch is een -all op een onvolledige record de manier waarop je facturen kwijtraakt.

SPF breekt bij doorsturen, en dat is bewust zo

SPF controleert het IP-adres dat verbinding maakte met de ontvangende server. Wordt een bericht doorgestuurd, via een mailinglijst verspreid of door een aliasdienst gerelayd, dan is het verbonden IP dat van de doorstuurder, niet het jouwe. De SPF-controle faalt, ook al heb je niets verkeerd gedaan.

Dat los je binnen SPF niet op. Daarom bestaat DKIM naast SPF: een handtekening reist mee met de hop, een IP-lijst niet. Een domein dat alleen op SPF leunt, ziet authenticatiefouten bij elk doorgestuurd bericht. Daarom voldoet SPF alleen ook niet aan DMARC voor doorgestuurde mail. Reken erop dat DKIM die berichten draagt.

Alignment is de volgende valkuil. Een bericht kan SPF passeren en toch DMARC laten falen. DMARC vereist dat het domein dat SPF passeerde, het Return-Path-domein, overeenkomt met het zichtbare From-domein. Veel gedeelde providers gebruiken standaard hun eigen bounce-domein, dus SPF slaagt voor provider-mail.net en zegt niets over example.com.

Controleer dit in de ruwe headers. Kijk in de regel Authentication-Results naar smtp.mailfrom=. Staat daar niet jouw domein of een subdomein ervan, dan slaagt SPF zonder dat het je helpt.

De oplossing is een eigen Return-Path op een subdomein van jezelf, wat de meeste serieuze verzenders ondersteunen. Postmark, Resend, Mailgun en SendGrid documenteren allemaal deze opzet, al staat ze niet altijd standaard aan.

Inbox-providers verwachten authenticatie van elke verzender

Sinds februari 2024 vereist Google dat alle verzenders authenticeren met SPF of DKIM, en verzenders van meer dan 5.000 berichten per dag naar Gmail moeten SPF, DKIM en DMARC hebben ingesteld. De details staan in de richtlijnen van Google voor e-mailafzenders. Yahoo hanteert sinds dezelfde periode vergelijkbare regels.

Daarmee is SPF van "fijn om te hebben" een voorwaarde voor aflevering geworden. Een ontbrekende of kapotte record toont zich nu als afwijzingen en spamplaatsing, niet alleen als een lagere reputatiescore.

Onze lezing na een paar jaar traces: de regels vangen vooral domeinen zonder enige authenticatie en verzenders met hoge klachtpercentages. Een correcte spf record alleen brengt je niet in de inbox, maar een ontbrekende houdt je erbuiten.

Zo controleer en repareer je een spf record in vier stappen

Doe dit in volgorde en controleer na elke DNS-wijziging opnieuw.

1. Haal de huidige record op. Draai dig +short TXT example.com en zoek de regel die begint met v=spf1. Staan er twee, voeg ze samen.

2. Tel de lookups. Tel include, a, mx, exists, redirect en alles wat in de includes genest zit. Zit je op 8 of hoger, plan dan nu de opschoning, niet pas bij de elfde.

3. Maak een lijst van echte verzenders. Gebruik DMARC-aggregaterapporten of Authentication-Results-headers van testverzendingen. Voeg alleen de bronnen toe die daar verschijnen.

4. Stuur een test en lees de header. Het resultaat moet spf=pass zijn, met smtp.mailfrom op je eigen domein.

DNS-wijzigingen hebben tijd nodig om door te werken, en de TTL van je huidige record bepaalt hoe lang oude antwoorden blijven hangen. Verlaag de TTL een dag vóór een geplande wijziging naar 300 seconden.

Een werkend voorbeeld voor een saas-bedrijf met drie verzenders

Neem een product dat verstuurt via Google Workspace, een transactionele provider en een helpdesk. Een schone record ziet er zo uit:

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:spf.transactional.example include:spf.helpdesk.example -all"

Dat zijn drie includes, en elke include verbergt zijn eigen geneste lookups. Tel ze voordat je publiceert, want de zichtbare lengte zegt niets over het echte budget. Een record met drie includes kan al op 7 of 8 lookups zitten.

Splits daarom op doel. Houd menselijke mail op het root-domein. Zet productnotificaties op notify.example.com, met een record die alleen de transactionele provider noemt. De root-record blijft kort, het subdomein krijgt een eigen budget van 10 lookups, en een reputatieprobleem op de ene stroom sleept de andere niet mee.

Die splitsing maakt de DMARC-rapporten ook leesbaar. Elke stroom heeft een eigen Return-Path-domein, dus een fout wijst naar één verzender in plaats van naar een stapel.

Wat SPF niet doet

SPF voorkomt niet dat iemand je From-adres vervalst, want het kijkt nooit naar die header. Het versleutelt niets. Het vertelt je ook niet waarom een bericht in de spam belandde. En het schaalt niet voorbij het budget van 10 lookups zonder doorlopend onderhoud.

Behandel het als een van de drie records die je samen publiceert: SPF voor het verzendpad, DKIM voor de integriteit van het bericht, DMARC voor het beleid dat ze koppelt aan je From-domein. Heb je alleen SPF en niets anders, dan is de volgende concrete stap een DMARC-record op p=none en twee weken lang de rapporten lezen.