Een SPF-record valideren betekent het controleren aan de hand van de regels die ontvangende mailservers daadwerkelijk afdwingen - de Sender Policy Framework-specificatie (RFC 7208). Een record kan er correct uitzien en toch worden geweigerd, dus hier leest u wat "geldig" betekent en hoe u de fouten oplost die deze validator vindt.
Wat "geldig" betekent onder RFC 7208
Een geldig SPF-record voldoet tegelijk aan al deze voorwaarden: het is het enige v=spf1 TXT-record op het domein, het begint met de v=spf1-tag, het gebruikt alleen erkende mechanismen en qualifiers, het resolvet in tien of minder DNS-lookups, het produceert niet meer dan twee void lookups, en het eindigt met een all-qualifier. Mist het er één, dan kunnen ontvangers een PermError teruggeven en het record behandelen alsof het nooit is gepubliceerd.
Syntaxregels die de validator afdwingt
- Slechts één record. RFC 7208 staat precies één
v=spf1-record per domein toe. Een tweede is een automatische PermError - beide worden genegeerd. - Correcte volgorde. De
v=spf1-versietag moet als eerste komen en hetall-mechanisme als laatste. - Alleen geldige mechanismen en qualifiers. Toegestane mechanismen zijn
include,a,mx,ip4,ip6,existsenall; elk mag een+-,--,~- of?-qualifier dragen. Typefouten zoalsip:ofincludes:falen. - Stringlengte. Elke afzonderlijke tekenreeks in het TXT-record moet binnen 255 tekens blijven, en het hele record binnen 512 bytes, anders kapt DNS het af.
De limieten van 10 lookups en 2 void lookups
Twee numerieke limieten vangen de meeste records met "geldige syntax, faalt toch". De eerste is het bekende plafond van tien DNS-bevragende mechanismen per evaluatie - elk include, a, mx, ptr en exists telt mee, en geneste includes tellen recursief mee. De tweede, minder bekende limiet is void lookups: niet meer dan twee mechanismen mogen resolven naar een leeg DNS-antwoord. Overschrijd een van beide en het resultaat is een PermError. Is uw record over de limiet van tien lookups, dan flattent AutoSPF de includes tot een compact record dat schoon valideert en scant elke 15 minuten opnieuw - zie te veel DNS-lookups voor de details.
Verouderde en risicovolle mechanismen
De validator waarschuwt voor twee dingen die technisch parseerbaar zijn maar vermeden moeten worden. Het ptr-mechanisme is verouderd volgens RFC 7208 (§5.5) omdat het traag en onbetrouwbaar is - vervang het door ip4/ip6 of een include. En +all autoriseert het hele internet om als uw domein te versturen, wat het doel van SPF volledig tenietdoet; een geldig record zou moeten eindigen op -all of ~all.
Hoe u een ongeldig SPF-record repareert
De meeste validatiefouten wijzen naar een van vier oplossingen - en onze gids over hoe u SPF-validatie oplost behandelt elk daarvan diepgaand:
- Twee SPF-records? Voeg elke verzender samen in één
v=spf1-record. - Meer dan 10 lookups? Vervang lookup-zware includes door
ip4/ip6-vermeldingen, of flatten het record automatisch met AutoSPF. - Verouderde
ptr? Verwijder het en autoriseer die hosts in plaats daarvan per IP of include. - Ontbrekende of verkeerde qualifier? Zorg dat het record begint met
v=spf1en eindigt met-all(of~allterwijl u test).
Vanaf nul opnieuw opbouwen is vaak eenvoudiger dan patchen - de gratis SPF-record-generator produceert een syntactisch schoon record dat u hier in één stap kunt valideren.
Waar SPF staat naast DKIM en DMARC
Een geldig SPF-record is noodzakelijk maar niet voldoende. DKIM ondertekent de berichttekst en DMARC koppelt SPF en DKIM aan het zichtbare From-domein en stelt het handhavingsbeleid in. Nadat u uw SPF-record controleert en het valideert, bevestigt u de andere twee met de gratis DMARC-checker en DKIM-lookup. Valideer SPF opnieuw telkens wanneer u een verzenddienst toevoegt of verwijdert, en audit het minstens één keer per kwartaal - en onthoud dat elk verzendend subdomein zijn eigen geldige record nodig heeft.