Voer een willekeurig domein door deze SPF-checker en hij haalt het live record op, klapt elk mechanisme uit en toont u de volledige lijst met IP-adressen die uw domein momenteel vertrouwt om mail te versturen. Alles buiten die lijst is wat ontvangende servers zullen betwisten of weigeren. Bent u nieuw met het concept, begin dan met wat een SPF-lookup is en waarom die ertoe doet.
Hoe een SPF-record eruitziet
Een SPF-record is één TXT-vermelding die is gepubliceerd in uw DNS-records en die ontvangers vertelt welke mailservers namens uw domein berichten mogen versturen. Een typisch record ziet er zo uit:
v=spf1 include:_spf.google.com ip4:192.0.2.0/24 -all
Elk stukje is een mechanisme. Het include:-mechanisme haalt de geautoriseerde verzenders van een ander domein binnen, ip4: autoriseert een specifiek IP-adres of IP-reeks, en de afsluitende -all weigert elke andere verzender. Wanneer u deze SPF-checker uitvoert, klapt hij elk mechanisme uit, valideert hij de syntax aan de hand van de Sender Policy Framework (SPF)-specificatie (RFC 7208) en toont hij elk IP-adres dat uw domein momenteel autoriseert.
Veelvoorkomende SPF-fouten en wat ze betekenen
Wanneer de checker uw record analyseert, resulteert het in een van diverse SPF-uitkomsten. De fouten die het waard zijn om te herkennen:
- PermError (getoond als
PermErrorin de tooluitvoer) - een permanente fout in het record zelf. Vrijwel altijd een syntaxfout of een record dat de DNS-lookup-limiet overschrijdt. Ontvangers behandelen het record alsof het niet bestaat. Los de syntax op of beperk geneste includes om het te verhelpen. - TempError (
TempError) - een tijdelijk DNS-resolutieprobleem, vaak een trage of onbereikbare nameserver. Test over een paar minuten opnieuw; blijft het aanhouden, controleer dan uw DNS-provider. - softfail (de
~all-qualifier) - de verzender is niet geautoriseerd, maar ontvangers zouden het bericht moeten accepteren en als verdacht moeten markeren. Gebruikelijk in overgangssituaties voordat wordt overgeschakeld naar hardfail. - hardfail (de
-all-qualifier) - de verzender is niet geautoriseerd, dus ontvangers weigeren het bericht ronduit. Dit is de instelling die u wilt zodra elke legitieme verzender in beeld is. - none - het domein publiceert helemaal geen SPF-record, dus ontvangers hebben niets om de verzender aan te toetsen en behandelen de mail vaak als niet-vertrouwd.
- neutral (de
?all-qualifier) - het domein weigert uitdrukkelijk autorisatie te bevestigen. Wordt vergelijkbaar met none behandeld.
Elke uitkomst wijst naar een andere oplossing. Syntaxfouten, ontbrekende TXT-records en ongeautoriseerde verzenders verschijnen in de checker als afzonderlijke foutcategorieën, zodat u ernaar kunt handelen zonder in ruwe DNS-antwoorden te hoeven graven.
Hoe SPF samenwerkt met DKIM en DMARC
SPF is een van de drie e-mailauthenticatiestandaarden die samenwerken, dus een SPF-controle vertelt zelden het hele verhaal op zichzelf. SPF verifieert de verzendende server, DKIM voegt een cryptografische handtekening toe die bewijst dat het bericht onderweg niet is gewijzigd, en DMARC koppelt de twee - het controleert of SPF of DKIM uitlijnt met het domein in het zichtbare "From"-adres en vertelt ontvangers wat te doen wanneer authenticatie faalt. Gmail, Yahoo en Microsoft vereisen nu alle drie van bulkverzenders, dus een geslaagd SPF-record is het fundament waarop de rest van uw e-mailauthenticatie - en uw verdediging tegen spoofing en e-mailfraude - is gebouwd.
Wanneer u een probleem oplost dat deze SPF-checker aan het licht brengt, controleer dan DKIM en DMARC tegelijkertijd opnieuw. Een technisch geldig SPF-record dat niet uitlijnt met uw DMARC-beleid kan alsnog falen, en SPF aanscherpen naar -all voordat uw andere verzenders in beeld zijn, blokkeert legitieme mail.
De limiet van 10 DNS-lookups
include-, a-, mx-, ptr- en exists-mechanisme telt mee voor de limiet van 10 DNS-lookups. Overschrijd hem en het record faalt met PermError.De Sender Policy Framework-specificatie beperkt DNS-lookups tot tien per evaluatie (RFC 7208, sectie 4.6.4). Elk include:-, a-, mx-, ptr- en exists-mechanisme telt mee voor de limiet, en geneste includes tellen recursief mee. Wanneer uw record de limiet van 10 DNS-lookups overschrijdt, geven ontvangers PermError terug en kunnen uw berichten in spam belanden, hoe correct de rest van uw record ook is - elk IP-adres dat u hebt vermeld wordt irrelevant op het moment dat de lookup-limiet boven de tien uitkomt.
De checker telt elke lookup die uw record veroorzaakt, inclusief die verborgen zitten in externe include:-directives. Zit u boven de tien - of dichtbij - dan kan AutoSPF uw SPF-record automatisch flattenen, waarbij de geautoriseerde IP-adressen behouden blijven terwijl geneste lookups worden samengevoegd tot één geldig SPF-record.
Wanneer u een SPF-controle uitvoert
Voer een SPF-controle uit telkens wanneer u een e-mailprovider toevoegt of verwijdert, van platform migreert of merkt dat berichten in spam belanden - deze SPF-recordcontroles zijn routinematige hygiëne, dus audit uw record minstens één keer per kwartaal. Telkens wanneer u wijzigt wie mail voor uw domein verstuurt, bevestigt een SPF-lookup dat het record nog steeds resolvet, onder de limiet van 10 lookups blijft en alleen de servers vermeldt die u vertrouwt. Tools zoals deze maken daar een controle van 10 seconden van in plaats van een handmatige dig-sessie, en werken goed samen met een DMARC-checker en DKIM-lookup voor een volledig beeld van uw e-mailauthenticatie. Controleer ook uw subdomeinen apart - een subdomein erft het SPF-record van het bovenliggende domein niet, dus elk subdomein dat mail verstuurt heeft zijn eigen record nodig.