Een SPF-record maken: afzenders ordenen en DNS-query’s controleren

Als je voor een domein een SPF-record wilt maken, is het doel eenvoudig: de juiste afzenders toestaan zonder een DNS-kluwen te bouwen die een halfjaar later problemen geeft. Veel fouten beginnen hetzelfde. Je voegt een leverancier toe. Daarna nog een. Vervolgens geeft Microsoft een 550 5.7.515, Google een 550 5.7.26 en zit je om 11 uur 's avonds TXT-records uit te pluizen.

Daar zit het probleem. SPF lijkt eenvoudig, totdat het dat niet meer is. Het record van het hoofddomein wordt een verzamelbak, recursieve includes stapelen zich op en een extra DNS-afhankelijke term kan de evaluatie in PermError laten eindigen. Voor een bedrijfsdomein, klantomgeving of opzet met meerdere merken is dat geen detail. Het kan de bezorging ernstig verstoren, afhankelijk van het beleid van de ontvanger. Wil je eerst het grotere plaatje van domeinconfiguratie begrijpen, lees dan zakelijke e-mail voor kleine bedrijven.

Deze gids laat een houdbare aanpak zien: houd bedrijfsmail op het hoofddomein, scheid bulk- en applicatiemail via subdomeinen en behandel het budget voor DNS-afhankelijke SPF-termen als een eindige hulpbron. Zo maak je SPF-records die minder vaak opnieuw moeten worden ingericht. De scheiding werkt alleen als de betrokken verzendstroom het subdomein daadwerkelijk als MAIL FROM- of return-path-domein gebruikt.

Waarom zoveel SPF-records problemen geven

SPF kan misgaan doordat ontvangers tijdens de evaluatie slechts een beperkt aantal DNS-afhankelijke termen mogen verwerken. Als je te veel includes op hetzelfde domein stapelt, kan de controle die grens overschrijden en PermError opleveren. Een ontvanger kan de mail dan weigeren, ook als de syntaxis op het eerste gezicht correct lijkt.

RFC 7208 is daar duidelijk over. Tot de termen die DNS-query's uitlokken behoren include, a, mx, ptr, exists en redirect. Ontvangers moeten het aantal tijdens de evaluatie verwerkte termen van dit type begrenzen op 10, inclusief recursieve evaluaties. Het gaat niet om het totale aantal DNS-pakketten. Overschrijding levert een permanente fout op, geen waarschuwing. Volgens dezelfde RFC veroorzaken meerdere SPF-records op hetzelfde domein ook PermError; andere, niet-SPF-gerelateerde TXT-records mogen wel naast het ene SPF-record bestaan.

Daarom schiet het gebruikelijke advies tekort. Algemene handleidingen laten je alle afzenders in één TXT-waarde op @ stoppen. Dat oogt overzichtelijk, maar maakt je hoofddomein tot gedeelde infrastructuur voor nieuwsbrieven, supportsystemen, applicatiemeldingen, acquisitietools en persoonlijke mailboxen. Als een leverancier zijn include-keten uitbreidt, kan dat gevolgen hebben voor alle afzenders op dat SPF-domein.

Een kwetsbare aanpak: één SPF-record op het hoofddomein dat elke tool moet toestaan die het bedrijf ooit heeft gebruikt.

De richtlijnen van Google voor afzenders benadrukken eveneens correcte authenticatie en domeinafstemming, vooral bij bulkmail. SPF is slechts een onderdeel daarvan, maar een defect SPF-record is vaak de eerste zichtbare fout.

De echte beperking: het budget van 10 DNS-afhankelijke termen

De harde regel: bij het opstellen van een SPF-record werk je met een vast evaluatiebudget van 10 DNS-afhankelijke termen. Dat budget geldt recursief. Als een include leidt tot verdere termen die DNS-query's uitlokken, tellen die ook mee. Je DNS-provider kan een verkeerd berekend SPF-budget niet oplossen.

Deze termen tellen mee:

• include
• a
• mx
• ptr (niet gebruiken)
• exists
• redirect

Deze termen tellen niet mee:

• ip4
• ip6
• all

Let ook op lege DNS-resultaten, de zogeheten void lookups. RFC 7208 beveelt aan deze te beperken tot twee. Een typefout in het doel van een include kan een deel van die ruimte verbruiken. Het overschrijden van die aanbevolen limiet, niet het alleen bereiken ervan, kan een SPF-controle opnieuw in PermError laten eindigen.

Verstuurt een domein via vier of vijf leveranciers, dan verdient het evaluatiebudget al serieuze aandacht. Het aantal leveranciers alleen bepaalt niet of je de grens overschrijdt. Hun include-ketens en je ontwerp doen dat wel.

Een SPF-record maken met gescheiden verzendstromen

Een robuuste manier om SPF in te richten is persoonlijke bedrijfsmail te scheiden van bulk- en applicatiemail. Zet je primaire mailboxprovider op het hoofddomein en laat marketing-, support- en applicatieverzenders passende subdomeinen gebruiken voor hun MAIL FROM of return-path. Elke stroom krijgt dan een eigen SPF-budget, waardoor een probleem bij een leverancier minder snel andere stromen raakt. Alleen het zichtbare From-adres wijzigen biedt die scheiding niet.

De aanpak:

1. Hoofddomein @ voor persoonlijke bedrijfsmail.
2. Subdomeinen voor nieuwsbrieven, support, transactiemeldingen en andere gespecialiseerde verzendstromen.
3. Eén SPF-record per hostnaam. Geen dubbele SPF-records of vergeten voorgangers; andere TXT-records blijven toegestaan.

Voorbeeld voor het hoofddomein bij beheerde verzending via TrekMail:

v=spf1 include:spf.trekmail.net -all

Dat is overzichtelijk: één include en een duidelijke policy. Controleer wel de recursieve evaluatiekosten en of alle legitieme afzenders gedekt zijn.

Voorbeeld voor een marketingsubdomein:

v=spf1 include:servers.mcsv.net include:hubspot.com -all

Mailchimp en HubSpot gebruiken zo het budget van marketing.example.com, mits dat hun daadwerkelijk ingestelde SPF-verzenddomein is, en niet dat van je bedrijfsdomein. Een uitbreiding van hun infrastructuur hoeft de mailboxen op example.com dan niet te raken. Dit is een illustratie: volg voor iedere leverancier de actuele officiële instructies voor authenticatie en een aangepast MAIL FROM-domein. DMARC vereist daarnaast afgestemde SPF of DKIM; strikte en soepele afstemming behandelen subdomeinen verschillend.

Ook TrekMail kan in die opzet passen. De domeindocumentatie noemt include:spf.trekmail.net als basis voor beheerde verzending. De DNS-controle kan conflicten signaleren, maar vervangt geen volledige authenticatiecontrole. Voeg je nog mailboxen en DNS-instellingen toe, raadpleeg dan Een domein toevoegen aan TrekMail en De DNS-status controleren.

Stap voor stap: SPF-records maken zonder giswerk

Voor onderhoudbare SPF-records inventariseer je eerst alle afzenders, wijs je elke afzender het juiste verzenddomein toe en bouw je daarna pas het TXT-record. Begin niet bij DNS, maar bij de verantwoordelijkheid voor elke verzendstroom. Zo voorkom je dat willekeurige includes zich op het hoofddomein opstapelen.

Volg deze werkwijze:

1. Maak een lijst van alle diensten die namens je domein mail versturen.
2. Deel ze in als bedrijfsmail, transactiemail, support of marketing.
3. Bepaal welke hostnaam iedere afzender daadwerkelijk voor MAIL FROM gebruikt.
4. Gebruik de kleinste geldige SPF-policy die alle legitieme afzenders van die hostnaam dekt.
5. Publiceer per hostnaam één SPF-TXT-record, naast eventuele andere TXT-records.

Stel vervolgens het daadwerkelijke record samen, volgens de actuele instructies voor het ingestelde verzenddomein bij iedere leverancier.

Voorbeeld voor beheerde SMTP via TrekMail:

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net -all
TTL: 3600

Illustratief gecombineerd patroon voor TrekMail en eigen SMTP op Nano of in een hybride opzet:

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net include:amazonses.com -all
TTL: 3600

Gebruik dit gecombineerde voorbeeld niet automatisch. Sta alleen de werkelijke SMTP-provider toe voor het relevante MAIL FROM-domein en volg diens instructies voor een aangepast MAIL FROM. Nano gebruikt volgens de aangehaalde productinformatie een eigen SMTP-provider voor uitgaande mail; dat betekent niet dat zowel TrekMail als SES moet worden opgenomen. De bron noemt betaalde abonnementen vanaf $3.50 per maand met beheerde SMTP, Nano als blijvend gratis aanbod en een gratis proefperiode van 14 dagen voor betaalde abonnementen waarvoor een creditcard nodig is. Controleer de actuele voorwaarden voordat je hiervoor kiest. Zie voor de configuratie eigen SMTP (BYO) en beheerde TrekMail SMTP.

Het record publiceren en controleren

Publiceer de SPF-tekst als TXT-record en controleer daarna wat openbare DNS-resolvers teruggeven. Vertrouw niet alleen op de interface van je registrar, een gecachet dashboard of een groen vinkje in één leverancierstool. Vraag de TXT-records op en controleer dat er precies één geldig SPF-record is. De onderstaande opdrachten gebruiken doorgaans een resolver en kunnen gecachete antwoorden tonen; ze garanderen geen rechtstreekse controle bij de autoritatieve nameserver of een exact moment waarop wijzigingen overal zichtbaar zijn.

Mac of Linux:

dig txt example.com +short

Windows:

nslookup -type=txt example.com

Je wilt één SPF-waarde zien die begint met v=spf1. Geen dubbele SPF-waarden of vergeten record van een migratie van drie jaar geleden. Niet-gerelateerde TXT-records mogen er gewoon naast staan.

Snelle controles:

• Begint met v=spf1
• Eindigt met -all nadat je alle legitieme afzenders hebt geïnventariseerd en getest
• Bevat alleen de afzenders die je werkelijk gebruikt
• Heeft per hostnaam slechts één SPF-record

Bij een overstap kunnen achtergebleven MX- en SPF-records verwarring veroorzaken. De DNS-documentatie van TrekMail behandelt dit aandachtspunt. Beoordeel eerst welke records nog nodig zijn, zeker tijdens een gefaseerde migratie. Voor een bredere overstap helpen deze gidsen: e-mail maken met een eigen domein en e-mailhosting voor meerdere domeinen.

Veelvoorkomende SPF-fouten en een gerichte oplossing

Veel SPF-problemen hebben dezelfde oorzaken: te veel DNS-afhankelijke termen, meerdere SPF-records, verkeerde verzenddomeinen of typefouten in includes. Met een duidelijk overzicht van afzenders zijn die gemakkelijker te vinden. Zonder dat overzicht kan troubleshooting snel veel tijd kosten.

Twee praktische vuistregels besparen veel werk:

1. Gebruik ip4 voor vaste verzendadressen die je volledig beheert. Dat verbruikt geen DNS-afhankelijke termen.
2. Laat een marketingplatform niet hetzelfde SPF-verzenddomein gebruiken als directiemail, tenzij daar een goed onderbouwde reden voor is.

De documentatie van Google beschrijft het echte doel: authenticatie én afstemming, niet SPF op zichzelf. SPF kan slagen terwijl mail toch niet aan het beleid voldoet, als het zichtbare From-domein niet correct is afgestemd op het geauthenticeerde domein. Bij DMARC kan afgestemde SPF of DKIM voldoen; of een subdomein is afgestemd hangt mede af van de strikte of soepele modus. Lees de veelgestelde vragen over Googles richtlijnen voor e-mailafzenders bij problemen met bulkbezorging.

Wanneer TrekMail dit eenvoudiger kan maken

TrekMail kan helpen bij overzichtelijke SPF-configuraties voor meerdere domeinen. De in de bron beschreven voordelen zijn operationeel: een centrale include voor beheerde verzending, gedeelde opslag, geen facturering per gebruiker, ingebouwde IMAP-migratie en een keuze tussen eigen SMTP en beheerde SMTP, afhankelijk van abonnement en verzendmodel. Controleer de actuele mogelijkheden en voorwaarden; één include garandeert geen klein recursief SPF-budget.

Voor zelfstandige oprichters zit de winst in eenvoud: bedrijfsmail gescheiden houden, TrekMail voor mailboxhosting gebruiken en een abonnement zonder kosten per gebruiker kiezen als dat bij de actuele voorwaarden past. Teams kunnen profiteren van een uniformere onboarding en minder DNS-fouten. Voor bureaus en MSP's is het vooral een herbruikbaar patroon voor tientallen of honderden domeinen, zonder telkens de volledige mailarchitectuur opnieuw te ontwerpen.

In plaats van voor elke klant een andere kwetsbare SPF-opzet te beheren, werk je met een herhaalbare architectuur, een centraal dashboard en een gecontroleerde include voor het hoofddomein. Dat is een beter beheermodel, niet alleen een nettere TXT-waarde. Regelmatige controle blijft nodig.

Volgens het aanbod dat de bron beschrijft kun je met Nano beginnen met 10 domeinen, 5GB gedeelde opslag en eigen SMTP, zonder creditcard. Voor beheerde verzending en hogere limieten noemt de bron betaalde TrekMail-abonnementen vanaf $3.50 per maand, met een gratis proefperiode van 14 dagen waarvoor een creditcard nodig is. Bekijk de prijzen van TrekMail voor de actuele abonnementen, limieten en voorwaarden.

Conclusie: bouw een SPF-opzet die minder onderhoud vraagt

Wil je SPF-records maken die lang bruikbaar blijven, denk dan niet aan één enorme toestemmingslijst op het hoofddomein, maar aan architectuur. Het hoofddomein voor persoonlijke bedrijfsmail. Werkelijke MAIL FROM-subdomeinen voor gespecialiseerde afzenders. Zo weinig mogelijk benodigde includes. Een expliciete -all nadat alle legitieme verzendstromen zijn gecontroleerd. DNS-verificatie na publicatie, met aandacht voor caching, TTL en DMARC-afstemming.

Die aanpak helpt het evaluatiebudget te bewaken, beperkt onverwachte storingen en maakt toekomstige leverancierswissels beter beheersbaar. Ze garandeert geen onderhoudsvrije SPF-configuratie. Ben je toch je mailomgeving opnieuw aan het inrichten, bekijk dan TrekMail en kies een model dat bij je groei en actuele verzendbehoeften past.