No DMARC record found: de ene regel die je domein mist

In het kort

• De melding betekent dat er geen TXT-record staat op _dmarc.yourdomain.com. Je mailserver is niet kapot.
• Voeg één TXT-record toe met de host _dmarc en de waarde v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Met p=none blijft de bezorging precies zoals die was.
• Gmail, Yahoo en Outlook.com eisen het record alleen van bulkafzenders. Voeg het toch toe: Google telt een heel domein en heft de bulkstatus nooit op, en rapporten komen pas zodra er een record bestaat.
• Vindt een checker nog steeds niets, zoek dan naar de verkeerde DNS-host, een dubbele hostnaam of twee DMARC-records. Twee records heffen elkaar op.
• De standaard is in mei 2026 veranderd met RFC 9989: pct is verdwenen, t en np zijn nieuw. De help van Google beschrijft pct nog steeds, stand oktober 2026.

‘No DMARC record found’ (geen DMARC-record gevonden) betekent dat een checker de DNS om een TXT-record op _dmarc.yourdomain.com heeft gevraagd en niets terugkreeg. Er is niets kapot aan je mailserver. De oplossing is één TXT-record met de host _dmarc en de waarde v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Met p=none wordt je mail precies zo bezorgd als voorheen. Je laat ontvangers alleen weten dat je meedoet, en je begint rapporten te krijgen.

DMARC is het derde van de drie e-mailrecords, naast SPF en DKIM. SPF somt de servers op die namens je domein mogen verzenden. DKIM ondertekent elk bericht. DMARC vertelt een ontvanger wat hij moet doen als geen van beide instaat voor het domein in je From-adres, en waar hij een dagelijkse samenvatting naartoe moet sturen. Sinds mei 2026 is het vastgelegd in RFC 9989, dat het oudere RFC 7489 heeft vervangen. Veel handleidingen beschrijven nog de oudere versie, en dat geldt ook voor de helppagina van Google, stand oktober 2026.

Het record dat je toevoegt

Log in waar de DNS van je domein wordt beheerd. Dat is het bedrijf waar je nameservers naar verwijzen, en dat is niet altijd het bedrijf waar je het domein hebt gekocht. Voeg een nieuw record toe met deze waarden:

Uitgeschreven als regel in een zonebestand ziet het voltooide record er zo uit:

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

Vervang example.com door je eigen domein. De drie onderdelen doen het volgende:

• v=DMARC1 markeert de regel als DMARC-record. Het moet vooraan staan, met DMARC1 in hoofdletters. Is dat niet zo, dan negeren ontvangers het hele record.
• p=none is het beleid: behandel mijn mail zoals je dat toch al zou doen. Door dit record wordt niets geblokkeerd of naar de spam verplaatst.
• rua=mailto:… is het adres voor de dagelijkse rapporten. Maak dat adres aan, of een alias die naar jou doorstuurt, voordat je het record publiceert.

Google noemt dezelfde drie velden in Set up DMARC. Het vraagt ook dat SPF en DKIM al 48 uur werken voordat je DMARC toevoegt. Meldt je checker ook die twee, los die dan eerst op.

Zo controleer je of het is gelukt

Vraag het zelf aan de DNS. Open op macOS of Linux een terminal en gebruik dig. Gebruik op Windows nslookup.

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com

Staat het record live, dan komt de regel tussen aanhalingstekens terug. Dit antwoordde het eigen domein van Google op 5 oktober 2026:

$ dig +short TXT _dmarc.google.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

Een leeg antwoord betekent dat het record er nog niet is, of niet staat waar ontvangers het zoeken. Laat je eigen query de regel zien, voer dan de checker die je de melding gaf opnieuw uit. MXToolbox formuleert het probleem bijvoorbeeld als ‘No DMARC Record found’ en legt uit dat ‘je domein geen gepubliceerd DMARC-record heeft’.

Wat elk onderdeel van een DMARC-record betekent

Een record is een lijst van tag=value-paren, gescheiden door puntkomma’s. In de standaard is alleen v verplicht, en die moet vooraan staan. Zet p op de tweede plaats: de help van Google zegt ‘De tags v en p moeten als eerste worden vermeld’, en de oudere standaard verwachtte dezelfde volgorde. Dit zijn de tags uit RFC 9989, sectie 4.7:

Oudere records eindigen vaak op pct=100. De tag was bedoeld om een beleid op een deel van de mislukte mail toe te passen. RFC 9989 heeft hem geschrapt, samen met rf en ri, en geeft de reden:

Uit de praktijk bleek dat de tag ‘pct’ meestal niet nauwkeurig werd toegepast, tenzij de opgegeven waarde 0 of 100 (de standaardwaarde) was, en de onnauwkeurigheden bij andere waarden liepen van implementatie tot implementatie sterk uiteen.

Ontvangers moeten tags negeren die ze niet kennen, dus een oude pct=100 kan geen kwaad. De records van yahoo.com en microsoft.com bevatten hem op 5 oktober 2026 nog, en de helppagina van Google raadt pct nog steeds aan voor een geleidelijke invoering. Laat hem in een nieuw record weg.

Heb je DMARC nodig als je maar een paar e-mails per dag verstuurt?

Volgens de gepubliceerde regels van de grote e-mailproviders is een DMARC-record verplicht zodra je in bulk verstuurt. Daaronder is het een aanbeveling.

De bronnen zijn de Email sender guidelines van Google, de Sender Best Practices van Yahoo en de aankondiging voor afzenders met een hoog volume van Microsoft, alle stand oktober 2026. Verstuur je dertig e-mails per dag vanuit één mailbox, dan eist geen van hen het record. Er zijn toch drie redenen om het nu toe te voegen.

• De drempel wordt per domein geteld, en hij wordt niet gereset. Google telt alle berichten aan persoonlijke Gmail-accounts die van hetzelfde primaire domein komen bij elkaar op, inclusief subdomeinen. De FAQ voor afzenders zegt: ‘Afzenders die ten minste één keer aan de bovenstaande criteria voldoen, worden permanent als bulkafzender beschouwd.’
• Zowel Google als Yahoo raadt het iedereen aan. Google schrijft: ‘we raden aan dat je altijd SPF, DKIM en DMARC instelt voor je domeinen’. Yahoo ‘dringt er bij alle afzenders sterk op aan een DMARC-beleid te publiceren voor elk domein dat mail verstuurt’.
• Zonder het record krijg je geen rapporten. Daarmee zie je welke servers mail versturen met jouw domein in de From-regel, zowel je eigen tools als vreemden.

Voor bulkafzenders heeft het ontbrekende record gevolgen. De FAQ voor afzenders van Google noemt er de tijdelijke fout 4.7.31 voor: ‘het verzenddomein heeft geen DMARC-record, of het DMARC-record geeft geen DMARC-beleid op’. Dezelfde pagina zegt dat mail die niet aan de eisen voldoet sinds november 2025 te maken krijgt met ‘tijdelijke en permanente weigeringen’.

Record toegevoegd, en de checker vindt nog steeds niets?

Dan is meestal een van deze dingen de oorzaak. Loop ze na met de dig-query van hierboven.

• Je hebt de DNS op de verkeerde plek aangepast. Staan je nameservers bij een ander bedrijf dan je registrar, dan worden records die je bij de registrar invoert nooit opgevraagd. dig +short NS example.com laat zien wie voor je domein antwoordt.
• De host klopt niet. Het record staat op example.com zelf, of op een dubbele naam, zoals hierboven beschreven. Ontvangers vragen alleen naar _dmarc.example.com.
• Er zijn twee DMARC-records. De standaard is hier streng: ‘Als voor één doel meerdere DMARC-beleidsrecords worden teruggegeven, worden ze allemaal verworpen.’ Voeg ze samen tot één. Twee rapportadressen komen in één rua, gescheiden door een komma.
• De eerste tag is niet precies v=DMARC1. Kleine letters, een typefout zoals DMARC 1, of p= ervoor maken het record ongeldig.
• Het recordtype is niet TXT, of de waarde is met gekrulde aanhalingstekens uit een document geplakt. Typ de waarde als platte tekst, zonder aanhalingstekens, tenzij de help van je DNS-host erom vraagt.
• Er zit nog een oud antwoord in de cache. Resolvers onthouden ‘dit record bestaat niet’ een tijdje. Vraag het rechtstreeks aan een van je eigen nameservers door de naam ervan aan de query toe te voegen, bijvoorbeeld dig +short TXT _dmarc.example.com @ns1.example.net. Is het record daar te zien, dan volgen de checkers vanzelf.

Waar de rapporten naartoe gaan, en wat je ermee doet

Elke ontvanger die mail kreeg met jouw domein in de From-regel, stuurt een rapport naar het rua-adres. Volgens de pagina About DMARC reports van Google worden ze ‘meestal één keer per dag per e-mail verstuurd’. Het rapport is een XML-bestand, meestal gecomprimeerd, als bijlage bij een e-mail. RFC 9990 beschrijft het formaat.

Google waarschuwt dat grote organisaties ‘dagelijks tot honderden of zelfs duizenden rapporten kunnen krijgen’ en raadt een groep of een aparte mailbox aan. Het aantal hangt af van hoeveel je verstuurt en naar hoeveel domeinen, dus één of twee mailboxen leveren er veel minder op. Een alias zoals dmarc@ met een filter naar een eigen map is genoeg.

Het adres hoort op hetzelfde domein te staan als het record. Wil je de rapporten ergens anders hebben, dan moet het andere domein daarmee instemmen door zelf een record te publiceren. Zonder dat record moeten ontvangers het adres negeren (RFC 9990, sectie 4).

example.com._report._dmarc.otherdomain.net.  IN  TXT  "v=DMARC1;"

Daarom werkt een gratis Gmail-adres niet als rapportadres: gmail.com publiceerde zo’n record niet toen we het op 5 oktober 2026 controleerden.

In het bestand staat elk record-blok voor één verzendende server: het IP-adres, het aantal berichten en onder policy_evaluated of DKIM en SPF voor jouw domein zijn geslaagd. Je zoekt twee dingen. Servers die je kent en die fail tonen, moeten worden gerepareerd; DMARC faalt terwijl SPF en DKIM slagen legt uit hoe. Servers die je niet kent, zijn een tool die je bent vergeten of iemand die jouw naam gebruikt.

Na p=none: wanneer je het beleid aanscherpt

p=none is een monitoringmodus. Het voldoet aan het minimum dat de e-mailproviders vragen, en het weerhoudt niemand ervan je adres te vervalsen. Dat doen alleen p=quarantine, dat ontvangers vraagt mislukte mail als verdacht te behandelen, en p=reject, dat vraagt die te weigeren.

Voordat je aanscherpt, moet elke legitieme bron van je mail slagen. RFC 9989 zegt dat zulke hiaten ‘MOETEN worden verholpen vóór elke poging’ tot handhaving, en dat het, afhankelijk van hoe vaak je verstuurt, ‘vele maanden kan duren’ voordat de rapporten zekerheid geven. De pagina over de invoering van Google vindt één week aan rapporten ‘meestal genoeg’. Met één mailbox en één of twee tools zit je dichter bij het cijfer van Google, maar neem er een paar weken voor, zodat ook de maandelijkse factuurrun en het contactformulier in beeld komen.

Over de stap zelf zijn de twee bronnen het niet eens. Google stelt nog steeds p=quarantine; pct=5 voor, met een oplopend getal. De standaard heeft pct laten vallen en biedt in plaats daarvan dit:

v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com

t=y vraagt ontvangers om mislukkingen voorlopig één niveau lager te behandelen, dus als none. Blijven de rapporten schoon, verwijder dan t=y. Houd er rekening mee dat een ontvanger die de tag niet kent hem negeert en quarantine volledig toepast, en dat de pagina’s van Google t niet noemen, stand oktober 2026. Zou een strenger beleid mail treffen die je nog niet kunt repareren, blijf dan op p=none.

Wat WarmupBay hier doet

Wanneer je een mailbox koppelt, controleert WarmupBay SPF, DKIM en DMARC van het domein. Ontbreekt het DMARC-record, dan toont het een kant-en-klaar record om te kopiëren. Je kunt de warmup toch starten. Ontbreken de records na 72 uur nog steeds, dan stopt de warmup.

WarmupBay kan het record niet voor je toevoegen, want je DNS is van jou, en het verzamelt of leest geen DMARC-rapporten. Wat het doet, is de stap na de records: je mailbox wisselt een paar e-mails per dag uit met andere mailboxen in een gedeelde pool, te beginnen met drie en elke dag één meer, zodat de verzendactiviteit geleidelijk wordt opgebouwd. Het is gratis voor 10 e-mails per dag. Bekijk wat de controle en de warmup omvatten, of koppel je mailbox zodra het record er staat.

Veelgestelde vragen

Dekt een DMARC-record op example.com ook subdomeinen zoals news.example.com?

Ja. Een ontvanger vraagt eerst naar een record op _dmarc.news.example.com. Is dat er niet, dan valt hij terug op het record van het organisatiedomein, example.com. Het beleid dat op het subdomein wordt toegepast, is dat in sp als je dat hebt ingesteld, en anders dat in p.

Kan ik v=DMARC1; p=none publiceren zonder rua-adres?

Ja. Dat is een geldig record, en het telt als een gepubliceerd beleid. Je krijgt geen rapporten, dus je ziet niet of je eigen mail slaagt of wie je domein nog meer gebruikt. Yahoo noemt een werkend rua-adres sterk aanbevolen, en Google raadt aan er altijd een op te nemen.

Heb ik een DMARC-record nodig voor een tweede domein dat ik alleen voor outreach gebruik?

Ja. Ontvangers zoeken het domein op uit het From-adres van elk bericht, dus een record op je hoofddomein dekt een ander domein niet. Gebruik dezelfde regel op het tweede domein. Moeten de rapporten naar een adres op je hoofddomein, dan moet het hoofddomein het autorisatierecord publiceren dat wordt beschreven onder ‘Waar de rapporten naartoe gaan’.

Wat moet een domein publiceren dat nooit e-mail verstuurt?

Het strenge paar. M3AAWG raadt voor domeinen die nooit mail versturen het SPF-record v=spf1 -all aan en een DMARC-record met p=reject, zodat niemand ze in een From-adres kan gebruiken. Voor DMARC is dat de regel v=DMARC1; p=reject op _dmarc.

Is p=none slechter voor mijn mail dan p=quarantine of p=reject?

De gepubliceerde afzenderregels van Gmail, Yahoo en Outlook.com vragen om ten minste p=none en niets strengers. Het beleid bepaalt wat er gebeurt met mail die niet door DMARC komt, en daar hoort vervalste mail op jouw naam bij. Eén functie vraagt meer: BIMI, het logo naast je berichten, vereist volgens de help van Google quarantine of reject.

Bronnen

1. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), May 2026
2. RFC 9990: DMARC Aggregate Reporting, May 2026
3. Email sender guidelines – Gmail Help
4. Email sender guidelines FAQ – Gmail Help
5. Set up DMARC – Google Workspace Help
6. Recommended DMARC rollout – Google Workspace Help
7. About DMARC reports – Google Workspace Help
8. Troubleshoot DMARC issues – Google Workspace Help
9. Sender Best Practices – Yahoo Sender Hub
10. Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders – Microsoft Community Hub
11. DMARC Record Published – MXToolbox
12. M3AAWG Email Authentication Recommended Best Practices, September 2020 (PDF)
13. M3AAWG Protecting Parked Domains Best Common Practices, December 2015 (PDF)