Defaults.Exposed › Oplossingen › Guides

"SPF Record Not Found" — maar u hébt er een? De 5 echte oorzaken (2026)

Gepubliceerd 2026-07-08

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

Als een checker “SPF record not found” meldt maar u zeker weet dat u er een hebt gepubliceerd, is het record meestal onzichtbaar in plaats van afwezig: 1.013.416 domeinen — ongeveer één op de 138 van de domeinen die SPF proberen — publiceren twee of meer SPF-records, een PermError (RFC 7208 §3.2) die veel checkers als niet-gevonden rapporteren, volgens de Defaults.Exposed-census van 261 miljoen domeinen.

Er zijn vijf echte oorzaken, allemaal in één zitting op te lossen: verkeerde host, dubbel record, verkeerd DNS-type of verhaspelde aanhalingstekens, inconsistente nameservers, of een lengte-/CNAME-conflict. Hieronder: de 60-secondentest voor elk, in de volgorde waarin u ze moet nalopen, en daarna de stappen om het op te lossen.

Weet u zeker dat het record echt bestaat?

Begin met de weinig vleiende mogelijkheid, want die is veruit de meest voorkomende: van de 261.086.232 domeinen die in de Defaults.Exposed-census zijn beoordeeld, hebben 121.145.609 — 46,4% — helemaal geen SPF-record. Heel wat gevallen van “maar ik heb dit echt ingesteld” blijken een record te zijn dat is toegevoegd aan een staging-zone of aan een oude DNS-provider die niet langer autoritatief is. Controleer bij de DNS-provider waar uw nameservers daadwerkelijk naar verwijzen (vaak niet uw registrar) op een TXT-record dat begint met v=spf1. Staat het er echt niet, sla het speurwerk dan over en ga rechtstreeks naar repareer uw SPF-record.

Hoe controleert u een SPF-record op de juiste manier?

Webcheckers vragen DNS op via hun eigen cachende resolver. Wilt u de waarheid zien, vraag dan de autoritatieve nameserver van uw domein rechtstreeks:

# find the authoritative nameservers
dig NS yourdomain.com +short

# ask one of them directly for TXT records
dig TXT yourdomain.com @ns1.yourdnshost.com +short

Op Windows: nslookup -type=TXT yourdomain.com ns1.yourdnshost.com.

Twee interpretatieregels. Tel ten eerste de regels die met v=spf1 beginnen — het aantal telt net zo zwaar als de inhoud. Controleer ten tweede of u de juiste naam hebt opgevraagd: ontvangende mailservers evalueren SPF tegen het domein in de Return-Path (RFC5321.MailFrom, de “envelope from”) — niet het From-adres dat ontvangers te zien krijgen. Als uw nieuwsbrieftool mail laat bouncen via bounce.yourdomain.com, is een perfect record op de apex niet het record dat ontvangende servers opzoeken.

Wat zijn de vijf echte oorzaken?

Gegevens per 2026-06-29.

1. Staat het record op de verkeerde host?

De klassieker: SPF toegevoegd op mail.yourdomain.com terwijl de mail claimt van yourdomain.com te komen, of andersom. SPF erft niet naar beneden over — een record op de apex zegt niets over subdomeinen, en andersom. Publiceer op exact de naam in uw Return-Path. Een leverancier die verzendt vanaf een eigen bounce-subdomein heeft een record op dát subdomein nodig — meestal een CNAME of TXT die de leverancier aanlevert (de GoDaddy SPF-installatiegids laat zien waar deze velden staan).

2. Hebt u twee SPF-records?

De hoofdoorzaak, en de meest misleidende foutmelding in e-mailauthenticatie. RFC 7208 §3.2 is onverbiddelijk: een domein moet precies één SPF-record hebben. Twee of meer is een PermError — ontvangende servers behandelen uw SPF als ongeldig. Sommige checkers rapporteren die toestand accuraat (“multiple records found”); andere rapporteren het netto-effect: no valid SPF record found. U ziet een record in uw beheerpaneel en concludeert dat de checker kapot is. Dat is hij niet — u hebt één record te veel.

De census vond 1.013.416 domeinen met twee of meer SPF-records — ongeveer één op de 138 van de domeinen die SPF proberen — en bij elk daarvan staat SPF effectief uit. Het gebeurt meestal tijdens een providerwissel: de wizard van de nieuwe provider voegt een vers record toe in plaats van het oude te bewerken. De oplossing is samenvoegen, nooit een tweede record: combineer alles tot één regel v=spf1 … ~all en verwijder de rest. Ons datarapport twee SPF-records is hetzelfde als geen legt uit hoe een miljoen domeinen hier zijn beland; begon het na een migratie, zie dan SPF werkt niet meer na wisselen van provider. Plak bij het samenvoegen niet blind elke include: aan elkaar — elke include kost DNS-lookups tegen de harde limiet van 10 van SPF, waarmee u niet-gevonden inruilt voor een PermError: too many DNS lookups.

3. Hebt u het verkeerde recordtype gepubliceerd — of heeft de interface het verhaspeld?

Vroege SPF had een eigen DNS-recordtype (type 99, letterlijk “SPF” genaamd). Het is afgeschaft: RFC 7208 vereist TXT, en ontvangende servers vragen type 99 niet op. Sommige DNS-panelen bieden “SPF” nog aan in het keuzemenu voor recordtypes; kiest u dat, dan is uw record echt, correct gevormd en onzichtbaar. Controleer de typekolom en publiceer opnieuw als TXT.

Het subtielere broertje zijn de aanhalingstekens. Een waarde die al tussen aanhalingstekens staat plakken in een veld dat zelf aanhalingstekens toevoegt, levert ""v=spf1 …"" op — en dat begint niet meer met v=spf1, dus voor een verifier bestaat het niet. Uw dig-uitvoer toont de waarheid; het DNS-paneel verbergt het vaak cosmetisch.

4. Is het echt “nog aan het propageren”?

“Geef het 24–48 uur om te propageren” is het meest overbodig voorgeschreven advies in DNS. Propagatie is niets meer dan caches die verlopen: zodra de TTL van het record is verstreken (doorgaans 1 uur, zelden meer dan 24), kan elke resolver het nieuwe antwoord zien. Na 24 uur nog steeds niet gevonden? Dan is propagatie niet de oorzaak.

De twee echte boosdoeners: negative caching — een resolver die u opzocht voordat u het record toevoegde, cachet het antwoord “no such record” totdat de negatieve TTL verloopt — en inconsistente nameservers na een migratie, waarbij het domein nog de nameservers van de oude provider naast de nieuwe vermeldt en de halve wereld een zone leest die u niet meer bewerkt. Vraag elke vermelde nameserver rechtstreeks op; verschillen de antwoorden, dan hebt u het gevonden. Corrigeer de NS-delegatie bij de registrar zodat alleen de provider die u daadwerkelijk bewerkt autoritatief is.

5. Is het record te lang, of geblokkeerd door een CNAME?

Eén string in een TXT-record is maximaal 255 tekens lang. Langere SPF-records zijn toegestaan, maar moeten worden opgesplitst in meerdere strings tussen aanhalingstekens binnen één record — en de interfaces van DNS-providers verprutsen die splitsing regelmatig, waardoor de waarde wordt afgekapt of midden in een mechanisme breekt en niet meer te parsen is. Is uw record lang, kijk dan in de dig-uitvoer naar een waarde die abrupt eindigt.

Los daarvan verbiedt DNS een TXT-record op een naam waar al een CNAME staat. Is mail.yourdomain.com een CNAME naar uw provider, dan kunt u daar niet óók SPF plaatsen — sommige panelen accepteren het en serveren vervolgens alleen de CNAME. Zet het record waar de CNAME naartoe wijst (als u daar controle over hebt), of herstructureer zodat de verzendende naam geen CNAME heeft. Providers met nette TXT-afhandeling maken beide makkelijker — zie de Cloudflare SPF-installatiegids.

Hoe lost u het op, stap voor stap?

1. Voer de gratis scan uit op defaults.exposed — die leest uw live DNS en vertelt u in welke van de vijf situaties u zit voordat u iets aanraakt.
2. Controleer welke nameservers autoritatief zijn (dig NS) en of ze allemaal hetzelfde antwoorden.
3. Vraag TXT op bij de autoritatieve nameserver voor exact het Return-Path-domein.
4. Tel de v=spf1-regels: nul → publiceer er één; twee of meer → voeg samen tot één.
5. Controleer of het type TXT is, of de waarde exact met v=spf1 begint en of er geen losse aanhalingstekens of afkapping in geslopen zijn.
6. Wacht één TTL uit en scan daarna opnieuw om te bevestigen dat het overal netjes wordt gevonden.

Veelgestelde vragen

Waarom zegt de checker “not found” terwijl ik het record in mijn DNS-paneel zie staan? Meestal oorzaak 2 of 4: een tweede v=spf1-record maakt beide ongeldig — een PermError die sommige tools als niet-gevonden rapporteren, de toestand waarin 1.013.416 domeinen zich bevinden per 2026-06-29 — of uw paneel is niet de DNS die daadwerkelijk autoritatief is.

Hoe lang duurt het voordat checkers mijn fix zien? Eén TTL — doorgaans een uur, hooguit 24. Daarna is “propagatie” niet de verklaring; loop de vijf oorzaken opnieuw na, te beginnen met de consistentie van de nameservers.

Moet ik het recordtype “SPF” gebruiken dat mijn DNS-paneel aanbiedt? Nee. Type 99 is afgeschaft; RFC 7208 vereist uitsluitend TXT. Een type-99-record is onzichtbaar voor moderne ontvangende servers.

Het record wordt nu gevonden — waarom faalt mijn mail nog steeds op SPF? Omdat SPF wordt gecontroleerd tegen het Return-Path-domein, niet de From-header, en het record daadwerkelijk de servers moet vermelden die voor u verzenden. Gevonden worden is stap één; de gids repareer uw SPF-record behandelt het slagen.

Is helemaal geen SPF-record echt zo gebruikelijk? Ja — 121.145.609 domeinen, 46,4% van de 261.086.232 die in de Defaults.Exposed-census zijn beoordeeld (per 2026-06-29), publiceren helemaal geen SPF. Niet-gevonden is de standaardtoestand van het internet.

Stuur de eigenaar het rapport

Zodra het record netjes wordt gevonden, voert u de scan opnieuw uit en stuurt u het beoordeelde rapport door naar de bedrijfseigenaar of klant van wie dit domein is. Het laat in gewone taal zien wat er kapot was, wat u hebt gerepareerd en waar het domein nu staat — precies het bewijs waar bij cyberverzekeringsverlengingen en beveiligingsvragenlijsten van leveranciers om wordt gevraagd. Het rapport is het bonnetje van het werk.

Controleer uw SPF-record gratis

Zie in welke van de vijf niet-gevonden-situaties uw domein zit — privé en alleen voor de eigenaar.

Controleer uw domein → · Repareer SPF → · SPF werkt niet meer na wisselen van provider → · Hoe wij beoordelen → · Uitsluitend geaggregeerde gegevens. Gegevens opgeslagen en verwerkt in de EU.