DMARC is een TXT-record op _dmarc.<your domain> dat ontvangende servers vertelt wat ze moeten doen met mail die jouw domein in de From-header gebruikt maar zowel de SPF- als de DKIM-controle met alignment niet doorstaat, en waar ze rapporten naartoe moeten sturen. p=none vraagt alleen om rapporten, p=quarantine vraagt ontvangers om falende mail als verdacht te behandelen, en p=reject vraagt ze die te weigeren.

Gmail, Yahoo en Microsoft accepteren p=none van bulkverzenders, dus veel domeinen publiceren dat en laten het daarbij: ze krijgen rapporten over spoofers, maar blokkeren ze niet. Uit de analyse van Red Sift van 73,3 miljoen domeinen, aangehaald in april 2026, bleek dat 14,9% überhaupt een DMARC-beleid had en 2,5% p=reject handhaafde. EasyDMARC, ook een DMARC-leverancier, meldde in 2025 dat 62,7% van de Fortune 500-bedrijven met DMARC p=reject gebruikte, tegenover 15,2% van de Inc. 5000-bedrijven.

Hier is een plan van 30 dagen naar p=reject, record voor record, voor een domein dat mail verstuurt vanuit zakelijke mailboxen, een of twee ESP’s, een helpdesk en een factureringstool. Dertig dagen past bij een verzendsubdomein. Een domein dat je medewerkers voor hun dagelijkse mail gebruiken, heeft meer tijd nodig.

De belangrijkste punten

• Publiceer op dag 1 v=DMARC1; p=none; rua=mailto:.... Zonder rua mogen ontvangende servers geen geaggregeerde rapporten sturen.
• Elke legitieme afzender moet slagen voor SPF of DKIM met alignment op je From-domein. Voor de meeste tools betekent dat: DKIM-ondertekening met jouw domein.
• Houd SPF binnen 10 termen die een DNS-lookup vereisen, geneste includes meegeteld, anders krijgt al je mail permerror.
• Ga op dag 15 naar p=quarantine en op dag 22 naar p=reject, telkens na een week met schone rapporten. Voor een domein dat medewerkers voor hun dagelijkse mail gebruiken, vraagt RFC 9989 om een maand voor elk van de eerste twee fases.
• RFC 9989 (mei 2026) markeert pct als historisch. Sla de opbouw via pct=10 en pct=50 over.
• BIMI vereist p=quarantine of p=reject op het organisatiedomein, geen sp=none, een logo in SVG Tiny PS en, voor Gmail, een VMC of CMC.

Wat er in 2026 veranderde aan DMARC

In mei 2026 verving de IETF RFC 7489, een informatief document (Informational) uit 2015, door DMARCbis: RFC 9989, een Proposed Standard die ook RFC 9091 vervangt, plus RFC 9990 voor geaggregeerde rapportage. Drie veranderingen zijn hier van belang:

• pct is historisch. Bijlage A.6 zegt dat de tag “meestal niet nauwkeurig werd toegepast, tenzij de opgegeven waarde 0 of 100 was”.
• t=y vervangt pct=0. Ontvangers passen dan één niveau lager toe dan je beleid, dus p=reject; t=y werkt als quarantine. Het is een testschakelaar.
• np is nieuw. Deze tag geldt voor subdomeinen die niet in de DNS bestaan, en oudere ontvangers moeten hem negeren.

Voor het bepalen van het organisatiedomein vervangt een DNS tree walk bovendien de Public Suffix List.

De drie records waar DMARC op steunt

DMARC slaagt als SPF of DKIM slaagt en het geslaagde domein in lijn is met het From-domein. Eén geslaagde controle met alignment is genoeg.

SPF en de limiet van 10 lookups

SPF autoriseert servers voor het envelopedomein (MAIL FROM of return-path), de enige identiteit die DMARC gebruikt, niet HELO. RFC 7208, sectie 4.6.4 beperkt het aantal termen dat een DNS-lookup vereist tot 10: include, a, mx, ptr, exists en redirect, geteld door alle geneste includes heen. ip4, ip6 en all tellen niet mee. Ga je erboven, dan is het resultaat permerror. Dezelfde sectie staat ook maximaal twee “void lookups” toe, meestal een include voor een hostnaam die niet meer bestaat.

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:_spf.helpdesk.example include:mail.billing.example ~all"

Daarmee zitten er al 4 lookups op voordat je meetelt wat elke leverancier nest, dus los ze allemaal op met dig +short TXT <name>, de hele keten af. Om binnen de 10 te blijven, schrap je tools die je niet meer gebruikt of geef je elke ESP een eigen return-path-subdomein, zoals bounce.example.com, met een eigen budget van 10. De SPF-handleiding van Microsoft raadt aan om te eindigen met -all op domeinen die ook DKIM en DMARC gebruiken.

Veel ESP’s gebruiken standaard hun eigen return-path-domein, en dat is niet in lijn met het jouwe. Stel een eigen return-path in of vertrouw op DKIM.

DKIM: 2048-bitsleutels, selectors en rotatie

DKIM ondertekent elk bericht met een domein d= en een selector s=; de ontvangende server haalt de sleutel op bij <selector>._domainkey.<d domain>. Een tool die ondertekent met d=vendor-mail.example slaagt voor DKIM en zakt voor DMARC.

Volgens RFC 8301 moeten ondertekenaars RSA-sleutels van minstens 1024 bits gebruiken, en zouden ze 2048 bits moeten gebruiken. De richtlijnen van Google voor afzenders zeggen hetzelfde voor mail naar persoonlijke Gmail-accounts. Een sleutel van 2048 bits is langer dan de limiet van 255 tekens voor een TXT-string, dus je zet hem als meerdere strings tussen aanhalingstekens in één record. De meeste DNS-hosts splitsen dat voor je op.

s202610._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1x..."
    "...remainder-of-the-2048-bit-key...IDAQAB" )

Geef elk verzendsysteem een eigen selector en gebruik een naam nooit opnieuw. Een datum, zoals s202610, houdt de geschiedenis leesbaar. Volgens de praktijken voor sleutelrotatie van M3AAWG roteer je minstens elke zes maanden:

1. Publiceer de nieuwe selector en wacht tot die is doorgevoerd.
2. Schakel de ondertekening over op de nieuwe sleutel.
3. Laat de oude publieke sleutel 7 tot 30 dagen in de DNS staan, zodat mail die nog onderweg is kan worden geverifieerd.
4. Zet de oude selector buiten gebruik met een lege p=. Verwijder hem niet.

Alignment: relaxed of strict

RFC 9989 definieert twee modi:

RFC 9989 merkt op dat “bijna alle domeineigenaren relaxed alignment voldoende hebben gevonden”. Laat aspf en adkim weg. Strikte SPF-alignment breekt het gebruikelijke return-path op een subdomein.

Het 30-dagenplan

Het record voor elke fase. Ga pas door na een week met schone rapporten.

Duikt er in week 2 een bron op die niemand kan repareren, blijf dan op p=none. Je eigen facturen weigeren is erger dan later handhaven.

Dag 1 tot en met 7: publiceer p=none met rapportage

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

Rapporten zijn met gzip gecomprimeerde XML-bestanden, minstens dagelijks van elke ontvangende server, dus laat rua naar een rapportverwerker wijzen, niet naar een persoon. Staat het adres op een ander organisatiedomein, dan negeren ontvangers het volgens RFC 9990, tenzij example.com._report._dmarc.<report domain> het autoriseert. Rapportverwerkers publiceren dat record zelf; voor je eigen domeinen voeg je het zelf toe.

Publiceer precies één DMARC-record. Laten installatiewizards twee v=DMARC1-records achter op _dmarc.example.com, dan negeren ontvangers ze allebei.

Sla ruf over. RFC 9989 merkt op dat privacybewuste ontvangers foutrapporten zwaar redigeren of helemaal niet versturen, en volgens de FAQ in de aankondiging van Microsoft voor afzenders met hoge volumes stuurt Microsoft wel rua-rapporten, maar is het niet van plan ruf te sturen.

Zo lees je een geaggregeerd rapport

RFC 9990 beschrijft XML-rapporten die “dagelijks (of vaker)” komen, één per beleidsdomein. Hier is één record, aangepast van het voorbeeld in de RFC:

<record>
  <row>
    <source_ip>192.0.2.123</source_ip>
    <count>123</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>bounces.vendor.example</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>vendor.example</domain>
      <selector>abc123</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounces.vendor.example</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

In policy_evaluated zijn dkim en spf de resultaten van de alignment, en disposition is wat de ontvangende server deed. auth_results bevat de ruwe resultaten en hun domeinen. Hier slagen beide voor vendor.example, dus zakken ze allebei voor alignment: een leverancier die namens jou verstuurt zonder namens jou te ondertekenen. Zet de aangepaste DKIM of domeinauthenticatie van die leverancier aan.

Dag 1 tot en met 7: vind de onbekende afzenders

Groepeer op source_ip, envelope_from en het DKIM-veld domain plus selector, sorteer op count en deel de resultaten zo in:

Om te achterhalen bij wie een IP-adres hoort, voer je dig -x 192.0.2.123 +short uit en bekijk je de selector, die vaak de naam van de leverancier bevat. Vraag daarna aan de financiële afdeling, support en sales wat er allemaal namens het bedrijf verstuurt: facturering, helpdesk, agenda-uitnodigingen, kantoorscanners.

Doorgestuurde mail en mail van mailinglijsten zullen falen op manieren die je niet kunt repareren, en de FAQ voor afzenders van Google eist daarvoor geen alignment, dus wacht daar niet op.

Dag 8 tot en met 14: repareer elke legitieme bron

Werk van de hoogste count naar beneden:

1. Zakelijke mail (Google Workspace, Microsoft 365). Zet DKIM aan in de beheerconsole, met 2048 bits waar dat kan, en controleer of de include van de provider in je SPF-record staat.
2. ESP’s en marketingtools. Stel domeinauthenticatie in, zodat ze ondertekenen met jouw d=, plus een eigen return-path als dat wordt aangeboden.
3. Helpdesk, facturering, CRM. Hetzelfde als bij ESP’s. Kan een tool niet met jouw domein ondertekenen, gebruik dan een subdomein waarvoor hij dat wel kan, of het eigen domein van de tool.
4. Tools die je niet meer gebruikt. Verwijder hun includes en selectors.

Tel daarna je SPF-lookups opnieuw.

Dag 15: p=quarantine

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

Quarantaine betekent meestal de spammap. Let op legitieme bronnen met de disposition quarantine. Wil je eerst oefenen, dan vraagt p=quarantine; t=y ontvangers die RFC 9989 volgen om none toe te passen, al is de RFC pas een paar maanden oud en respecteert nog niet elke ontvanger t.

Dag 22: p=reject

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

Ontvangers die p=reject respecteren, weigeren falende mail al tijdens de SMTP-sessie, maar RFC 9989 zegt dat ze die in quarantaine moeten plaatsen als het beleid hun enige aanwijzing is, dus een deel belandt in de spammap.

Dezelfde RFC zegt dat een domein op p=reject “NIET uitsluitend op SPF MAG vertrouwen” en met DKIM moet ondertekenen, omdat doorsturen SPF breekt, maar DKIM niet. Controleer daarom eerst of elke bron DKIM met alignment heeft.

Laat rua voorgoed staan. De nieuwe tool van volgend kwartaal duikt eerder op in je rapporten dan in je supportwachtrij.

Wanneer je meer tijd neemt

Volgens RFC 9989, sectie 7.4, horen domeinen waarvan de gebruikers berichten op mailinglijsten plaatsen geen p=reject te publiceren (“SHOULD NOT”), en domeinen die dat toch doen, moeten eerst “minstens een maand” op p=none staan en “een even lange periode” op p=quarantine. Dat geldt voor de meeste hoofddomeinen van bedrijven, dus geef daar elk van de eerste twee fases een maand. Een subdomein dat alleen je ESP gebruikt, heeft geen verkeer van mailinglijsten en kan het tempo van 30 dagen aanhouden.

Beleid voor subdomeinen: sp= en np=

p geldt voor het domein en de subdomeinen ervan. sp overschrijft dat voor bestaande subdomeinen, np voor niet-bestaande. Een subdomein met een eigen record gebruikt dat record, en RFC 9989 negeert sp dan.

Een apart verzendsubdomein zoals mail.example.com, dat door één ESP wordt gebruikt met geverifieerde SPF en DKIM, kan vanaf dag één p=reject publiceren. p=none; sp=reject op het hoofddomein beschermt de subdomeinen terwijl je met het hoofddomein zelf bezig bent, maar blokkeert BIMI.

Geparkeerde domeinen horen volgens de SPF-handleiding van Microsoft v=spf1 -all te publiceren, plus v=DMARC1; p=reject; op _dmarc.

Dag 30 en daarna: BIMI

BIMI toont je logo naast geauthenticeerde mail in inboxen die het ondersteunen:

De BIMI-draft staat op revisie 14 (mei 2026) en is nog steeds een Internet-Draft die is geschreven op basis van RFC 7489, vandaar pct. Laat pct weg en zet geen t=y.

De regel voor het organisatiedomein is een valkuil voor afzenders op subdomeinen: met mail.example.com op p=reject en example.com op p=none mogen ontvangers het logo niet tonen, dus ook het hoofddomein moet het plan doorlopen.

De SVG-richtlijnen van de BIMI Group raden een vierkant, gecentreerd logo op een effen achtergrond aan, kleiner dan 32 KB. Google voegde in september 2024 ondersteuning voor CMC’s toe. Het record volgens de implementatiegids van de BIMI Group:

default._bimi.example.com.  3600  IN  TXT  "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/certificate.pem"

Een handelsmerk registreren duurt maanden, dus begin nu al met alles wat met een VMC te maken heeft.

Wat Gmail, Yahoo en Microsoft eisen

Geen van de drie eist handhaving, alleen een DMARC-record en alignment.

Bronnen: de richtlijnen van Google voor afzenders en de FAQ, de best practices van Yahoo voor afzenders, en de aankondiging van april 2025 en de supportpagina over 5.7.515 van Microsoft. Microsoft begon op 5 mei 2025 met handhaven, nadat een update van 29 april de actie had veranderd van verplaatsen naar de map Ongewenste e-mail in weigeren.

Volgens de FAQ van Google “wordt alignment met zowel SPF als DKIM uiteindelijk een vereiste voor afzenders”, dus zorg in week 2 voor alignment op allebei. Over afmeldingen en spamratio’s lees je meer in wat er nog steeds geldt als een agent je e-mail verstuurt en in onze gids over bezorgbaarheid.

DMARC op een verzenddomein in Brew

Bij het instellen van een domein in Brew heb je dit nodig:

• DKIM: een TXT-record op een ._domainkey-selector onder je verzenddomein. Vereist.
• SPF: een MX- en een TXT-record op send.<your sending domain>, het return-path van Brew. Vereist.
• DMARC: een TXT-record op _dmarc.<your sending domain>. Optioneel en aanbevolen.
• Een CNAME voor kliktracking, alleen bij een eigen trackingsubdomein.

Het domein kan versturen zodra SPF en DKIM zijn geverifieerd, en Brew stelt een passende DMARC-waarde voor:

; dedicated sending subdomain, e.g. mail.example.com
_dmarc.mail.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@mail.example.com"
 
; apex domain, or a domain Brew can't prove is dedicated
_dmarc.example.com.       TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Een apart subdomein krijgt p=reject, omdat er niets vanaf wordt verstuurd voordat de SPF en DKIM van Brew zijn geverifieerd. Een hoofddomein krijgt p=none, omdat je andere tools waarschijnlijk ook namens dat domein versturen; volg dan het plan hierboven. De alignment blijft relaxed, omdat het return-path send.<domain> alleen in de relaxed-modus in lijn is.

Brew leest het live record op _dmarc.<sending domain> bij het toevoegen, bij het verifiëren en bij elke nieuwe controle. Je ziet het resultaat onder Domeinen, en ook via get_domain_health over MCP en GET /v1/domains/{domainId}/health:

• dmarc_missing: een waarschuwing met het exacte record dat je moet toevoegen.
• dmarc_invalid: bij twee DMARC-records op dezelfde naam, of bij een ongeldige versie, een ongeldig beleid of dubbele tags. De melding noemt het record dat je moet verwijderen.
• Geverifieerd: zodra er precies één geldig record is gevonden.

De automatische DNS-instelling schrijft alleen een DMARC-record als er nog geen bestaat, dus er ontstaat nooit een dubbel record. De controle gebeurt op het verzenddomein, niet op het bovenliggende domein, dus geef elk verzendsubdomein een eigen record, ook dat voor transactionele mail als je de twee scheidt zoals de documentatie aanraadt. In je rua-verwerker lees je de rapporten en besluit je wanneer je naar reject gaat.

Veelgestelde vragen

Hoelang moet ik op p=none blijven voordat ik naar quarantine ga?

Tot een volledige week aan rapporten laat zien dat elke legitieme bron slaagt voor SPF of DKIM met alignment; voor een verzendsubdomein is dat meestal één tot twee weken. Voor een domein dat medewerkers voor hun dagelijkse mail gebruiken, vraagt RFC 9989 om minstens een maand. Twee jaar op p=none zonder dat iemand de rapporten leest, telt voor niets.

Is de pct-tag van DMARC verouderd?

Ja. RFC 9989 noemt pct “historisch” en vervangt de enige betrouwbare waarden ervan door t: t=y werkt als pct=0, t=n als pct=100. Oudere ontvangers lezen pct misschien nog, maar pasten tussenliggende waarden nooit consequent toe, dus ga in hele stappen.

Blokkeert p=reject mijn doorgestuurde e-mail?

Gewoon doorsturen breekt meestal SPF, maar niet DKIM, dus DKIM met alignment slaagt nog steeds. Mailinglijsten die het onderwerp of de footer aanpassen, breken DKIM, en sommige herschrijven de From-header om dat te compenseren. Overal DKIM met alignment is je beste bescherming.

Eisen Gmail en Yahoo p=reject?

Nee. Beide eisen dat bulkverzenders DMARC publiceren en accepteren p=none, net als Microsoft boven de 5.000 berichten per dag naar Outlook.com. Handhaving houdt spoofing tegen en is vereist voor BIMI, maar geen van de drie eist het.

Heb ik een VMC nodig voor BIMI?

Voor Gmail heb je een VMC nodig, waarvoor je een geregistreerd handelsmerk moet hebben en die een vinkje toont, of een CMC, die het logo zonder vinkje toont. Volgens de BIMI Group tonen een paar providers, waaronder Yahoo en Fastmail, ook logo’s zonder certificaat (self-asserted).