SPF, DKIM en DMARC uitgelegd: veilig op weg naar p=reject

Iedereen kan uw domein in de Van-regel van een e-mail typen. Met SPF, DKIM en DMARC kan de ontvangende server controleren of een bericht echt van u komt, en weet hij wat hij moet doen als dat niet zo is. Zorgvuldig ingericht maken ze spoofing van uw exacte domein veel moeilijker. Overhaast ingevoerd kunnen ze uw eigen facturen tegenhouden.

Wat elk mechanisme doet

SPF (Sender Policy Framework, RFC 7208) is een TXT-record in DNS dat de servers opsomt die e-mail namens een domein mogen versturen. De ontvanger vergelijkt het IP-adres van de server die verbinding maakt met die lijst. SPF controleert de envelope-afzender (de identiteiten MAIL FROM en HELO), niet het From-adres dat de ontvanger ziet.

DKIM (DomainKeys Identified Mail, RFC 6376) voegt aan elk bericht een cryptografische handtekening toe. De tag d= noemt het ondertekenende domein en s= een selector. De publieke sleutel staat in DNS op selector._domainkey.domain. Een geldige handtekening laat zien dat de ondertekende delen van het bericht niet zijn gewijzigd sinds dat domein ze ondertekende.

DMARC koppelt beide aan het zichtbare From-domein. In mei 2026 is een herziene versie gepubliceerd als RFC 9989, een Standards Track-document dat RFC 7489 vervangt. Een DMARC-record legt uw beleid vast en vraagt ontvangers u rapporten te sturen.

Alignment wordt vaak over het hoofd gezien

Een bericht slaagt voor DMARC als SPF of DKIM slaagt en het geauthenticeerde domein overeenkomt met het From-domein (alignment). Relaxed alignment, de standaard, accepteert een overeenkomst op het organisatiedomein, dus mail.example.eu komt overeen met example.eu. Strict alignment (adkim=s of aspf=s) vereist een exacte overeenkomst.

Bij externe verzenders gaat dit meestal mis. Een nieuwsbriefplatform gebruikt bijvoorbeeld een envelope-domein zoals bounces.platform.example. SPF slaagt dan voor het domein van het platform, maar dat domein komt niet overeen met example.eu, dus het draagt niets bij aan uw DMARC-resultaat.

De oplossing is om het platform met DKIM te laten ondertekenen met d=example.eu, of om een eigen return-path in te stellen op een van uw eigen subdomeinen. RFC 9989 raadt domeineigenaren aan zowel SPF als DKIM te gebruiken. Zo kan de ene het resultaat nog dragen als de andere faalt, bijvoorbeeld na doorsturen.

Hoe de records eruitzien

De voorbeelden hieronder gebruiken een IP-adres voor documentatie en een fictieve provider. Vervang ze door uw eigen waarden.

example.eu.                    TXT  "v=spf1 include:spf.mail-provider.example ip4:203.0.113.25 ~all"
s2026._domainkey.example.eu.   TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
_dmarc.example.eu.             TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.eu"

Het DMARC-record hierboven staat in monitoringmodus. Het vraagt om verzamelrapporten, maar vraagt geen actie voor e-mail die niet slaagt. Verzamelrapporten, inmiddels vastgelegd in RFC 9990, laten zien welke servers e-mail versturen met uw domein en of ze slagen.

Voor DKIM-sleutels schrijft RFC 6376 RSA-sleutels van minstens 1024 bits voor als ze lang worden gebruikt. Google eist minstens 1024 bits voor e-mail aan persoonlijke Gmail-accounts en raadt 2048 bits aan als uw provider dat ondersteunt.

Veilig van p=none naar p=reject

1. Breng elke verzender in kaart. Denk aan uw e-mailplatform, CRM, facturatie- en salarissystemen, helpdesk, webformulieren en apparaten zoals scanners die documenten mailen.
2. Stel SPF en DKIM in voor elke verzender. Vraag elke dienst om met DKIM te ondertekenen onder uw eigen domein, waar dat mogelijk is.
3. Publiceer p=none met een rua-adres. RFC 9989 beschrijft dit als het gebruikelijke beginpunt, zodat u verzenders vindt die u bij de inrichting over het hoofd hebt gezien.
4. Lees de rapporten en dicht de gaten. Neem er minstens enkele weken voor, en langer als u maandelijkse of driemaandelijkse verzendingen hebt, zoals salarisstroken of jaaroverzichten.
5. Ga naar p=quarantine en daarna naar p=reject. RFC 9989 heeft de oude tag pct geschrapt. In de plaats daarvan komt de testmodus: t=y vraagt ontvangers het beleid één niveau lager toe te passen, dus p=reject; t=y wordt behandeld als quarantaine.
6. Neem subdomeinen en geparkeerde domeinen mee. De tag sp bepaalt het beleid voor bestaande subdomeinen, en de nieuwe tag np geldt voor subdomeinen die niet bestaan.

Zie t=y als een verzachting, niet als een garantie. Zowel RFC 7489 als RFC 9989 schrijft ontvangers voor om tags te negeren die ze niet kennen. Een ontvanger die de nieuwe specificatie nog niet heeft overgenomen, kan uw gepubliceerde beleid dus volledig toepassen.

Bij stap 6 hoort een domein dat nooit e-mail verstuurt dat ook expliciet te zeggen. Publiceer een SPF-record dat niemand machtigt en een beleid met reject:

parked-example.eu.                              TXT  "v=spf1 -all"
_dmarc.parked-example.eu.                       TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.eu"
parked-example.eu._report._dmarc.example.eu.    TXT  "v=DMARC1"

Het derde record is nodig omdat de rapporten naar een ander domein gaan. RFC 9990 verplicht ontvangers om te controleren of het bestemmingsdomein heeft ingestemd met het ontvangen van rapporten voor het beleidsdomein, voordat ze die versturen.

Grote mailboxproviders verwachten dit werk al. Sinds 1 februari 2024 eist Google van bulkverzenders (meer dan 5000 berichten per dag naar Gmail) dat ze SPF, DKIM en DMARC met alignment gebruiken. Een beleid van p=none voldoet aan dat minimum, maar beschermt uw domein niet.

Veelgemaakte fouten

Twee SPF-records

Een domein mag maar één SPF-record publiceren. Vindt een ontvanger er meer dan één, dan is het SPF-resultaat permerror in plaats van pass. Voegt u een nieuwe dienst toe, neem de include daarvan dan op in het bestaande record in plaats van een tweede record aan te maken.

Meer dan tien DNS-lookups

RFC 7208 beperkt de evaluatie van SPF tot 10 termen die DNS-opvragingen veroorzaken: include, a, mx, ptr, exists en de modifier redirect. Includes die binnen uw includes zijn genest, tellen ook mee. Gaat u over de limiet, dan is het resultaat permerror.

De termen ip4, ip6 en all tellen niet mee, dus het helpt om uw eigen servers op adres op te sommen. Verwijder includes voor diensten die u niet meer gebruikt. De RFC stelt ook voor om "void lookups", opvragingen die geen antwoord opleveren, te beperken tot twee.

+all en ?all

Het mechanisme all komt altijd overeen, en de qualifier bepaalt het resultaat. +all machtigt dus elke server op het internet; publiceer het nooit. ?all geeft neutral, en volgens RFC 7208 moet dat precies zo worden behandeld als helemaal geen SPF-resultaat. Gebruik ~all (softfail) of -all (fail).

Welke van de twee? De oorspronkelijke DMARC-specificatie (RFC 7489, paragraaf 6.7) merkt op dat weigeren bij een SPF-fail voorkomt dat de ontvanger DKIM evalueert. Dat kan doorgestuurde e-mail schaden, waarbij SPF faalt maar de DKIM-handtekening nog geldig is. Zodra DMARC wordt gehandhaafd, laat ~all de uiteindelijke beslissing aan DMARC over.

Doorsturen en mailinglijsten vergeten

Een doorgestuurd bericht komt binnen vanaf het IP-adres van de doorstuurder, en dat staat niet in uw SPF-record. Een DKIM-handtekening overleeft doorsturen meestal als het bericht niet wordt gewijzigd. Mailinglijsten die het onderwerp aanpassen of een voettekst toevoegen, kunnen de handtekening echter breken. Daarom is betrouwbare DKIM-ondertekening onder uw eigen domein belangrijker dan SPF wanneer u naar p=reject gaat.

ptr gebruiken

Volgens RFC 7208 moet het mechanisme ptr niet worden gepubliceerd. Het is traag, minder betrouwbaar en telt toch mee voor de lookuplimiet.

Handhaven zonder rapporten te lezen

Wie direct naar p=reject springt, blokkeert al snel de eigen wachtwoordresets, facturen of supportantwoorden. De rapporten vertellen u welke verzenders u bent vergeten. Lees ze voordat u gaat handhaven, en blijf ze daarna lezen, want er komen steeds nieuwe diensten bij.

Waar u begint

• Controleer met onze e-mailbeveiligingscheck wat uw domein vandaag publiceert.
• Bouw of verbeter uw records met de SPF- en DMARC-generator.
• Noteer elk systeem dat e-mail verstuurt uit naam van uw domein. Die lijst hebt u nodig voordat u gaat handhaven.
• Publiceer nu p=none met een rapportageadres, en plan een datum om de eerste rapporten te beoordelen.
• Zet v=spf1 -all en een DMARC-record met p=reject op elk domein in uw bezit dat geen e-mail verstuurt.

Wilt u de analyse van de rapporten en de overstap naar handhaving liever uitbesteden? Onze dienst beheerde beveiliging kan bij beide helpen.