Sender Policy Framework opzoeken

SPF-record checken: je beleid opzoeken en lezen

Haal het gepubliceerde v=spf1-record van een verzenddomein op, lees de mechanismen in volgorde en tel de termen op het hoogste niveau die DNS-queries veroorzaken.

De checker vraagt TXT op voor het domein, isoleert het v=spf1-beleid en telt de termen op het hoogste niveau die DNS-queries veroorzaken. Hij vergelijkt de DNS-over-HTTPS-antwoorden van Cloudflare en Google.

Zo lees je het record

SPF autoriseert verzendinfrastructuur via IP-adres, include of redirect. Het all-mechanisme bepaalt het standaardoordeel voor afzenders die nergens op matchen. Mechanismen worden van links naar rechts geëvalueerd, en de eerste match beëindigt de evaluatie.

De limiet van 10 lookups

Elke include-, a-, mx-, ptr-, exists- of redirect-term dwingt tijdens de evaluatie extra DNS-queries af. RFC 7208 beperkt de volledige evaluatie tot 10 publieke DNS-lookups; wie die overschrijdt, krijgt permerror, ongeacht de tekst van het beleid.

Eén record, één domein

Een domein hoort precies één selecteerbaar v=spf1-record te publiceren. Als twee providers elk hun eigen record publiceren, combineer de termen dan in één beleid in plaats van beide te behouden.

Vragen over deze tool

Bewijst een SPF-record dat mijn e-mail in de inbox belandt?

Nee. SPF publiceert het autorisatiebeleid voor het domein. Inboxplaatsing hangt af van authenticatie-alignment, afzenderreputatie, content en de filters van de ontvangende provider.

Waarom meldde de checker een risico voor het lookupbudget?

De DNS-queryende termen op het hoogste niveau naderen of overschrijden de evaluatielimiet van 10 lookups uit RFC 7208. Flatten of splits de include-keten voordat afzenders permerror krijgen.

Kan ik SPF controleren voor een subdomein?

Ja. Voer het subdomein zelf in. SPF heeft geen fallback naar het bovenliggende domein: ontvangers controleren alleen de exacte naam die wordt gebruikt in MAIL FROM of HELO, dus elk subdomein dat e-mail verstuurt heeft zijn eigen v=spf1-record.