SPF in de praktijk: alle verzenders in kaart

Module 4: Afleverbaarheid: SPF, DKIM en DMARC in de praktijk · Leestijd: 12 minuten

Leerdoel: Na deze les kun je alle diensten opsporen die namens je domein mailen, ze in één SPF-record onderbrengen, de opzoekingen recursief tellen tot de grens van tien, en bewust kiezen tussen ~all en -all.

Kernbegrippen: inventaris van verzenders, envelope-afzender (Return-Path), één SPF-record, include, redirect, limiet van 10 DNS-opzoekingen (RFC 7208 paragraaf 4.6.4), lege opzoekingen (void lookups, maximaal 2), recursief tellen, permerror, flattening, SPF voor subdomeinen, SPF op een domein dat niet mailt, ~all en -all

Even herhalen

Een SPF-record is een TXT-record op je domein dat begint met v=spf1 en opsomt welke servers namens je domein mogen mailen. De opbouw, de tekens + - ~ ? en de drie bekendste fouten (twee records, +all, meer dan tien opzoekingen) staan in de DNS-cursus, les 4.3. Lees die eerst als SPF nieuw voor je is. Deze les gaat over het lastige deel: in de praktijk weet bijna niemand precies wie er allemaal namens zijn domein mailt.

Stap 1: de inventaris

SPF werkt alleen als alle verzenders erin staan. Vergeet je er één, dan komt die mail in de spam of wordt hij geweigerd zodra je DMARC aanscherpt. Loop daarom deze lijst na. Bij een gemiddeld klein bedrijf vind je er al snel vijf of zes:

Twee goede manieren om ze te vinden:

1. Kopregels lezen. Stuur vanuit elk systeem een mail naar jezelf (een factuur, een wachtwoordherstel, een testnieuwsbrief) en kijk in de kopregels naar Return-Path en Authentication-Results (les 1.5). Daar zie je via welk domein en welke server hij kwam.
2. DMARC-rapporten. Zet DMARC op p=none met een rapportadres (les 4.4). Na een paar weken zie je in de rapporten (les 4.5) elke server die namens je domein mailde, ook die je vergeten was. Dat is de betrouwbaarste inventaris.

Niet elke dienst hoort in je SPF

Hier gaat het vaak mis. SPF kijkt naar de envelope-afzender (het Return-Path), niet naar het Van-adres. Veel nieuwsbrief- en verzenddiensten versturen met een Return-Path op hun eigen domein, bijvoorbeeld bounce-123@mail.mailer.example. De ontvanger controleert dan het SPF-record van mailer.example, niet het jouwe. Een include van die dienst in jouw record doet dan niets, behalve een opzoeking kosten.

Wat die dienst wel nodig heeft om door DMARC te komen, is een DKIM-handtekening met jouw domein (les 4.3), of een eigen Return-Path-subdomein van jou (bijvoorbeeld bounce.example.com als CNAME naar de dienst). Lees dus in de handleiding van de dienst wat hij vraagt. Zegt hij "zet include: in je SPF", doe dat dan. Zegt hij alleen "maak deze CNAME-records voor DKIM en het bounce-domein", dan hoeft er niets in je hoofdrecord. Module 7 gaat hier verder op in.

Stap 2: één record, en goed tellen

Alle verzenders gaan in één record. Stel dat je inventaris dit oplevert: de mailserver van je hostingbedrijf, Microsoft 365 voor een paar medewerkers, je boekhoudprogramma en een helpdesk. Dan wordt het record bijvoorbeeld:

example.com.  3600  IN  TXT  "v=spf1 a mx include:spf.hosting.example include:spf.protection.outlook.com include:_spf.boekhoud.example include:mail.helpdesk.example ~all"

Hoeveel opzoekingen is dat? Tel elke a, mx, include, exists, ptr en redirect, en tel daarna ook alles wat in de records achter elke include staat:

Bij 11 geeft de ontvanger een permerror: het hele SPF-record telt dan niet, voor geen enkele verzender. Je mail van je eigen mailserver wordt dus slechter beoordeeld omdat de helpdesk drie opzoekingen kost. En het verraderlijke is: je record kan vandaag 9 zijn en morgen 11, zonder dat jij iets wijzigt, omdat een dienst zijn eigen record uitbreidt.

Daarnaast: maximaal twee lege opzoekingen

RFC 7208 noemt ook void lookups: opzoekingen die niets opleveren (de naam bestaat niet, of heeft geen SPF- of adresrecord). Meer dan twee daarvan leidt ook tot een permerror. Dat gebeurt vooral met oude includes van diensten die je niet meer gebruikt en die hun record hebben weggehaald, of met een a: naar een server die niet meer bestaat. Opruimen dus.

Stap 3: terug onder de tien

Zit je boven de tien, dan zijn er vier oplossingen, van best naar minst goed:

1. Haal weg wat niet nodig is. Diensten die je niet meer gebruikt. Diensten die met een eigen Return-Path versturen (zie hierboven) en dus niet in jouw SPF horen. a als je website zelf geen mail verstuurt. mx als je MX naar een dienst wijst die al met een include in je record staat.
2. Gebruik een subdomein. Laat een dienst versturen vanaf nieuws.example.com of factuur.example.com. Dat subdomein krijgt een eigen SPF-record met alleen die dienst, en telt niet mee in de tien van je hoofddomein. Uitlijning in DMARC (les 4.4) werkt standaard ook voor subdomeinen.
3. Gebruik ip4: en ip6: voor je eigen vaste servers. Die kosten geen opzoeking. Doe dat alleen voor adressen die jij beheert en die niet veranderen.
4. Flattening (alle includes vervangen door de IP-adressen die er nu achter zitten). Dat haalt het aantal op 0, maar het record klopt niet meer zodra een dienst zijn adressen verandert, en grote diensten doen dat regelmatig. Doe het alleen met een tool die het automatisch bijhoudt, en liever helemaal niet.

redirect of include?

redirect= zegt: gebruik het SPF-record van dat andere domein in plaats van dit record. Het kost één opzoeking, net als een include. Het is handig als je veel domeinen hebt die precies hetzelfde beleid moeten krijgen: v=spf1 redirect=_spf.example.com op elk domein, en het echte record op één plek. Een record met redirect= mag geen all hebben, want dan wordt de redirect genegeerd. Gmail gebruikt het zelf: gmail.com heeft v=spf1 redirect=_spf.google.com.

Stap 4: ~all of -all?

De advieslijn van deze cursus, gelijk aan de DNS-cursus:

• Begin met ~all (softfail). Mail van een server die niet in je record staat, wordt als verdacht gezien, maar meestal niet meteen geweigerd. Vergeet je een verzender, dan is de schade beperkt.
• Ga naar -all (fail) als je zeker weet dat alle verzenders erin staan, bijvoorbeeld nadat je een paar weken DMARC-rapporten hebt bekeken en er geen onbekende bronnen meer zijn.

Met DMARC erbij is het verschil kleiner dan vaak wordt gedacht. DMARC beslist op basis van "SPF of DKIM geslaagd en uitgelijnd". Een softfail is voor DMARC gewoon "niet geslaagd". De echte bescherming komt dus van een streng DMARC-beleid, niet van -all. Sommige ontvangers weigeren bij -all al vóór de DMARC-beoordeling; dat is een reden om -all pas te kiezen als je record echt compleet is.

Een domein dat nooit mailt

Heb je domeinen die nooit mail versturen (een oude merknaam, een tikfoutdomein)? Bescherm ze dan tegen misbruik met:

example.org.         IN  TXT  "v=spf1 -all"
_dmarc.example.org.  IN  TXT  "v=DMARC1; p=reject"
example.org.         IN  MX   0 .

Hier is -all meteen goed: er is niemand die mag mailen. De laatste regel is een null MX (RFC 7505): "dit domein ontvangt geen mail". example.com zelf staat precies zo ingesteld.

In de praktijk: zo ziet het eruit in een paneel

Bij een hostingpakket van WebOké staat standaard v=spf1 a mx include:webawere.nl ~all. Voeg je een dienst toe, dan pas je dat record aan (in DirectAdmin: DNS Beheer, het potlood achter het SPF-record, veld Inclusief Domein; in Mijn WebOké: de SPF-hulp op het tabblad DNS). Laat include:webawere.nl staan zolang je mail of website via die servers loopt. Bij andere aanbieders heet de standaardinclude anders, maar het principe is gelijk: aanvullen, niet een tweede record maken.

Samenvatting

• Maak eerst een inventaris van alle verzenders; DMARC-rapporten en kopregels helpen daarbij.
• Een dienst met een eigen Return-Path hoort niet in je SPF; die heeft DKIM met jouw domein nodig.
• Tel recursief: elke include, a, mx, exists, ptr en redirect, ook binnen includes. Boven de tien, of meer dan twee lege opzoekingen, is permerror.
• Kom terug onder de tien door op te ruimen en subdomeinen te gebruiken; flattening alleen met automatisch onderhoud.
• Begin met ~all, ga naar -all als je zeker bent. Domeinen die nooit mailen: -all, DMARC reject en null MX.

Quiz

Opdracht

Opdracht Z4.2: SPF van je domein recursief laten tellen. Vul je eigen domein in (of sidn.nl als je geen eigen domein hebt). Tel zelf eerst hoeveel DNS-opzoekingen het SPF-record kost, inclusief alles binnen de includes, en vul het getal in, samen met het einde van het record (~all, -all, ?all of +all). Het programma telt live na, inclusief lege opzoekingen, en laat de boom zien.

Opdracht O4.2: Je verzendersinventaris. Maak met de tabel uit deze les een lijst van alle systemen die namens je domein mail versturen. Zet bij elk: via welke server of dienst, of hij in je SPF moet (eigen Return-Path of niet), en of hij DKIM met jouw domein tekent. Stuur vanuit minstens twee systemen een testmail naar jezelf en noteer uit de kopregels het Return-Path-domein en het DKIM-domein (d=).

Verder lezen

De stappen in deze artikelen gelden voor de panelen van WebOké; bij andere aanbieders werkt het vergelijkbaar.

• Gratis DNS-cursus 4.3: SPF: wie mag mailen namens jouw domein?
• DirectAdmin handleiding 5.7: SPF instellen en aanvullen
• Hoe werkt het SPF-record in de DNS?
• SPF-record toevoegen of wijzigen in DirectAdmin
• WebOké handleiding 5.5: DNS-hulpjes: MX, SPF, DMARC, CAA en SRV
• RFC 7208 (SPF), paragraaf 4.6.4 (limieten) en 6.1 (redirect); RFC 7505 (null MX)