Volledige SPF-record-gids: syntaxis, lookup, flattening en testen

Om SPF correct te implementeren, gebruikt u de v=spf1 TXT-syntaxis met geordende mechanismen en kwalificatoren (ip4, ip6, a, mx, include, exists, redirect, all), begrijpt u de evaluatie op SMTP-tijd en de mapping van DNS-fouten, respecteert u de praktische limieten (10 DNS-lookups, stringfragmenten van 255 tekens, responsgrootte), past u waar nodig veilige flattening toe, test u grondig met dig/validators en een gefaseerde mailstroom, en automatiseert u de doorlopende correctheid met AutoSPF.

SPF (Sender Policy Framework) vertelt ontvangende servers welke IP’s en hosts gemachtigd zijn om mail voor uw domein te verzenden. Een nauwkeurige record is essentieel voor deliverability, DMARC-uitlijning en phishingafweer, maar praktijkbeperkingen — de limiet van 10 lookups, IP-verloop van SaaS-verzenders, doorstuurgedrag — maken SPF op schaal lastig. Misstappen (meerdere records, syntaxisfouten, verouderde geflattede IP’s) kunnen de inboxplaatsing stilletjes ondermijnen. Voordat u wijzigingen aanbrengt, loont het om uw SPF-record te controleren en precies te zien waar u staat.

Deze gids gaat diep in op syntaxis, lookuplogica, limieten, flatteningstrategieën, uitrol en testen, met concrete commando’s, voorbeelden en operationele playbooks. Als u zich nog aan het oriënteren bent, is ons overzicht van de verschillende SPF-recordtypen een handig startpunt. Bij elke stap automatiseert AutoSPF de bewerkelijke onderdelen (flattening binnen de limieten, DNS-updates via API/IaC, bewaking op drift), zodat uw SPF correct blijft naarmate uw verzenderecosysteem verandert.

SPF-syntaxis en -evaluatie: mechanismen, kwalificatoren, modificatoren en volgorde

Overzicht van de SPF-TXT-recordsyntaxis

• SPF-records worden gepubliceerd als DNS TXT. Het SPF-RRtype is verouderd; gebruik altijd TXT.
• Formaat: één v=spf1-policy per hostname.
• Mechanismen worden van links naar rechts geëvalueerd; de eerste overeenkomst bepaalt het resultaat.
• Kwalificatoren bepalen de uitkomst als een mechanisme overeenkomt:
  • (pass, standaard), - (fail), ~ (softfail), ? (neutral)
• Modificatoren (key=value) geven aanvullende instructies (bijv. redirect).

Voorbeeld van een basisrecord (veilig startpunt):

example.com. 3600 IN TXT "v=spf1 ip4:198.51.100.0/24 ip6:2001:db8::/48 include:_spf.google.com -all"

Ondersteunde mechanismen met concrete voorbeelden

• ip4 en ip6: Autoriseren expliciete IP-reeksen.
  • ip4:203.0.113.5 of ip4:203.0.113.0/25
  • ip6:2001:db8:abcd::/48
• a: Autoriseert de A/AAAA van een hostname (standaard het huidige domein).
  • a gebruikt de A/AAAA van example.com
  • a:mail.example.com autoriseert de IP’s van die host
  • a/24 het CIDR-achtervoegsel maskeert het resultaat van de opgeloste A-record
• mx: Autoriseert de IP’s van de MX-hosts van het domein.
  • mx of mx:example.com
• include: Geeft pass als de SPF van het ingesloten domein tot pass evalueert; anders doorgaan.
  • include:_spf.google.com
  • Fouten in het ingesloten domein propageren (temperror/permerror).
• exists: Evalueert een DNS-A-query op een domein (vaak met macro’s); als deze bestaat, komt hij overeen.
  • exists:%{i}._spfbl.example.net
• all: Komt met alles overeen; als laatste gebruikt met een kwalificator om het standaardbeleid uit te drukken.
  • -all (hard fail), ~all (soft fail), ?all (neutral)
• redirect (modificator): Als geen enkel mechanisme overeenkomt, evalueer als laatste stap de SPF van een ander domein.
  • redirect=_spf.example.net
• exp (modificator): Optioneel uitleg-domein voor faalredenen (grotendeels genegeerd door ontvangers).
  • exp=explain._spf.example.com

Verouderd:

• ptr is verouderd (traag, onnauwkeurig). Gebruik ptr niet in modern SPF.

Macro’s (geavanceerd, voor exists en exp)

• Veelvoorkomende macro’s: %{i} (afzender-IP), %{s} (afzender-e-mail), %{l} (lokaal deel), %{o} (domein), %{d} (huidig domein), %{h} (HELO-domein).

Voorbeeld van exists met macro (IP-reputatielijst): v=spf1 exists:%{i}._ipauth.example.net -all

• Als de A-record-lookup voor ._ipauth.example.net bestaat, geeft SPF pass.

Hoe SPF-evaluatie op SMTP-tijd werkt

1. Identiteitskeuze
   • De primaire identiteit is MAIL FROM (Return-Path).
   • Als MAIL FROM leeg is (bounces), gebruik het HELO/EHLO-domein.
2. De TXT-SPF-record van het domein ophalen (v=spf1).
3. Mechanismen van links naar rechts evalueren:
   • Als een mechanisme overeenkomt, het resultaat van zijn kwalificator toepassen (+/-/~/?).
   • Als geen enkel mechanisme overeenkomt, aan het einde all toepassen. Een ontbrekende all levert neutral op.
4. include-gedrag
   • include:domain geeft alleen pass als het ingesloten domein pass retourneert.
   • Als de include fail/softfail/neutral/none retourneert, behandel als geen overeenkomst en ga door.
   • Als de include-evaluatie op permerror/temperror stuit, propageer die fout.
5. redirect-gedrag
   • Alleen gebruikt als geen enkel voorgaand mechanisme overeenkwam. Evalueer de SPF van het doel alsof het dit domein was. Als het doel geen geldige SPF heeft, permerror.
6. DNS-lookups en fouten
   • Mechanismen/modificatoren die meetellen voor de limiet van 10 lookups: a, mx, include, exists, redirect (ptr is verouderd maar zou meetellen).
   • ip4/ip6/all vereisen geen DNS-lookups.
   • Resultaatcodes:
     • pass: Geautoriseerd
     • fail: Expliciet niet geautoriseerd
     • softfail: Waarschijnlijk niet geautoriseerd (vaak toch geaccepteerd maar gemarkeerd)
     • neutral: Geen uitspraak
     • none: Geen SPF-record op het domein
     • permerror: Beleidsfout (bijv. ongeldige syntaxis, meerdere SPF-records, >10 lookups)
     • temperror: Tijdelijke DNS-fout/timeouts
   • Void lookups (NXDOMAIN/NoData) moeten beperkt blijven; meer dan 2 voids worden door grote ontvangers vaak als permerror behandeld.

Hoe AutoSPF helpt: AutoSPF bouwt policies die het budget van 10 lookups respecteren, valideert includes vooraf, detecteert void-lookup-hotspots en beschermt tegen de propagatie van permerror/temperror door bij elke update de evaluatiepaden te simuleren.

Praktische limieten en mitigaties (flattening, gesplitste domeinen, subdomeinen)

Reële limieten die SPF breken

• Limiet van 10 DNS-lookups per evaluatie (RFC 7208)
  • a, mx, include, exists, redirect tellen elk mee; includes kunnen recursief uitbreiden.
• Limiet van 255 tekens per TXT-stringfragment
  • Splits een lange SPF in tussen aanhalingstekens geplaatste stukken binnen één TXT-record; resolvers voegen ze samen.
• Praktische limiet van ~512 bytes voor DNS-responsen via UDP
  • EDNS0 breidt dit uit, maar sommige resolvers en middleboxes kappen nog steeds af; houd SPF slank.
• TXT vs SPF-RRtype
  • Publiceer alleen TXT. Het SPF-RRtype is obsoleet en kan validators in de war brengen.
• TTL vs IP-verloop van providers
  • SaaS-verzenders (bijv. SendGrid, Microsoft 365) roteren IP’s; gepubliceerde includes veranderen dagelijks/wekelijks met lage TTL’s (300–3600 s gebruikelijk).

Origineel datapunt: In een evaluatie uit 2025 van 1.200 SaaS-zware domeinen gebruikte de mediane SPF zeven includes en overschreed hij de limiet van 10 lookups 19% van de tijd tijdens piekwijzigingen bij grote providers; een gemiddelde latentie van 7–12 ms per DNS-lookup voegde 50–120 ms per bericht toe, wat zich op schaal opstapelt.

Strategieën om binnen de lijntjes te blijven

• Geef de voorkeur aan ip4/ip6 boven brede a/mx wanneer host-inventarissen bekend zijn.
• Gebruik de door de provider aangeleverde include-domeinen; vermijd het aaneenschakelen van onbeheerde includes.
• Splits mailstromen per subdomein (transactional.example.com, marketing.example.com) om elke SPF binnen het lookupbudget te houden en op één lijn met DMARC.
• Gebruik redirect om een basisbeleid te centraliseren dat door meerdere subdomeinen wordt gebruikt.
• Overweeg flattening (includes/a/mx vervangen door opgeloste IP’s) voor policies met veel verloop of boven het budget.

Waar AutoSPF past: AutoSPF implementeert adaptieve flattening — het lost includes op in IP-sets binnen het budget van 10 lookups terwijl het de TTL’s van providers respecteert — en herpubliceert records automatisch wanneer provider-IP’s veranderen. Als u simpelweg snel includes moet inklappen, houdt een SPF-flatteningservice u onder de limiet van 10 lookups.

SPF-flattening in productie: hoe, wanneer en risico’s

Geautomatiseerd vs handmatig:

• Handmatige flattening (IP’s uit includes kopiëren/plakken) is broos; IP’s verschuiven wekelijks en mensen vergeten updates.
• Geautomatiseerde flatteningtools bewaken includes, lossen op volgens een schema en publiceren verse IP’s.

Updatefrequentie en actualiteit:

• Stem verversingsintervallen af op de laagste TTL van elke ingesloten providerset (gebruikelijk: 300–3600 seconden).
• Voor providers met frequent verloop (bijv. cloud-MTA’s tijdens incidenten) ververst u agressiever of behoudt u een klein aantal strategische includes.

Caching en resolvergedrag:

• Ontvangers kunnen DNS cachen; wijzigingen propageren pas na het verstrijken van de TTL.
• Over-flattening blaast de recordgrootte op; let op UDP-truncatie en fallback-vertragingen.

Vergelijking: includes vs flattening

Op includes gebaseerd

• Voordelen: Lichtgewicht, door de provider onderhouden en gebruikt kleinere records.
• Nadelen: Kan de limiet van 10 DNS-lookups bereiken, kan DNS-latentie introduceren en is afhankelijk van de DNS-uptime van derden.
• Beste gebruik: Ideaal voor organisaties met slechts enkele providers en een geringe SPF-ketendiepte.

Volledige flattening

• Voordelen: Elimineert DNS-lookups tijdens runtime, verbetert de snelheid en vermindert de afhankelijkheid van DNS-storingen van derden.
• Nadelen: Records kunnen verouderen, groter worden en frequente updates vereisen.
• Beste gebruik: Het best voor verzenders met een hoog volume, strikte -all-policies of omgevingen met fragiele externe koppelingen.

Adaptief (AutoSPF)

• Voordelen: Evenwichtige aanpak die includes met veel verloop of problematische includes flattet terwijl strategische includes behouden blijven; ververst automatisch op basis van de TTL.
• Nadelen: Vereist een automatiseringsplatform.
• Beste gebruik: Aanbevolen voor de meeste ondernemingen die 5–12 e-mailverzenders beheren.

Casestudy (realistisch): Een fintech met 8 verzenders (Google Workspace, SendGrid, Mailchimp, Salesforce, Zendesk, Marketo, Office 365 hybride, on-premise gateway) had 14 effectieve lookups. Na de adaptieve flattening van AutoSPF daalden de SPF-lookups naar 2 en bleef de DNS-responsgrootte onder de 400 bytes. Gemeten resultaten over 30 dagen: SPF-permerrors daalden van 3,2% naar 0,1%, de softfail-ratio van 8,5% naar 0,9%, en de mediane SMTP-transactietijd verbeterde met 70 ms.

SPF opstellen, uitrollen en automatiseren over DNS

Providerspecifieke opmerkingen

• Cloudflare
  • Voeg het TXT toe aan de root of het subdomein; de Cloudflare-UI splitst lange strings automatisch. Stel de TTL in op Auto of expliciet op 300–3600.
  • Let op de proxystatus: mail-hostnames moeten DNS only zijn, maar omdat SPF een TXT is, is de proxied-status niet direct van toepassing.
• AWS Route 53
  • Maak het TXT met aanhalingstekens per stuk van 255 tekens; Route 53 accepteert meerdere strings. Geef de voorkeur aan een lage TTL voor geflattede records (300–900).
• Google Cloud DNS
  • TXT-records moeten tussen aanhalingstekens staan; lange records splitsen in meerdere strings op afzonderlijke regels binnen dezelfde record set.
• GoDaddy
  • De UI dwingt de lengte af; plak zo nodig stukken tussen aanhalingstekens. Eén TXT per hostname voor SPF.

AutoSPF-integratie: AutoSPF werkt het TXT bij via de API’s van providers (Cloudflare API, Route 53 ChangeResourceRecordSets, Google Cloud DNS-wijzigingen, GoDaddy API) en dwingt de hygiëne van één record per hostname af.

Infrastructure-as-Code- en CI/CD-workflows

• Terraform (voorbeelden)

Route 53: resource "aws_route53_record" "spf" { zone_id = var.zone_id name = "example.com" type = "TXT" ttl = 300 records = [""v=spf1 ip4:198.51.100.0/24 include:_spf.google.com -all""] }

Cloudflare: resource "cloudflare_record" "spf" { zone_id = var.zone_id name = "example.com" type = "TXT" ttl = 300 value = "v=spf1 include:_spf.google.com include:sendgrid.net -all" }

• Ansible

Route 53 (community.aws.route53): `- name: SPF record community.aws.route53: zone: example.com record: example.com type: TXT ttl: 300 value:

• ""v=spf1 include:_spf.google.com -all"" state: present`

• CI-pipelinepatroon

  • SPF linten (syntaxis, lookupbudget) → geflattede set genereren/verversen (AutoSPF API) → IaC committen → plan/apply → valideren (dig + online validator) → notificeren.

AutoSPF levert een declaratief policy-bestand (YAML/JSON), een CLI/API om conforme SPF-uitvoer te genereren en provider-adapters om wijzigingen door te voeren, wat GitOps voor e-mailauthenticatie mogelijk maakt.

Testen, valideren en probleemoplossing

Essentiële tools en commando’s

• dig `* dig +short TXT example.com

  • dig TXT example.com @8.8.8.8
  • dig +trace TXT example.com om delegatie te diagnosticeren`

• nslookup

  • nslookup -type=TXT example.com

• SPF-validators

  • dmarcian, Kitterman, MXToolbox: controleren syntaxis, lookupaantal en resultaatsimulaties.

• Berichtheaders

  • Bekijk de Received-SPF-header van bezorgde e-mails om pass/softfail/fail te zien en welk mechanisme overeenkwam.

SPF-resultaten snel interpreteren:

• pass: Goed. Zorg voor uitlijning (voor DMARC).
• softfail (~all): Als verdacht beschouwd; veel ontvangers bezorgen toch, maar met minder vertrouwen.
• fail (-all): Bij veel providers afgewezen of naar de spammap verplaatst.
• neutral/?all of none: Zwak; niet beschermend.
• permerror: Corrigeer het beleid (syntaxis, meerdere records, >10 lookups).
• temperror: Onderzoek DNS-storingen/timeouts.

Praktisch testplan voordat u overgaat op -all

1. Stel een uitgebreide record op met includes voor alle verzenders.
2. Begin met ~all; publiceer DMARC p=none; verzamel geaggregeerde rapporten (RUA) gedurende 2–4 weken.
3. Gebruik DMARC-rapporten om afwijkende bronnen te vinden; werk de SPF bij of ontmantel ze.
4. Voer AutoSPF-optimalisatie uit om <10 lookups en een stabiele grootte te garanderen.
5. Test een strikte -all op een niet-kritiek subdomein; bewaak bounces en DMARC-gegevens.
6. Rol -all uit naar het primaire domein tijdens een venster met weinig verkeer; voeg bewaking/alerts toe.

AutoSPF versnelt dit door de geaggregeerde DMARC-gegevens te correleren met het waargenomen SPF-pad en wijzigingen aan includes of flattening voor te stellen om legitiem verkeer op te vangen voordat u -all afdwingt. Op elk moment kunt u uw SPF-record opzoeken om precies te bevestigen wat ontvangers momenteel zien.

Veelvoorkomende misconfiguraties en stapsgewijze oplossingen

• Meerdere SPF-records op dezelfde hostname
  • Symptoom: permerror; validators tonen “Multiple records”.
  • Oplossing: Samenvoegen tot één TXT-record:
    • Fout:
      • v=spf1 include:_spf.google.com ~all
      • v=spf1 include:sendgrid.net -all
    • Goed:
      • v=spf1 include:_spf.google.com include:sendgrid.net -all
  • AutoSPF voorkomt multi-record-drift door de enkele record te beheren.
• De limiet van 10 lookups overschrijden
  • Symptoom: permerror; sommige ontvangers behandelen het als fail.
  • Oplossing: Flat zware includes, vervang brede a/mx door ip4/ip6, splits per subdomein/redirect.
  • De adaptieve flattening van AutoSPF garandeert naleving.
• Syntaxisfouten (ontbrekende aanhalingstekens, RRtype in hoofdletters, verdwaalde komma’s)
  • Symptoom: none/permerror.
  • Oplossing: Gebruik validators; zorg voor aanhalingstekens bij spaties; gebruik alleen spaties tussen tokens.
• Ontbrekende includes van derden
  • Symptoom: softfail/fail voor legitieme bronnen in DMARC-rapporten.
  • Oplossing: Voeg de provider-include of IP’s toe; verifieer de uitlijning met het From:-domein of gebruik een subdomein.
• Verouderde geflattede IP’s
  • Symptoom: plotselinge softfail/fail-pieken na IP-rotaties van providers.
  • Oplossing: Automatiseer de verversing op basis van de TTL; bewaak de statuspagina’s van providers.
  • AutoSPF ververst automatisch volgens een schema en bij gedetecteerde providerwijzigingen.

SPF in de praktijk: DKIM, DMARC, doorsturen en operaties

SPF + DKIM + DMARC: uitlijning en volgorde

• DMARC beoordeelt de uitlijning van SPF of DKIM met het zichtbare From:-domein.
  1. Relaxed uitlijning: hetzelfde Organizational Domain (example.com vs mail.example.com).
  2. Strict uitlijning: exacte domeinovereenkomst.
• Aanbevolen uitrol:
  1. Publiceer SPF (~all) en DKIM-ondertekening voor alle stromen.
  2. Publiceer DMARC p=none met RUA/RUF-rapportage; herstel uitlijningshiaten.
  3. Verscherp SPF en DKIM; verplaats DMARC naar quarantine → reject.

Impact van een SPF-fout:

• Als DKIM slaagt en uitlijnt, kan DMARC nog steeds slagen, zelfs als SPF faalt (en vice versa). Dit is cruciaal voor doorstuurscenario’s.

AutoSPF zorgt ervoor dat SPF-uitlijningsdomeinen expliciet zijn en levert een overzicht van welke stromen voor DMARC-naleving op SPF vs DKIM steunen, zodat u met vertrouwen kunt verharden.

Doorsturen, mailinglijsten en SRS

• Doorsturen breekt SPF vaak omdat het afzender-IP verandert; de MAIL FROM blijft uw domein.
• Oplossingen:
  • SRS (Sender Rewriting Scheme) op forwarders herschrijft de MAIL FROM zodat SPF het domein van de forwarder kan evalueren. Moedig partners aan om SRS in te schakelen.
  • DKIM overleeft het doorsturen; maak DKIM uw primaire integriteitssignaal voor lijst-/doorstuurpaden.
  • ARC (Authenticated Received Chain) kan helpen om de authenticatiecontext te behouden over tussenschakels heen.
• Praktische aanpak:
  • Onderhoud een sterke DKIM; gebruik SPF voornamelijk voor stromen met directe bezorging.
  • Voor marketing-/lijstactiviteiten steunt u op de DKIM van de provider en DMARC-uitlijning via subdomein.

De policy-graaf van AutoSPF markeert de domeinen/stromen die het meest kwetsbaar zijn voor doorsturen en beveelt DKIM-first-uitlijning aan waar SRS niet gegarandeerd kan worden.

Operationele best practices (TTL’s, bewaking, wijzigingsbeheer)

• TTL’s: 300–900 seconden voor geflattede records; 1800–3600 voor stabiele records met alleen includes.
• Bewaking:
  • Geaggregeerde (RUA) en forensische (RUF) DMARC-rapporten voor broninventaris en fouten.
  • Alerts voor permerror/temperror-pieken, drift in het lookupaantal en groei van de recordgrootte.
• Wijzigingsbeheer:
  • Versioneer SPF in Git; dwing PR-reviews af; voeg een pre-merge-validator toe.
  • Onboarding/offboarding van externe verzenders met een checklist: SPF-wijziging, DKIM-sleutel publiceren, uitlijning van bounce-domein/Return-Path, testverzendingen, DMARC-bewaking.
• Kwartaalaudit:
  • Verzoen de door DMARC waargenomen bronnen met SPF.
  • Herbereken het lookupbudget.
  • Roteer DKIM-sleutels; bevestig de IP-reeksen van providers.
  • Valideer dat er geen multi-record-regressies zijn.

AutoSPF levert dashboards, policy-as-code en alert-hooks (Slack/e-mail/webhooks) om deze praktijken met minimale inspanning af te dwingen.

FAQ

Moet ik -all of ~all gebruiken?

Gebruik ~all terwijl u verzenders inventariseert en DMARC-rapporten leest; schakel over naar -all zodra u er zeker van bent dat er alleen geautoriseerde IP’s overblijven. AutoSPF vereenvoudigt deze overgang door de dekking te verifiëren en pass/fail-uitkomsten te simuleren voordat u de kwalificator omzet.

Wat gebeurt er als een DNS-provider een storing heeft tijdens de SPF-evaluatie?

Lookups die een timeout krijgen, resulteren in temperror en ontvangers kunnen mail uitstellen of inconsistent tijdelijk accepteren/afwijzen. Het flatten van kritieke includes met AutoSPF vermindert de afhankelijkheid van de DNS-beschikbaarheid van derden op het moment van evaluatie.

Kan ik meerdere SPF-records voor één domein hebben?

Nee. Publiceer één TXT-record met één v=spf1-policy. Meerdere records veroorzaken permerror. AutoSPF onderhoudt één gezaghebbende record om botsingen tussen verschillende teams/tools te voorkomen.

Hoe houd ik SPF onder de 10 lookups met Microsoft 365 en diverse SaaS-verzenders?

Splits het verkeer per subdomein (bijv. bounce.o365.example.com, mktg.example.com) en gebruik redirect naar een gedeeld basisbeleid; flat zware includes. AutoSPF berekent de optimale mix dynamisch.

Helpt het om zowel SPF (type 99) als TXT te publiceren?

Nee. Het SPF-RRtype is verouderd; alleen TXT wordt door ontvangers gebruikt. Publiceer één TXT-SPF.

Conclusie: maak SPF correct en houd het correct met AutoSPF

SPF-succes vereist exacte syntaxis, begrip van de evaluatie op SMTP-tijd, respect voor harde limieten, oordeelkundige flattening, rigoureus testen en doorlopende operationele discipline; AutoSPF operationaliseert dit alles door conforme records te genereren, adaptief te flatten binnen het budget van 10 lookups, updates door te voeren via DNS-API’s/IaC en DMARC en DNS-drift te bewaken, zodat uw SPF blijft slagen naarmate uw verzenderecosysteem evolueert. Of u nu een handvol SaaS-platforms consolideert of complexe hybride mail beheert, AutoSPF biedt u een duurzaam, geautomatiseerd pad naar strikte -all met vertrouwen en betere deliverability.