Hoe maak ik een SPF-record aan voor een eigen domein?

Wat bevat een SPF-record?

Een SPF-record is een TXT-record dat begint met v=spf1 en doorgaat met mechanismen, elk met een optionele kwalificatie. RFC 7208 definieert de mechanismen all, include, a, mx, ip4, ip6, exists en ptr, en de modifier redirect. De kwalificatie bepaalt het resultaat wanneer een mechanisme overeenkomt: + pass (de standaard), - fail, ~ softfail en ? neutral.

Voor een domein dat een e-mailaanbieder gebruikt, doet één mechanisme bijna al het werk: include. Het vertelt de ontvanger het SPF-record van het domein van de aanbieder te evalueren en een treffer daar als een treffer voor het uwe te behandelen. U kopieert nooit met de hand IP-adressen, dus de aanbieder kan zijn servers wijzigen zonder dat u uw DNS aanraakt. Als u verzendt vanaf een eigen server, vermelden ip4 en ip6 de adressen ervan en kosten ze geen opzoeking.

SPF wordt gepubliceerd als TXT-record. Eén enkele TXT-string is beperkt tot 255 octetten, en een langer record wordt opgesplitst in meerdere strings die de ontvanger zonder spatie samenvoegt. De meeste DNS-editors doen het splitsen voor u.

Waarom mag een domein maar één SPF-record hebben?

Als twee TXT-records allebei beginnen met v=spf1, kan de ontvanger niet kiezen en geeft hij een permanente fout terug, zodat elk bericht SPF niet doorstaat. RFC 7208 stelt dat een domein niet meer dan één SPF-record mag hebben. Proton, Mailbox.org en Mailfence geven allemaal hetzelfde advies: als u een dienst toevoegt, zet u de include ervan in het record dat bestaat.

De gewone oorzaak is een overstap. U publiceert het record van de nieuwe aanbieder en vergeet het oude. Open de TXT-lijst, voeg de twee regels samen tot één en verwijder het restant. Als u definitief van aanbieder wisselt, vervang dan de oude include in plaats van eraan toe te voegen. De overstap zelf wordt beschreven in hoe u e-mail naar een nieuwe aanbieder verhuist zonder e-mail te verliezen.

Wat is de limiet van 10 opzoekingen in SPF?

SPF-evaluatie stopt met een permanente fout na 10 termen die DNS bevragen, dus een record dat er 11 nodig heeft, faalt voor elke afzender. De termen die meetellen zijn include, a, mx, ptr, exists en de modifier redirect. De mechanismen all, ip4 en ip6 tellen niet mee. RFC 7208 zegt ook dat implementaties zouden moeten stoppen na twee void-opzoekingen, die niets of een niet-bestaand domein opleveren.

Een include telt als één opzoeking plus elke opzoeking binnen het ingesloten record. Eén mailboxaanbieder is dus goedkoop, maar een stapel van een mailhost, een nieuwsbriefdienst, een helpdesk en een websiteformulier loopt op. Verwijder eerst de diensten die u niet meer gebruikt. Als een hulpmiddel vaste IP-adressen publiceert, kosten ip4- en ip6-bereiken niets. Het exacte aantal geneste opzoekingen van elke aanbieder is niet gemeten door Postelva, dus test uw uiteindelijke record met een opzoeking voordat u erop vertrouwt, zoals getoond in hoe u MX-, SPF-, DKIM- en DMARC-records controleert.

Moet ik mijn SPF-record eindigen met ~all of -all?

Gebruik ~all tenzij u elke afzender beheert: het markeert andere servers als verdacht zonder ontvangers te vragen de e-mail meteen te weigeren. De kwalificatie op all is het oordeel voor elke server die eerder met niets overeenkwam. -all betekent fail, ~all betekent softfail, ?all betekent neutral.

Een harde -all is strenger, maar RFC 9989 waarschuwt dat hij een ontvanger een bericht kan laten weigeren nog voordat DMARC draait, waardoor een doorgestuurd bericht dat DKIM had gered, verborgen blijft. Om die reden eindigt het record dat Proton en Mailbox.org tonen op ~all. Volgens de vergelijking door Postelva van 12 november 2026 gebruiken de drie aanbieders met een volledige SPF-waarde op hun helppagina's (Proton Mail, Mailbox.org, Fastmail) elk precies 1 include, dus een record voor één aanbieder kost 1 opzoeking, en twee ervan eindigen op ~all terwijl de waarde van Fastmail eindigt op ?all.

Hoe het ook eindigt, DMARC dwingt af. Stel het beleid daar in, zoals uitgelegd in de gids voor DMARC instellen. De drie records worden vergeleken in SPF versus DKIM versus DMARC.

Wat controleert SPF, en wat niet?

SPF controleert de server achter de envelope-afzender en de HELO-naam, niet het Van-adres in het bericht dat de lezer ziet. Een bericht kan SPF doorstaan voor een domein dat niemand opmerkt en toch uw domein tonen in de Van-regel. DMARC dicht die kloof door alignment tussen de twee te eisen.

SPF overleeft ook gewoon doorsturen niet, omdat een doorstuurder vanaf zijn eigen IP-adres bezorgt. Een citeerbare vuistregel: SPF autoriseert servers, één record per domein, hoogstens 10 opzoekingen. Voor een domein dat niets verzendt, publiceert u v=spf1 -all en het Postelva-sjabloon "geen e-mail"; voor een domein dat verzendt en ontvangt, DNS-sjablonen met één klik voor Proton Mail, Fastmail, Zoho Mail, Google Workspace en Microsoft 365, plus een SPF- en DMARC-sjabloon en een sjabloon "geen e-mail" voor een domeinnaam die niets verstuurt.