SPF-, DKIM- & DMARC-checker

SPF, DKIM en DMARC zijn de drie DNS-records die bepalen of post die zegt van jouw domein te komen wordt vertrouwd of weggegooid. Ze werken als een set: SPF geeft aan welke servers namens het domein mogen versturen, DKIM ondertekent het bericht cryptografisch zodat het onderweg niet kan worden gewijzigd, en DMARC koppelt die twee aan het zichtbare Van-adres en vertelt ontvangers wat ze moeten doen als een controle faalt. Mis er één en de andere twee doen minder dan je denkt: spoofers glippen door het gat, en legitieme post belandt in spam.

Deze checker bevraagt alle drie tegelijk vanaf onze servers en rapporteert in gewone taal terug. Hij ontleedt je SPF-record en telt de DNS-lookups die het veroorzaakt af tegen de harde limiet van tien, leest je openbare DKIM-sleutel en schat de sleutellengte, en beoordeelt je DMARC-beleid van alleen meekijken tot volledige afwijzing. Eén domein erin, drie oordelen eruit. Geen registratie, en er wordt niets over je domein bewaard.

SPF: welke servers namens je domein mogen versturen

Een SPF-record is één TXT-record op je domein dat begint met v=spf1 en de hosts opsomt die als jou mogen mailen. Elke term benoemt bronnen direct (ip4:, ip6:) of verwijst ergens anders heen (include:_spf.google.com haalt de reeksen van je provider binnen, a en mx autoriseren je eigen A/MX-hosts). Een ontvangende server loopt die lijst af en controleert of het verbindende IP erin valt. Het record eindigt met een all-mechanisme dat alles opvangt wat nog niet is gematcht, en de kwalificatie op die all is het hele beleid in één teken.

De kwalificaties, van strengst naar zwakst: -all (harde fail) zegt ontvangers alles van een niet-vermelde bron te weigeren; ~all (zachte fail) zegt behandel het als verdacht maar accepteer het toch, de pragmatische keuze zolang je nog niet zeker weet dat je lijst compleet is; ?all (neutraal) spreekt geen oordeel uit en levert je niets op; en +all autoriseert expliciet het hele internet om als jou te versturen, wat vrijwel altijd een misconfiguratie is die het doel van het record tenietdoet. De meeste goed beheerde domeinen zitten op ~all of -all.

Het addertje dat meer SPF-records sloopt dan wat ook is de limiet van tien lookups. Elke include, a, mx, ptr, exists en redirect dwingt de ontvanger tot een DNS-lookup, en die nesten: een include kan zijn eigen includes bevatten. RFC 7208 legt het totaal over de hele keten op tien, en dat overschrijden is een permerror die het hele record stilletjes laat falen. Daarom publiceren grote verzenders "afgevlakte" records die IP-reeksen inlinen in plaats van includes te ketenen. De checker telt je echte, recursieve totaal aan lookups, zodat je weet hoeveel ruimte er nog over is voordat je erover gaat.

DKIM: een handtekening die bewijst dat het bericht ongewijzigd is

DKIM voegt een cryptografische handtekening toe aan elk uitgaand bericht. Je mailserver houdt een privésleutel vast en ondertekent elk bericht; de bijbehorende openbare sleutel staat in DNS, en de ontvanger gebruikt die om te verifiëren dat de ondertekende delen van het bericht niet zijn veranderd nadat het je verliet. Een geldige handtekening bewijst twee dingen tegelijk: het bericht komt echt van een systeem dat je sleutel bezit, en de headers en de inhoud zijn intact aangekomen.

De openbare sleutel staat op een selector: een label dat je zelf kiest en dat de sleutel in DNS een eigen naamruimte geeft, gepubliceerd op <selector>._domainkey.<domain>. Selectors bestaan zodat je meerdere sleutels tegelijk kunt draaien (één per verzendende dienst) en ze zonder downtime kunt roteren: publiceer een nieuwe selector, schakel het ondertekenen om, en trek de oude daarna in. De selectornaam is niet geheim, maar hij is ook niet af te leiden uit het domein alleen; je vindt hem in de DNS-instructies van je mailprovider (Google gebruikt google, Microsoft 365 gebruikt selector1/selector2, veel ESP’s gebruiken hun eigen naam) of door de DKIM-Signature-header te lezen van een bericht dat je al hebt ontvangen, waar hij als de s=-tag staat. Deze tool kan ook een lijst met gangbare selectors voor je aftasten als je hem niet weet.

Sleutellengte telt. Een RSA-sleutel van 1024 bits was ooit de standaard en geldt nu als zwak: hij ligt binnen bereik van een vastberaden aanvaller en sommige providers zijn hem gaan wantrouwen. 2048 bits is de huidige basislijn en wat je zou moeten publiceren; sommige opstellingen gebruiken ed25519-sleutels, die kort maar sterk zijn. Roteer sleutels periodiek, ongeacht de lengte, want een sleutel die nooit verandert is een sleutel die nooit herstelt als hij uitlekt. De checker leest je gepubliceerde sleutel en schat de grootte, zodat je een moderne 2048-bits sleutel in één oogopslag van een verouderde 1024-bits sleutel onderscheidt.

DMARC: uitlijning, beleid en rapportages

DMARC is het record dat SPF en DKIM samen ergens toe laat optellen. Het staat op _dmarc.<domain> als TXT-record dat begint met v=DMARC1 en doet drie dingen: het eist uitlijning, het domein dat SPF of DKIM heeft doorstaan moet overeenkomen met het zichtbare Van-domein, waarmee de maas wordt gedicht waarbij een bericht SPF haalt voor een ongerelateerd domein terwijl het toch het jouwe spooft; het verklaart een beleid dat ontvangers vertelt wat ze bij een gefaalde controle moeten doen; en het vraagt rapportages op zodat je kunt zien wie er als jou verstuurt.

Het beleid is de p=-tag en het is een ladder die je beklimt, geen schakelaar die je omzet. p=none is alleen meekijken: ontvangers bezorgen falende post nog steeds maar sturen je rapportages, en daar hoort elke uitrol precies te beginnen, zodat je verkeer kunt bekijken zonder iets te breken. p=quarantine zegt ontvangers falende post als verdacht te behandelen, meestal door hem naar spam te sturen. p=reject zegt ze hem ronduit te weigeren, en is de eindtoestand die spoofing daadwerkelijk stopt. Twee extra tags sturen de uitrol: pct= past het beleid op slechts een percentage van de post toe (een manier om reject vanaf 10% op te voeren), en een pct onder 100 betekent dat de meeste falende post er nog steeds doorheen komt.

De rua=-tag is waar je geaggregeerde rapportages heen stuurt: dagelijkse XML-samenvattingen van ontvangers met elke bron die als jouw domein verstuurt, welke slagen of falen, en hoe. Zonder rua handhaaf je een beleid blind; met rua kun je elke legitieme verzender vinden voordat je aanscherpt naar reject, zodat je niet per ongeluk je eigen facturen of nieuwsbrieven blokkeert. Een DMARC-record zonder rapportageadres is de meest voorkomende reden dat een uitrol voor altijd op p=none blijft steken.

De drie in de juiste volgorde uitrollen

De volgorde telt, omdat elk record afhangt van de records ervoor. Zorg eerst dat SPF en DKIM slagen en uitgelijnd zijn, leg daar dan DMARC in meekijkmodus overheen, en scherp daarna aan. Meteen naar p=reject springen voordat je hebt bevestigd dat elke legitieme verzender uitgelijnd is, is hoe je je eigen post blokkeert.

Een minimaal, correct startpunt ziet eruit als de records hieronder: een SPF-record dat je provider autoriseert en de rest zacht laat falen, een DKIM-sleutel gepubliceerd op de selector van je provider, en een DMARC-record in meekijkmodus met een rapportageadres, zodat je kunt kijken voordat je handhaaft.

• Publiceer eerst SPF: som elke verzendende bron op en eindig met ~all, bijvoorbeeld v=spf1 include:_spf.google.com ~all. Controleer opnieuw dat het aantal lookups onder tien blijft.
• Voeg DKIM toe: zet ondertekenen aan bij je mailprovider en publiceer de openbare sleutel op de selector die hij je geeft (bijvoorbeeld google._domainkey.example.com). Kies bij voorkeur een 2048-bits sleutel.
• Voeg DMARC in meekijkmodus toe: v=DMARC1; p=none; rua=mailto:reports@example.com. Verzamel een paar weken rapportages en bevestig dat alle echte verzenders slagen.
• Scherp geleidelijk aan: ga van p=none → p=quarantine → p=reject, eventueel opgevoerd met pct=, pas zodra de rapportages laten zien dat elke legitieme bron uitgelijnd is.