SPF, DKIM en DMARC instellen voor een betere deliverability

SPF, DKIM en DMARC instellen voor betere deliverability

Sinds februari 2024 eisen Google en Yahoo van bulkverzenders — meer dan 5.000 berichten per dag naar Gmail-adressen — dat DKIM en DMARC zijn geconfigureerd. Het zijn geen suggesties. Ontvangers die uw domein niet kunnen authenticeren, wijzen de post af of zetten die in spam. Dit artikel legt uit hoe u de drie protocollen opzet, in de juiste volgorde, zonder uw eigen mailverkeer te breken.

Vereisten

• Toegang tot de DNS-instellingen van uw domein.
• Root-toegang tot uw mailserver (Postfix, Exim of een ander platform dat DKIM-ondertekening ondersteunt).
• Een geldig TLS-certificaat voor uw mailserver — niet strikt nodig voor authenticatie, maar zonder versleuteling haalt uw post de inbox van grote providers niet.
• Kennis van de systemen die namens uw domein mail versturen. Maak een lijst voordat u begint: eigen server, marketingplatform, ticketingsysteem, alles.

Stap 1: Inventariseer alle verzendende systemen

Elke dienst die e-mail verstuurt met uw domein in de `From:`-header moet in de authenticatie worden opgenomen. Vergeet de transactionele berichten niet: wachtwoordherstel, facturen, notificaties. Die worden vaak over het hoofd gezien en juist die worden door providers streng gecontroleerd.

Maak een overzicht van:

• IP-adressen van uw eigen mailserver(s)
• Externe diensten (Mailchimp, SendGrid, Google Workspace, Microsoft 365)
• Eventuele subdomeinen die apart mail versturen

Zonder dit overzicht gaat u straks DMARC instellen en ontdekt u dat uw eigen facturen in de spam belanden.

Stap 2: Stel SPF in

Sender Policy Framework is een TXT-record in uw DNS dat aangeeft welke IP-adressen en diensten namens uw domein mogen verzenden. Eén record per domein — meerdere records leiden tot een permanente fout.

Maak een record als dit, vervang de waarden door uw eigen:

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com include:sendgrid.net ~all

`ip4` specificeert een IP-bereik, `include` verwijst naar een extern domein dat ook mag verzenden, `~all` betekent dat andere bronnen in quarantaine moeten, `-all` dat ze hard geweigerd moeten worden.

SPF kent een harde limiet van 10 DNS-lookups per controle. Elke `include` telt mee, en sommige includes van grote providers tellen meerdere keren. Overschrijdt u de limiet, dan faalt de SPF-controle automatisch — ook voor legitieme verzenders. Houd het record daarom zo kort mogelijk. Verwijder diensten die u niet meer gebruikt. Gebruik één `include` voor een provider in plaats van meerdere losse IP-adressen.

Stap 3: Configureer DKIM

DKIM voegt een cryptografische handtekening toe aan de header van elk bericht. De ontvanger haalt de bijbehorende publieke sleutel op uit uw DNS en valideert daarmee zowel de afzender als de integriteit van de inhoud. Is de mail onderweg aangepast, dan faalt de handtekening.

Genereer een sleutelpaar op uw mailserver. Op een systeem met OpenDKIM:

opendkim-genkey -s default -d example.com -b 2048

Dit maakt twee bestanden: `default.private` en `default.txt`. De publieke sleutel in `default.txt` plaatst u als TXT-record in uw DNS onder de selector `default._domainkey.example.com`.

Configureer uw mailserver om met de privésleutel te ondertekenen. Voor Postfix met OpenDKIM voegt u toe aan `/etc/opendkim.conf`:

Mode                sv
KeyFile             /etc/opendkim/keys/example.com/default.private
Selector            default
Canonicalization    relaxed/simple

Start daarna de diensten opnieuw:

systemctl restart opendkim postfix

Gebruik 2048-bit sleutels. Kortere worden door steeds meer providers als onvoldoende veilig beschouwd. Roteer uw selectors periodiek — als een sleutel lekt, beperkt u daarmee de schade.

Belangrijk is dat DKIM op alle uitgaande mail zit, niet alleen op uw nieuwsbrieven. Transactionele berichten moeten net zo goed ondertekend zijn.

Stap 4: Publiceer een DMARC-record met p=none

DMARC bouwt voort op SPF en DKIM en voegt twee dingen toe: een beleid voor berichten die de controles falen, en een eis voor alignment. Het domein in de `From:`-header moet overeenkomen met het domein dat door SPF (via `Return-Path`) of door DKIM (via de `d=`-tag) wordt gevalideerd. Zonder alignment faalt DMARC, ook als SPF en DKIM afzonderlijk slagen.

DMARC schrijft u als TXT-record op `_dmarc.example.com`. Begin altijd met `p=none`:

v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-failures@example.com; fo=1

`p=none` betekent dat er nog niets gebeurt met falende berichten — u ontvangt alleen rapporten. `rua` ontvangt samenvattingen van providers, `ruf` individuele mislukkingsrapporten.

Zonder DMARC-record handelen ontvangers zelf af wat ze met onherkenbare mail doen. Met een record — zelfs met `p=none` — geeft u aan dat u het domein beheert en krijgt u zicht op wie er namens u verstuurt.

Stap 5: Analyseer de rapporten

Laat `p=none` twee tot vier weken staan. De rapporten die binnenkomen via `rua` en `ruf` laten zien welke systemen mail versturen namens uw domein — inclusief bronnen die u niet kent. Die moet u ofwel toevoegen aan SPF en DKIM, ofwel als misbruik beschouwen.

Controleer per bron:

• Komt het IP-adres overeen met een systeem dat u beheert?
• Is de DKIM-handtekening geldig?
• Is er SPF-alignment?

Legitieme systemen die falen, moeten worden hersteld voordat u het beleid verscherpt. Een derde partij die namens u verstuurt zonder correcte configuratie, zorgt ervoor dat uw domein wordt gezien als bron van onherkenbare mail.

Stap 6: Verscherp naar p=quarantine en p=reject

Wanneer alle legitieme bronnen correct zijn geconfigureerd, gaat u naar `p=quarantine`:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-failures@example.com; fo=1

Falende berichten belanden nu in de spammap in plaats van de inbox. Laat dit opnieuw enkele weken staan en controleer of er klachten binnenkomen over gemiste berichten.

De laatste stap is `p=reject`:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-failures@example.com; fo=1

Nu worden falende berichten volledig afgewezen. Deze stap is in de praktijk onomkeerbaar: een systeem dat u over het hoofd hebt gezien, verliest onmiddellijk zijn vermogen om mail te leveren. De overstap naar `p=reject` mag pas als u wekenlang in de rapporten hebt gezien dat alleen ongeautoriseerde bronnen falen.

Verificatie

Controleer uw records met `dig`:

dig TXT example.com
dig TXT default._domainkey.example.com
dig TXT _dmarc.example.com

Stuur daarna een testbericht naar een adres dat u bij Google en Yahoo hebt aangemaakt en bekijk de headers:

grep -E "spf|dkim|dmarc" /path/to/raw-message.txt

U zoekt naar `spf=pass`, `dkim=pass` en `dmarc=pass`. Elke andere uitkomst betekent dat een van de stappen niet correct is uitgevoerd.

Veelgemaakte fouten

Meerdere SPF-records. DNS staat maar één SPF-record per domein toe. Meerdere records zorgen ervoor dat de controle faalt. Voeg alles samen in één TXT-record.

SPF-lookup-limiet overschreden. Elke `include` telt mee voor de limiet van 10 lookups. Controleer met:

dig TXT example.com | grep -o "include:" | wc -l

Blijf onder de limiet, anders faalt SPF structureel.

DKIM alleen op marketingmail. Transactionele berichten zonder DKIM-handtekening falen DMARC zodra u naar `p=reject` gaat. Onderteken alle uitgaande mail, niet alleen de campagnes.

Waar het van afhangt

De drie protocollen doen elk iets anders. SPF controleert welke server mag versturen, DKIM of de inhoud onderweg is aangepast, en DMARC bepaalt wat er gebeurt als een van beide faalt. Het is een keten: haal één schakel weg en de rest betekent minder.

De grootste fout is haast. Wie in één nacht van niets naar `p=reject` gaat, ontdekt binnen een week welke derde partij er nog stiekem namens het domein verstuurde. De gefaseerde aanpak — `none`, dan `quarantine`, dan `reject` — bestaat niet voor niets. De rapporten in de `none`-fase zijn het halve werk; wie die overslaat, configureert blind.

Providers maken de eisen steeds strenger. Wat in 2024 gold voor bulkverzenders naar Google en Yahoo, wordt voor iedereen de norm. Wie de protocollen nu opzet, heeft de rapporten al klaarliggen voordat de volgende eis eraan komt. Wie wacht tot het misgaat, heeft geen rapporten — alleen een lege inbox.