SPF, DKIM en DMARC instellen voor 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 jouw domein niet kunnen authenticeren, wijzen de post af of zetten die in spam. Dit artikel legt uit hoe je de drie protocollen opzet, in de juiste volgorde, zonder je eigen mailverkeer te breken.

Vereisten

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

Stap 1: Inventariseer alle verzendende systemen

Elke dienst die e-mail verstuurt met jouw 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 je eigen mailserver(s)
• Externe diensten (Mailchimp, SendGrid, Google Workspace, Microsoft 365)
• Eventuele subdomeinen die apart mail versturen

Zonder dit overzicht ga je straks DMARC instellen en ontdek je dat je eigen facturen in de spam belanden.

Stap 2: Stel SPF in

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

Maak een record als dit, vervang de waarden door je 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. Overschrijd je de limiet, dan faalt de SPF-controle automatisch — ook voor legitieme verzenders. Houd het record daarom zo kort mogelijk. Verwijder diensten die je 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 je 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 je 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` plaats je als TXT-record in je DNS onder de selector `default._domainkey.example.com`.

Configureer je mailserver om met de privésleutel te ondertekenen. Voor Postfix met OpenDKIM voeg je 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 je selectors periodiek — als een sleutel lekt, beperk je daarmee de schade.

Belangrijk is dat DKIM op alle uitgaande mail zit, niet alleen op je 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 schrijf je 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 — je 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` — geef je aan dat je het domein beheert en krijg je zicht op wie er namens jou 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 jouw domein — inclusief bronnen die je niet kent. Die moet je ofwel toevoegen aan SPF en DKIM, ofwel als misbruik beschouwen.

Controleer per bron:

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

Legitimate systemen die falen, moeten worden gerepareerd voordat je het beleid verscherpt. Een derde partij die namens jou verstuurt zonder correcte configuratie, zorgt ervoor dat jouw domein wordt gezien als bron van onherkenbare mail.

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

Wanneer alle legitieme bronnen correct zijn geconfigureerd, ga je 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 weer 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 onomkeerbaar in de praktijk: een systeem dat je over het hoofd hebt gezien, verliest per direct zijn vermogen om mail te leveren. De overstap naar `p=reject` mag pas als je wekenlang in de rapporten hebt gezien dat alleen ongeautoriseerde bronnen falen.

Verificatie

Controleer je 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 je bij Google en Yahoo hebt aangemaakt en bekijk de headers:

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

Je 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 je 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 liggen voordat de volgende eis eraan komt. Wie wacht tot het misgaat, heeft geen rapporten — alleen een lege inbox.