SPF-record controleren

Uw domein controleren

Wat SPF wel en niet doet

SPF beantwoordt één vraag: mag deze server e-mail versturen namens dit domein? Het domein in kwestie is het envelope-adres — het adres waarmee de verzendende server zich tijdens de aflevering meldt en waar bounces naartoe gaan. Dat is niet hetzelfde als het afzenderadres dat uw ontvanger in zijn mailprogramma ziet.

Dit is de meest voorkomende misvatting over SPF, dus hij hoort vooraan: SPF alleen beschermt het zichtbare afzenderadres niet. Een afzender kan een envelope gebruiken van een domein waarover hij wél zeggenschap heeft, SPF netjes laten slagen, en toch uw domeinnaam in het zichtbare From-veld zetten. Pas DMARC eist dat het gecontroleerde domein overeenkomt met wat de ontvanger ziet. Hoe u dat inricht staat op Domeinbescherming voor e-mail.

Tweede beperking: SPF breekt bij doorsturen. Een doorgestuurd bericht komt bij de eindontvanger aan vanaf het IP-adres van de doorsturende server, en dat staat niet in uw record. DKIM heeft daar geen last van, omdat de handtekening in het bericht zelf zit en meereist. Wie alleen op SPF leunt, ziet doorgestuurde post dus onterecht falen.

De mechanismen

Een SPF-record is een reeks mechanismen die elk een groep afzenders autoriseren. Voor het lookupprobleem verderop is één kolom doorslaggevend: welke mechanismen tellen mee tegen het maximum van tien DNS-lookups, en welke niet.

Ook de redirect-modifier, die de evaluatie naar een ander record doorschuift, kost een lookup. Dat ip4 en ip6 níet meetellen is geen voetnoot: het is de sleutel tot vrijwel elke oplossing van een lookupprobleem. Vaste adressen van eigen servers horen als ip4 of ip6 in het record, niet achter een a of include.

De qualifiers

Voor elk mechanisme kan een qualifier staan die bepaalt wat een match betekent:

En dan de evaluatieregel die de meeste mensen niet kennen: een SPF-record wordt van links naar rechts gelezen en het eerste mechanisme dat matcht, wint. Omdat all altijd matcht, wordt alles wat erná staat nooit bekeken. Een record als v=spf1 mx ~all include:dienst.example autoriseert die dienst dus niet — de ontvanger komt er simpelweg nooit aan toe.

Het lookupbudget van tien

RFC 7208 staat per SPF-evaluatie maximaal tien DNS-lookups toe. Dat budget geldt globaal over de hele recursie, niet per record: elke include kost er zelf één, en alles wat het opgehaalde record vervolgens aan include-, a-, mx- of exists-mechanismen bevat, telt gewoon door tegen dezelfde tien.

Een echt voorbeeld, gemeten met deze controleur: hostage.nl heeft drie includes in zijn record, maar kost vijf lookups — spf.xyphen.it bevat er zelf nog twee. En mailgun.org heeft twee includes maar kost er vier. Een tool die alleen het aantal includes in uw eigen record telt, zit er daarom structureel naast, soms een factor twee. De enige manier om het werkelijke getal te kennen is de keten daadwerkelijk aflopen, en dat is precies wat de controleur hierboven doet.

Boven de tien geeft SPF permerror, en dat is geen waarschuwing maar een totale uitval: niets krijgt meer een pass, ook uw eigen mailserver niet. Bij DMARC valt daarmee de hele SPF-poot weg, en leunt de bezorging nog uitsluitend op DKIM.

Het verraderlijke is het moment waarop dit misgaat. De fout treedt op bij het versturen, wanneer de ontvangende server het record evalueert — niet bij het publiceren. U kunt het dus niet aan het record zelf zien: het staat er ogenschijnlijk correct, uw DNS-beheerpaneel klaagt nergens over, en toch faalt elke controle. Alleen vooraf recursief doorrekenen maakt het zichtbaar.

Te veel lookups: wat u wél moet doen

Zit u aan of over de limiet, doorloop dan deze stappen in deze volgorde:

1. Schrap ongebruikte diensten en overbodige mechanismen. Includes van pakketten die u jaren geleden heeft opgezegd, een mx terwijl uw mailservers nooit uitgaand versturen, een a voor een webserver die geen mail stuurt, elke ptr. Dit lost het merendeel van de gevallen op.
2. Orden de includes op volume. Zet de dienst die het meeste verstuurt vooraan. SPF stopt bij de eerste match, dus voor het gros van uw post is de evaluatie dan na één of twee lookups klaar.
3. Verplaats marketing- en transactiemail naar een subdomein. SPF erft niet: een subdomein heeft zijn eigen record, en dus zijn eigen budget van tien. nieuwsbrief.uwdomein.nl draagt de includes van de nieuwsbriefdienst, en het hoofddomein houdt ruimte over.
4. Richt DKIM goed in. Doorsturen breekt SPF per definitie en DKIM niet. Met een werkende DKIM-handtekening blijft DMARC ook slagen wanneer SPF onderweg sneuvelt. Het stappenplan staat in SPF, DKIM en DMARC instellen.

Waarom wij flattening afraden

Er is nog een vijfde route, die veel tools en diensten als eerste aanraden: flattening. Daarbij vervangt u de includes door de IP-lijsten die ze op dit moment opleveren. Het lookupprobleem is dan inderdaad weg — ip4 en ip6 kosten immers niets.

Het bezwaar is fundamenteel. include bestaat juist om ontkoppeling te bieden: de dienstverlener beheert zijn eigen adressen en uw record volgt automatisch. Na flattening is die koppeling weg. De provider wijzigt zijn reeksen wanneer hij wil, zonder u te waarschuwen, en uw record loopt stil uit de pas. De sprekendste faalvorm: een provider voegt één IP-adres toe aan zijn pool, en ongeveer één op de twintig van uw berichten faalt SPF — precies wanneer de load balancer dat nieuwe adres kiest. Intermitterend, dus vrijwel niet te diagnosticeren, en juist schadelijk als uw DMARC-beleid al op quarantine of reject staat.

Het sterkste argument komt van de bedenker zelf: dmarcian, de partij die flattening bedacht, is er in 2023 mee gestopt.

Onze conclusie: pas flattening alleen toe als de vier stappen hierboven zijn uitgeput, en dan als bewuste noodgreep — met een eigenaar die het record onderhoudt en monitoring die alarm slaat wanneer de bronlijsten wijzigen. Niet als standaardoplossing.

Twee dingen die u nooit moet doen

+all — of een kaal all zonder qualifier, wat hetzelfde is. Daarmee autoriseert u het hele internet om namens uw domein te mailen: elke spoofer krijgt een SPF-pass cadeau. En het is erger dan geen record, want bij aspf=r kan die pass zelfs voor DMARC-uitlijning meetellen. Het is geen zwakke instelling maar een averechtse.

ptr — RFC 7208 raadt het expliciet af. Het mechanisme is traag, onbetrouwbaar wanneer reverse DNS hapert, en het belast de reverse-DNS-servers van anderen bij elke controle. Alles wat ptr doet, doet een ip4, ip6 of include beter.

-all of ~all?

Hier past eerlijkheid: de RFC schrijft geen van beide voor. Onze richtlijn is ~all (softfail) tijdens de uitrol, zolang u nog niet zeker weet dat álle verzendende systemen — de nieuwsbriefdienst, het boekhoudpakket, het ticketsysteem — in het record staan. Is dat beeld compleet, dan is -all de eindstand: een expliciete uitspraak dat al het overige niet van u komt. Voor ontvangers die geen DMARC verwerken is die -all bovendien het enige signaal dat er is.

Eén waarschuwing daarbij: -all op een record dat al permerror geeft is geen strengheid maar een storing. Los eerst het lookup- of syntaxprobleem op; pas daarna heeft de qualifier betekenis.

Veelgestelde vragen