English Nederlands Español Italiano 日本語 Français
Log in

SPF|A- en MX-records

SPF-records bevatten vaak bijna standaard “a”- en “mx”-mechanismen: vroege SPF-generatortools maakten ze verplicht, of een domein ze nu nodig had of niet. Dat advies is niet goed gealterd: tegenwoordig is het opnemen ervan een van de meest voorkomende manieren waarop een SPF-record stilletjes kapot gaat. (Nieuw met SPF? Begin bij SPF | richtlijnen voor de basis.)

DNS round-robin breekt A/MX-gebaseerde SPF

Veel mailservers staan achter load balancers die bij elke -query een andere set IP-adressen teruggeven (een patroon dat round-robin, of “ flapping” heet). Bevat je SPF-record een “a”- of “mx”-mechanisme dat naar zo’n server verwijst, dan komt het IP waar een bericht daadwerkelijk vandaan kwam mogelijk niet overeen met wat je SPF-check toevallig oploste, met periodieke, onvoorspelbare authenticatiefouten tot gevolg.

Waarom dit belangrijk is

Het mx-mechanisme autoriseert welke IP-adressen de van je domein op dit moment ook aanwijzen, maar bestaan om inkomende mail af te handelen, niet om te beschrijven wie mag versturen. Je daadwerkelijke uitgaande mailprovider (Microsoft 365, Google Workspace en vergelijkbare) geeft je al een eigen include-mechanisme met alle IP’s die daadwerkelijk namens jou mogen versturen; dat is het mechanisme dat je SPF-record zou moeten gebruiken. Het a-mechanisme heeft hetzelfde probleem omgekeerd: het autoriseert het website-IP van je domein, en de meeste websites versturen tegenwoordig helemaal geen mail meer rechtstreeks: dat besteden ze uit aan een aparte email service provider.

Hoe het werkt

Naast simpelweg het verkeerde gereedschap voor de klus zijn, lossen a en mx allebei op het moment van evaluatie op: elke keer dat een ontvangende server je SPF-record controleert, wordt de hostname waar die mechanismen naar verwijzen opnieuw opgelost. Staat die hostname achter een load balancer met round-robin, dan kan de set IP’s waarnaar hij oplost van de ene query op de andere veranderen. Een bericht dat verstuurd is vanaf een IP-adres dat een moment eerder nog geldig was, kan SPF laten falen simpelweg omdat de volgende -lookup een andere set adressen teruggaf.

Een uitgewerkt voorbeeld van DNS flapping

Zo ziet dat round-robin-gedrag er in de praktijk daadwerkelijk uit, met een echte MX-hostname die twee keer kort na elkaar wordt opgevraagd:

Query 1:
mta5.am0.yahoodns.net.  60  IN  A  67.195.228.110
mta5.am0.yahoodns.net.  60  IN  A  98.136.96.74
mta5.am0.yahoodns.net.  60  IN  A  67.195.204.74
mta5.am0.yahoodns.net.  60  IN  A  67.195.228.106

Query 2:
mta5.am0.yahoodns.net.  11  IN  A  67.195.228.94
mta5.am0.yahoodns.net.  11  IN  A  67.195.228.111
mta5.am0.yahoodns.net.  11  IN  A  67.195.204.73
mta5.am0.yahoodns.net.  11  IN  A  98.136.96.74

Twee queries, enkele seconden na elkaar, en bijna geen van de IP-adressen komt overeen. Zou deze hostname aangewezen worden door een a– of mx-mechanisme in een SPF-record, dan hangt het volledig af van het moment waarop een ontvangende server toevallig opzoekt welke van deze adressen geautoriseerd wordt. Dat is precies het soort periodieke, moeilijk te diagnosticeren authenticatiefout dat dit in de praktijk veroorzaakt.

Ik wil meer weten

Wat te gebruiken in plaats daarvan

  • Gebruik het include-mechanisme dat je mailprovider je geeft (bijvoorbeeld include:spf.protection.outlook.com voor Microsoft 365) in plaats van mx.
  • Moet je specifieke, stabiele IP-adressen rechtstreeks autoriseren, gebruik dan ip4 of ip6 in plaats van a.
  • Zowel a als mx tellen ook mee voor de -lookuplimiet; zie SPF | richtlijnen voor de volledige limiet en welke andere mechanismen daarin meetellen.

Dit betekent niet dat a en mx volledig verboden zijn: het zijn geldige SPF-mechanismen, en er zijn specifieke, bewuste gevallen waarin ze wel degelijk het juiste gereedschap zijn (bijvoorbeeld het autoriseren van de eigen -identiteit van een mailserver-hostname, wat wél een bijpassend “A”-record vereist). De aanbeveling gaat specifiek over het gebruik ervan als standaard, onbezonnen keuze voor het autoriseren van je algemene verzendinfrastructuur.

Goed om te weten

De Sender Manager van Manager controleert op hostnames die flapping vertonen en waarschuwt je voordat je er één aan een SPF-record toevoegt, specifiek om dit faalscenario te vangen voordat het productie bereikt.

Bronnen & verder lezen