Home › Handleidingen

SPF, DKIM en DMARC instellen: records, valkuilen en controles

Gepubliceerd 2026-11-03 ／ Bijgewerkt 2026-11-03 ／ Door Yuki Nakazawa

SPF, DKIM en DMARC instellen is niet langer optioneel als u e-mail vanaf uw eigen domein verstuurt. Doe het in deze volgorde: publiceer één SPF-record, schakel DKIM-ondertekening in met een 2048-bits sleutel en publiceer daarna een DMARC-record dat begint bij p=none, met rapportage ingeschakeld. Zorg er meteen ook voor dat het IP-adres dat uw mail verstuurt een overeenkomende reverse DNS (PTR) heeft.

Deze handleiding werkt of u nu verstuurt vanaf shared hosting, uw eigen VPS, Google Workspace, Microsoft 365 of een bulkmaildienst. U krijgt records die u kunt aanpassen, de fouten die authenticatie het vaakst breken en de manier om aan de header van een echt bericht te controleren of alles werkt.

De feiten hieronder zijn gecontroleerd aan de hand van de RFC's en de officiële pagina's van Google, Yahoo en Microsoft zoals die in november 2026 waren. De vereisten van mailproviders veranderen, dus hun pagina's hebben het laatste woord.

Wat SPF, DKIM en DMARC elk aantonen, en in welke volgorde u ze instelt

Met SPF (Sender Policy Framework) kan een domein in DNS vastleggen welke servers zijn mail mogen versturen. De ontvangende server kijkt naar de envelope sender (het SMTP MAIL FROM-adres, dat later als Return-Path zichtbaar wordt), haalt het SPF-record van dat domein op en controleert of het IP-adres dat verbinding maakt op de lijst staat. Op zichzelf zegt SPF niets over het From-adres dat de lezer ziet.

DKIM (DomainKeys Identified Mail) voegt aan elk bericht een cryptografische handtekening toe. Het verzendende systeem ondertekent met een privésleutel en ontvangers controleren de handtekening met een openbare sleutel die in DNS is gepubliceerd. Een geldige handtekening bewijst dat het ondertekenende domein (de waarde d=) verantwoordelijkheid voor het bericht heeft genomen en dat de ondertekende headers en tekst onderweg niet zijn gewijzigd.

DMARC (Domain-based Message Authentication, Reporting and Conformance) koppelt die twee aan het zichtbare From-domein. Een bericht slaagt alleen voor DMARC als SPF of DKIM slaagt en het geauthenticeerde domein in lijn is met het From-domein. Het DMARC-record vertelt ontvangers ook wat u met mislukte berichten wilt laten doen (niets, quarantaine of weigeren) en waar ze verzamelrapporten heen moeten sturen. Zo ontdekt u verzendbronnen die u vergeten was.

Volgorde van instellen

1. Maak een lijst van alle systemen die mail namens uw domein versturen: uw eigen server, Google Workspace of Microsoft 365, nieuwsbrief- en transactionele maildiensten, webformulieren, facturatie- en helpdesksoftware.
2. Publiceer één SPF-record dat ze allemaal dekt.
3. Schakel DKIM in op elk verzendend systeem en publiceer de openbare sleutel.
4. Publiceer DMARC met p=none en een rapportageadres in rua. Google raadt aan na het instellen van SPF en DKIM 48 uur te wachten voordat u DMARC toevoegt.
5. Lees de rapporten, herstel bronnen die mislukken en ga daarna over op p=quarantine en uiteindelijk p=reject.

SPF instellen: één record, tien lookups

SPF is een TXT-record op het domein zelf. Hier is een domein dat vanaf een eigen server via IPv4 en IPv6 verstuurt en ook Google Workspace gebruikt:

example.com.  3600  IN  TXT  "v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:_spf.google.com ~all"

In de meeste DNS-beheerpanelen laat u het hostveld leeg (of vult u @ in), kiest u TXT en plakt u de waarde vanaf v=spf1. Veelgebruikte bouwstenen:

Valkuilen bij SPF

• Eén SPF-record per naam. RFC 7208 verbiedt meerdere SPF-records voor hetzelfde domein; ontvangers geven dan permerror en SPF mislukt voor alles. Voegt u een dienst toe, bewerk dan het bestaande record en voeg de include: daaraan toe in plaats van een tweede v=spf1-record aan te maken.
• De limiet van 10 lookups. De mechanismen include, a, mx, ptr en exists en de modifier redirect veroorzaken elk DNS-lookups, en het totaal over de hele evaluatie, inclusief lookups binnen geneste includes, mag niet hoger zijn dan 10. Gaat u daarboven, dan krijgt u permerror. ip4:, ip6: en all kosten niets. RFC 7208 zegt ook dat ontvangers moeten stoppen na twee lookups die geen antwoord opleveren, dus verwijder includes van diensten die u niet meer gebruikt.
• ~all tegenover -all. -all betekent dat bronnen die niet vermeld zijn niet gemachtigd zijn (fail); ~all betekent dat ze waarschijnlijk niet gemachtigd zijn (softfail). Google raadt ~all aan voor Workspace-domeinen; Microsoft raadt -all aan voor Microsoft 365-domeinen die ook DKIM en DMARC gebruiken. Weet u nog niet zeker of u alle afzenders hebt gevonden, begin dan met ~all en laat DMARC de handhaving doen.
• Subdomeinen hebben een eigen record nodig. Het SPF-record op example.com geldt niet voor news.example.com. Als u een bulkmaildienst op een eigen subdomein zet, krijgt die bovendien een apart budget van 10 lookups en blijft de reputatie gescheiden van de mail van uw medewerkers.
• Syntaxfouten. Microsoft noemt de gebruikelijke: include= in plaats van include:, een spatie na de dubbele punt en een punt achter het opgenomen domein.

Publiceer voor domeinen die nooit mail versturen v=spf1 -all, zodat ze moeilijker te vervalsen zijn.

DKIM instellen: 2048-bits sleutels en selectors

DKIM bestaat uit twee helften: het verzendende systeem ondertekent met een privésleutel en DNS publiceert de bijbehorende openbare sleutel. Bij Google Workspace, Microsoft 365, de meeste hostingbeheerpanelen en de meeste maildiensten genereert u de sleutel in de beheerconsole en kopieert u de DNS-waarde die daar wordt getoond.

Sleutellengte en selectors

Gebruik een RSA-sleutel van 2048 bits. RFC 8301 stelt 1024 bits als minimum en zegt dat ondertekenaars minstens 2048 bits zouden moeten gebruiken; ook verbiedt de RFC rsa-sha1. Het advies van Google sluit daarbij aan: kies 2048 bits als uw DNS-host dat ondersteunt en val alleen terug op 1024 als dat niet zo is.

De selector is een label dat aangeeft met welke sleutel een bericht is ondertekend, zodat een domein meerdere sleutels tegelijk kan hebben: één per verzenddienst of één per rotatieperiode. De openbare sleutel staat op selector._domainkey.yourdomain. Google Workspace gebruikt google als standaardselector. Microsoft 365 gebruikt twee CNAME-records, selector1._domainkey en selector2._domainkey, die verwijzen naar sleutels die Microsoft host; neem de exacte doelen over uit de Defender-portal of uit Get-DkimSigningConfig, want het formaat verschilt per tenant.

Een lange openbare sleutel publiceren

Een openbare sleutel van 2048 bits is langer dan de 255 tekens die in één DNS-character-string zijn toegestaan. In zonebestandsvorm schrijft u hem daarom als meerdere strings tussen aanhalingstekens in één TXT-record:

selector1._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA(first part of your key)"
    "(rest of your key)IDAQAB" )

Vervang de delen tussen haakjes door uw eigen sleutel. Ontvangers voegen de strings zonder spaties samen, dus u kunt overal binnen de sleutel splitsen. Veel beheerpanelen splitsen lange waarden automatisch: plak eerst de hele waarde en splits alleen zelf als het paneel die weigert. Let erop dat er bij het kopiëren niets verloren gaat; een lege p= betekent dat de sleutel is ingetrokken.

Op uw eigen VPS met Postfix of een vergelijkbare MTA kan een ondertekenende milter zoals OpenDKIM het sleutelpaar aanmaken, bijvoorbeeld met opendkim-genkey -b 2048 -s selector1 -d example.com. Publiceer de inhoud van het gegenereerde bestand met de openbare sleutel zoals hierboven.

Controleer of berichten echt worden ondertekend

Open een bericht dat u hebt verzonden en zoek naar een header DKIM-Signature:. De tag d= hoort uw domein te zijn en s= de selector die u hebt gepubliceerd. Veel maildiensten ondertekenen standaard met hun eigen domein; dat slaagt voor DKIM maar is niet in lijn met uw From-domein, dus het helpt niet voor DMARC. Schakel de authenticatie met een eigen domein (custom domain) van de dienst in, zodat d= uw domein wordt.

DMARC instellen: begin bij p=none en handhaaf daarna

DMARC is een TXT-record op _dmarc onder uw domein. Begin in monitormodus, waarin u ontvangers vraagt niets te veranderen aan de afhandeling van uw mail, en vraag om verzamelrapporten:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Verzamelrapporten (aggregate reports) zijn machineleesbare overzichten van welke IP-adressen mail namens uw domein hebben verstuurd en of die is geslaagd; Google raadt een aparte mailbox of groep aan om ze te ontvangen. Zodra de rapporten laten zien dat elke legitieme bron met alignment slaagt, maakt u het beleid strenger door hetzelfde record te bewerken, niet door een tweede toe te voegen:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Alignment, in gewone taal

Om voor DMARC te slagen, moet ten minste SPF of DKIM slagen voor een domein dat overeenkomt met het From-domein. In relaxed-modus moeten de organisatiedomeinen overeenkomen, dus een DKIM-handtekening met d=example.com is in lijn met mail van alerts@news.example.com. Strict-modus vereist een exacte overeenkomst. Maildiensten gebruiken vaak hun eigen domein in het Return-Path, dus SPF is dan niet in lijn, zelfs als het slaagt; DKIM met alignment is de praktische manier om die berichten door DMARC te krijgen.

Wilt u een ander beleid voor subdomeinen, voeg dan sp= toe. Met p=reject; sp=quarantine wordt bijvoorbeeld mislukte mail van het hoofddomein geweigerd, terwijl mislukte mail van subdomeinen alleen in quarantaine gaat.

Een opmerking over de bijgewerkte standaard

In mei 2026 is DMARC opnieuw gepubliceerd als RFC 9989, die RFC 7489 vervangt. Bestaande records blijven werken en beginnen nog steeds met v=DMARC1. De nieuwe standaard schrapt de tag pct, die behalve bij 0 of 100 zelden nauwkeurig werd toegepast, en voegt tags toe zoals t=y (testmodus) en np (beleid voor niet-bestaande subdomeinen). Sommige Help-pagina's van providers tonen nog pct; de minst dubbelzinnige manier om handhaving in te voeren is daarom stap voor stap de waarden van p= te doorlopen.

Reverse DNS (PTR) voor uw verzendende IP-adres

Reverse DNS koppelt een IP-adres terug aan een hostnaam. Google eist van alle afzenders naar persoonlijke Gmail-accounts een PTR-record waarvan de hostnaam terugverwijst naar hetzelfde verzendende IP-adres, en Yahoo eist geldige forward en reverse DNS voor verzendende IP-adressen en raadt een betekenisvol, niet-generiek PTR-record aan.

203.0.113.10       PTR  mail.example.com.
mail.example.com.  A    203.0.113.10

Het PTR-record staat niet in de zone van uw domein. De eigenaar van het IP-adres beheert het, dus op een VPS stelt u het in via het configuratiescherm van de provider (vaak reverse DNS of rDNS genoemd) en maakt u daarna een overeenkomend A-record (AAAA voor IPv6) aan in uw eigen DNS. Verstuurt u via IPv6, dan heeft het IPv6-adres dezelfde behandeling nodig. Bij Google Workspace, Microsoft 365, maildiensten en de meeste shared hosting beheert de provider de verzendende IP-adressen en hun reverse DNS voor u.

Zo controleert u uw configuratie

Lees Authentication-Results

Stuur een testbericht naar een externe mailbox en bekijk de volledige headers. Open in Gmail het bericht en kies Origineel weergeven. De DKIM-Help van Google merkt op dat u naar een andere gebruiker moet sturen en niet naar uzelf. Zoek naar een header zoals deze:

Authentication-Results: mx.example.net;
       dkim=pass header.i=@example.com header.s=selector1;
       spf=pass smtp.mailfrom=example.com;
       dmarc=pass header.from=example.com

De precieze opmaak verschilt per ontvanger. Waar het om gaat is spf=pass, dkim=pass en dmarc=pass, met uw eigen domein in header.i of header.d en in header.from. Slaagt SPF voor het domein van een dienst maar toont DKIM een ander domein, dan mislukt DMARC: herstel eerst de DKIM-alignment.

Raadpleeg DNS rechtstreeks

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short -x 203.0.113.10

Op Windows doet nslookup -type=TXT _dmarc.example.com hetzelfde. Het kan even duren voordat DNS-wijzigingen overal zijn doorgevoerd; volgens Google kan het voor SPF en DKIM elk tot 48 uur duren voordat ze werken. Gratis online checkers kunnen uw records ook ontleden en de SPF-lookups voor u tellen.

Slaagt de authenticatie en bouncet mail toch of komt die in spam terecht, controleer dan met onze blacklistchecker of uw verzendende IP-adres of domein op een DNSBL staat, en lees e-mail komt niet aan door een blacklist voor de volgende stappen.

Afzendervereisten van Gmail, Yahoo en Outlook.com

De grote mailproviders handhaven inmiddels authenticatie. Per november 2026 staat op hun officiële pagina's het volgende.

• Gmail (van kracht sinds 1 februari 2024): iedereen die naar persoonlijke Gmail-accounts verstuurt, heeft SPF of DKIM nodig, overeenkomende forward en reverse DNS, een TLS-verbinding en een spampercentage onder 0,3% in Postmaster Tools. Afzenders van meer dan 5.000 berichten per dag hebben daarnaast zowel SPF als DKIM nodig, een DMARC-record (p=none is voldoende), een From-domein dat in lijn is met SPF of DKIM, en afmelden met één klik voor marketingmail. DKIM-sleutels moeten minstens 1024 bits zijn; 2048 wordt aanbevolen.
• Yahoo (handhaving vanaf februari 2024): alle afzenders hebben SPF of DKIM nodig, geldige forward en reverse DNS en een spampercentage onder 0,3%. Bulkafzenders hebben zowel SPF als DKIM nodig, een DMARC-beleid van minstens p=none dat slaagt, From-alignment (relaxed volstaat), een werkende afmelding met één klik en geldige forward en reverse DNS voor de verzendende IP-adressen.
• Outlook.com (de consumentendienst achter outlook.com, hotmail.com en live.com): domeinen die meer dan 5.000 e-mails per dag versturen, moeten slagen voor SPF en DKIM en DMARC publiceren van minstens p=none, in lijn met SPF of DKIM. Microsoft heeft aangegeven dat berichten die niet aan de regels voldoen vanaf 5 mei 2025 worden geweigerd met de fout 550; 5.7.515.

Lees de volledige tekst in de richtlijnen voor e-mailafzenders van Google, de best practices voor afzenders van Yahoo en de aankondiging van Microsoft voor Outlook.com. Ook als u veel minder berichten verstuurt, voorkomt u door alle drie nu in te stellen dat een lagere drempel u later overvalt. Voor probleemoplossing die specifiek over Gmail gaat, zie Gmail levert uw e-mail niet af.

Veelgemaakte fouten

• Een tweede SPF-record. Een nieuw v=spf1-record per dienst toevoegen maakt SPF voor het hele domein ongeldig. Voeg alles samen in één record.
• Te veel includes. Oude diensten die in SPF zijn blijven staan, eten het budget van 10 lookups op. Verwijder wat u niet meer gebruikt en verplaats bulkmail naar een subdomein.
• Sleutel gepubliceerd, ondertekening niet ingeschakeld. In Google Workspace moet u, nadat het DNS-record actief is, nog op Verificatie starten klikken; andere platforms hebben een vergelijkbare schakelaar.
• De dienst ondertekent met zijn eigen domein. SPF en DKIM slagen allebei, DMARC mislukt. Schakel ondertekening met een eigen domein in.
• Meteen naar p=reject gaan. Een vergeten webformulier of facturatiesysteem levert dan van de ene op de andere dag niets meer af. Begin bij p=none en lees de rapporten.
• Schade door kopiëren en plakken. Extra aanhalingstekens in de waarde, een afgekapte sleutel, of een hostnaam die eindigt als _dmarc.example.com.example.com omdat het paneel het domein zelf toevoegt. Een snelle dig brengt dit allemaal aan het licht.

Veelgestelde vragen

Gebruikte officiële pagina's

De feiten in dit artikel zijn bij publicatie gecontroleerd aan de hand van de officiële pagina's hieronder. Beleid en werkwijze kunnen zonder aankondiging veranderen. Controleer daarom de officiële pagina's voordat u ergens belangrijks op vertrouwt.

• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9989: DMARC (obsoletes RFC 7489)
• Google: Email sender guidelines
• Google Workspace: Set up SPF
• Google Workspace: Set up DKIM
• Google Workspace: Set up DMARC
• Yahoo Sender Hub: Sender Best Practices
• Microsoft Community Hub: Outlook's New Requirements for High-Volume Senders
• Microsoft Learn: Set up SPF for your Microsoft 365 domain
• Microsoft Learn: How to use DKIM for email in your custom domain

Gerelateerde handleidingen

Alle handleidingen →