SPF stopte met werken nadat u van e-mailprovider wisselde — de migratie-oplossing (2026)

Gepubliceerd 2026-07-08

Cijfers per 2026-06-29 · methodologie v7. Geaggregeerde censusgegevens over 261 miljoen beoordeelde domeinen. Zie hoe wij beoordelen.

SPF breekt meestal na een wissel van e-mailprovider omdat het record van de nieuwe provider naast het oude werd toegevoegd. Twee v=spf1-records zijn een permanente fout — SPF wordt volledig ongeldig. 1.013.416 domeinen — ongeveer één op de 138 van de domeinen die SPF proberen — verkeren in die toestand, volgens de Defaults.Exposed-census van 261 miljoen domeinen. Voeg ze samen tot één.

De oplossing duurt ongeveer tien minuten: scan het domein om precies te zien wat de migratie heeft achtergelaten, noteer elk SPF-record bij uw autoritatieve nameservers, voeg ze samen tot één record dat alleen uw nieuwe provider bevat, en verifieer opnieuw met dig. Deze gids doorloopt elke stap, plus de DKIM- en nameservercontroles die de meeste migraties vergeten.

Waarom brak SPF direct na de migratie?

Omdat de installatiegids van de nieuwe provider zei “voeg dit TXT-record toe” — en dat deed u, naast het oude. Dat is het ene ding dat de SPF-standaard niet toestaat. RFC 7208 (§3.2, foutresultaat voorgeschreven in §4.5) staat precies één v=spf1-record per domein toe; een ontvanger die er twee of meer aantreft, moet PermError teruggeven in plaats van te raden welke autoritatief is. PermError betekent dat SPF ongeldig is: niet het oude record, niet het nieuwe, helemaal geen SPF.

En het stopt daar niet bij. DMARC behandelt een PermError als een fail voor het SPF-onderdeel, dus uw mail hangt nu volledig af van DKIM. Is de DKIM van de nieuwe provider ook nog niet ingesteld — gebruikelijk midden in een migratie — dan verstuurt u niet-geauthenticeerd precies op het moment dat u van infrastructuur wisselde, wanneer ontvangers u het strengst beoordelen.

Dit is de kopieer-plakactie die bescherming ongeldig maakt wanneer u van provider wisselt, en het is niet zeldzaam: 1.013.416 domeinen publiceren op dit moment twee of meer SPF-records — ongeveer één op de 138 van de 139 miljoen-sterke populatie die SPF probeert, volgens de Defaults.Exposed-census van 261 miljoen domeinen (gegevens per 2026-06-29). De volledige cijfers over de val van de twee records hebben hun eigen rapport; deze pagina is de procedurele oplossing.

Wat heeft de migratie achtergelaten?

Vijf achtergebleven zaken veroorzaken bijna elke SPF-storing na een migratie. Controleer ze in deze volgorde:

Wat is achtergebleven	Wat u ziet	De oplossing
Het oude SPF-record, nog steeds in DNS naast het nieuwe (twee `v=spf1`-records)	Checkers melden “meerdere SPF-records” of PermError; SPF stopt volledig met werken	Voeg samen tot één record, verwijder de rest — stappen hieronder
`include:` van de oude provider binnen uw ene record	SPF werkt, maar u verspilt DNS-lookups en de servers van de oude provider kunnen nog steeds als u versturen	Verwijder het zodra mail volledig is weggestroomd uit het oude systeem
`include:` van de nieuwe provider nooit toegevoegd	Mail van de nieuwe provider faalt SPF bij ontvangers	Voeg het toe aan het enige bestaande record — nooit als een nieuw record
DKIM-selectors niet aangemaakt voor de nieuwe provider	`dkim=fail` of handtekeningen van het standaarddomein van de provider; DMARC heeft geen tweede onderdeel	Publiceer de nieuwe selectors — stap 6 hieronder
Record alleen bijgewerkt bij de oude nameservers	Verschillende antwoorden afhankelijk van wie u vraagt; wisselvallige storingen	Herstel de zone bij de autoritatieve nameservers; verifieer beide sets tijdens de overgang

Hoe los ik het op? De migratiechecklist

Voer eerst de gratis scan uit op defaults.exposed. Die leest uw live DNS en vertelt u of u meerdere SPF-records hebt, een ontbrekende include, of een DKIM-gat — diagnosticeer voordat u iets aanraakt.
Noteer elk SPF-record bij de autoritatieve nameservers. dig +short NS yourdomain.com, en dan dig +short TXT yourdomain.com @<nameserver> tegen één daarvan. Tel de regels die met v=spf1 beginnen. Het enige veilige aantal is 1.
Voeg samen tot één record. Eén record, beginnend met v=spf1, met de include van uw nieuwe provider en elke andere afzender die u nog gebruikt (facturatietool, CRM, nieuwsbriefplatform), en één afsluitend -all of ~all. Voorbeeld — oud Google Workspace, nieuw Microsoft 365, midden in het leegstromen:
```
Before:  "v=spf1 include:_spf.google.com ~all"
         "v=spf1 include:spf.protection.outlook.com -all"

After:   "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
Later:   "v=spf1 include:spf.protection.outlook.com -all"
```
Providerwaarden en DNS-paneeleigenaardigheden staan in de installatiegidsen voor Google Workspace en Microsoft 365.
Verwijder de extra records. Samenvoegen zonder verwijderen lost niets op — de PermError komt van het aantal.
Behoud de include van de oude provider alleen zolang het oude systeem nog verstuurt — geplande rapporten, een oude CRM-connector, een vergeten postvak. Zodra het leegstromen klaar is, verwijder het: een verouderde include laat de oude infrastructuur nog toe als u te versturen, en elke include kost DNS-lookups tegen SPF’s harde limiet van 10 — minstens 797.263 domeinen hebben SPF ongeldig gemaakt door dat plafond te doorbreken (census, 2026-06-29).
Stel de DKIM van de nieuwe provider in — en verwijder de oude selectors nog niet. Nieuwe selectors ondertekenen nieuwe mail; oude selectors moeten gepubliceerd blijven totdat elk bericht dat ermee is ondertekend, is afgeleverd en eventuele doorstuurregels zijn afgehandeld. Volledige handleiding in DKIM faalt na het wisselen van e-mailtools.
Wisselde u ook van nameservers, controleer dan beide. DNS-migraties lopen vaak mee met e-mailmigraties. Vraag de oude en de nieuwe NS-set rechtstreeks op (dig TXT yourdomain.com @old-ns en @new-ns) — totdat de registrardelegatie volledig is doorgevoerd, vragen sommige ontvangers nog steeds de oude servers, dus het gerepareerde record moet bestaan bij welke set ook antwoordt.
Voer de scan opnieuw uit en bevestig dat SPF een enkel geldig record toont met een pass.

Welk domein controleert SPF eigenlijk?

Ontvangers evalueren SPF tegen het Return-Path-domein (RFC5321.MailFrom) — het bounce-adres — niet de From-header die uw ontvangers zien. Na een migratie is dit dubbel belangrijk: uw nieuwe provider gebruikt mogelijk zijn eigen bounce-domein totdat u een aangepast domein configureert, en SPF dat “slaagt” op een domein dat niet van u is, doet niets voor DMARC-alignment. De oplossing daarvoor is de DKIM van de nieuwe provider, ondertekend met uw domein.

Migreert u en herbrandt u tegelijk?

Ook het domein veranderd, naast de provider? Behandel het als twee klussen. Het nieuwe domein heeft de volledige stack nodig — SPF, DKIM, DMARC — vanaf dag één; gebruik de checklist voor nieuwe-domein-e-mail. Het oude domein blijft geauthenticeerd zolang doorstuur- of antwoordverkeer erdoorheen loopt, en wordt expliciet afgesloten (niet zomaar verlaten) zodra het geparkeerd is. Een oud domein met achtergebleven, half-kapotte SPF is een spoofingdoelwit dat uw oude naam draagt.

Veelgestelde vragen

Kan ik twee SPF-records behouden terwijl ik migreer? Nee. Er is geen coulanceperiode in de standaard — twee v=spf1-records vormen een PermError vanaf het moment dat het tweede bestaat, en 1.013.416 domeinen bevinden zich in die toestand volgens de census (2026-06-29). Het migratieveilige patroon is één record met de includes van beide providers tijdens de overlap.

Hoe lang moet ik de include van de oude provider behouden? Totdat er niets meer via de oude provider verstuurt — meestal de lengte van uw overlapvenster, dagen tot een paar weken. Houd het Return-Path in de gaten van alles wat nog via het oude systeem binnenkomt; stopt dat verkeer, verwijder dan de include en controleer opnieuw uw lookup-aantal.

Waarom toont een checker nog mijn oude record nadat ik het gerepareerd heb? DNS-caching respecteert de TTL van het record, en als uw nameservers zijn gewijzigd, vragen sommige resolvers nog steeds de oude set. Verifieer rechtstreeks bij de autoritatieve nameservers met dig TXT yourdomain.com @<ns> — staat het antwoord daar goed, dan is de oplossing klaar en trekken de caches bij. Is het bij één NS-set fout, zie dan ‘SPF record not found’ — de echte oorzaken.

Moet ik DMARC wijzigen als ik van provider wissel? Meestal niet het record zelf — het noemt uw rapportagepostvak en beleid, niet uw provider. Maar uw DMARC-resultaten hangen af van de SPF en DKIM die u net hebt gemigreerd: verwacht een dip in rapporten tijdens de overgang, en bevestig dat beide onderdelen slagen voordat u het beleid aanscherpt. Begin bij repareer SPF als de scan toont dat het SPF-onderdeel nog faalt.

Stuur de eigenaar het rapport

Doet u deze migratie voor een klant, rond het dan af met bewijs. Voer de gratis scan opnieuw uit zodra de samenvoeging live is en stuur het beoordeelde rapport door naar de bedrijfseigenaar: SPF, DKIM en DMARC geslaagd bij de nieuwe provider, in gewone taal, gedateerd. Dat is het bewijsstuk dat ze indienen bij de cyberverzekeringsverlenging en de volgende beveiligingsvragenlijst van een leverancier — bewijs dat de migratie het domein beter geauthenticeerd achterliet dan het begon.

Controleer uw domein → · DKIM faalt na het wisselen van e-mailtools → · ‘SPF record not found’ — de echte oorzaken → · Hoe wij beoordelen → · Uitsluitend geaggregeerde gegevens. Gegevens opgeslagen en verwerkt in de EU.