DMARC-record en beleid: configuratie, uitlijning en rapporten

Een geldig DMARC-record verdient in 2026 aandacht, vooral waar afzenderregels het vereisen. Google en Yahoo stellen eisen aan bepaalde bulkafzenders; Microsoft heeft eigen regels. Ontbrekende authenticatie kan filtering of weigering beïnvloeden, maar maakt niet iedere verzending automatisch onbruikbaar of onzichtbaar.

Een DMARC-record (Domain-based Message Authentication, Reporting, and Conformance) is een DNS TXT-record met beleid voor berichten die jouw zichtbare domein gebruiken maar niet via een uitgelijnde methode worden geauthenticeerd. Publiceer het onder _dmarc bij het werkelijke From-domein. Andere TXT-records mogen daarnaast bestaan, maar meerdere DMARC-beleidsrecords op dezelfde naam zijn ongeldig. Het bouwt voort op SPF en DKIM en vraagt ontvangers om een bepaalde behandeling; hun eigen beleid blijft gelden.

Een oprichter kan bezorgproblemen bij investeerders krijgen; een MSP met 500 domeinen kan vragen ontvangen over verdwenen QuickBooks-facturen. Beide moeten de werkelijke fout onderzoeken. Authenticatie helpt, maar garandeert geen inboxplaatsing op welke schaal dan ook.

Deze gids behandelt de werking van een DMARC-record, veelvoorkomende fouten en een gefaseerde route naar p=reject. Inventarisatie, tests en een terugvalplan verkleinen het risico voor legitieme mail; een foutloze overgang is niet gegarandeerd.

Wat een DMARC-record doet

Een DMARC-record publiceert authenticatiebeleid en rapportage-instellingen. Het scant geen inhoud en is geen algemene spamfilter. De vraag is: "Hoe wil ik dat de ontvanger omgaat met mail die mijn From-domein gebruikt maar geen succesvolle uitgelijnde authenticatie heeft?"

Vergelijk de infrastructuur met een evenement: SPF controleert verzend-IP's voor een envelopidentiteit, DKIM verifieert ondertekende inhoud en een ondertekenend domein, en DMARC verbindt die controles met het zichtbare domein en een beleidsverzoek. Zonder DMARC kunnen ontvangers nog steeds zelfstandig filteren of weigeren.

Met een DMARC-record weten Gmail en Outlook welk beleid je vraagt bij falende uitlijning. Dat vermindert onduidelijkheid, maar verplicht hen niet ieder bericht op dezelfde manier te behandelen. Ook een geslaagd resultaat garandeert geen aflevering.

De drie opties: de p=-tag

De p=-tag bevat het gevraagde beleid voor DMARC-falen. Andere velden regelen onder meer uitlijning, subdomeinen en rapportage en zijn eveneens belangrijk voor de werking.

p=reject kan een passend eindbeleid zijn, maar te snel overstappen is riskant. Een organisatie kan vervolgens een week factuurproblemen moeten onderzoeken; dit is een voorbeeld, geen bewezen beschrijving van de meeste implementaties.

Bereid de overgang daarom voor. De volgende onderdelen beschrijven een mogelijke route, geen universeel tijdschema.

Authenticatie met SPF, DKIM en DMARC

DMARC gebruikt SPF- en DKIM-resultaten met domeinuitlijning. Onvolledige inrichting kan bij handhaving legitieme stromen beïnvloeden. Beide zorgvuldig instellen biedt meer bruikbare authenticatieroutes, maar DMARC vereist niet dat beide tegelijk slagen.

De drie onderdelen werken zo samen:

SPF (Sender Policy Framework)

Functie: Autoriseert verzendende systemen voor het MAIL FROM-envelopdomein, of HELO in toepasselijke gevallen. Het controleert niet zelfstandig het zichtbare From-adres.

Beperking: Bij doorsturen kan SPF falen als de oorspronkelijke envelopafzender blijft staan en het IP-adres van de doorstuurserver niet geautoriseerd is. Dat gebeurt niet bij iedere doorstuurconfiguratie.

Zie SPF instellen voor de procedure, SPF voor e-mail voor de basis en SPF-opzoeklimieten oplossen voor relevante DNS-evaluatielimieten.

DKIM (DomainKeys Identified Mail)

Functie: Een handtekening in een berichtheader dekt geselecteerde headers en de ondertekende body. De ontvanger verifieert haar met een publieke sleutel in DNS volgens de gebruikte canonicalisatie.

Voordeel: DKIM kan doorsturen overleven als gedekte inhoud, sleutel en overige voorwaarden geldig blijven. Wijzigingen aan headers of body kunnen haar alsnog ongeldig maken; voor DMARC is uitlijning nodig.

DMARC (de beleidslaag)

De regel: DMARC slaagt bij succesvolle SPF die uitgelijnd is met Header From, of bij ten minste een geldige uitgelijnde DKIM-handtekening. Beide methoden inrichten is nuttig, maar één uitgelijnde succesvolle methode is voldoende.

Meer context staat in de instelvolgorde voor SPF, DKIM en DMARC.

Uitlijning begrijpelijk uitgelegd

SPF en DKIM kunnen afzonderlijk slagen terwijl DMARC faalt, ook met een syntactisch geldig record. Het verschil is welk domein werkelijk is geauthenticeerd.

Een bericht heeft onder meer deze twee afzenderidentiteiten:

• Header From: Het adres dat de ontvanger ziet, bijvoorbeeld support@yourcompany.com.
• Envelope From (Return-Path): Het technische adres voor bounces, dat een externe verzenddienst kan beheren.

DMARC vergelijkt Header From met het SPF-domein of het ondertekenende DKIM-domein. Relaxed alignment gebruikt het organisatiedomein; strict alignment vereist exact dezelfde domeinnaam. Falen volgt pas als geen geldige uitgelijnde methode slaagt.

Een klassiek voorbeeld: Mailchimp of een andere marketingdienst

Een illustratieve nieuwsbriefconfiguratie, niet noodzakelijk de huidige providerstandaard:

• Header From: news@yourcompany.com
• Return-Path: mail12.mailchimp.com als voorbeeldhost voor bounceverwerking, niet als volledig e-mailadres
• DKIM-handtekening: Ondertekend met d=mailchimp.com

De mogelijke evaluatie in dit voorbeeld:

• SPF gebruikt het daadwerkelijke envelopdomein binnen mailchimp.com en kan daarvoor slagen.
• DKIM voor mailchimp.com kan slagen.
• DMARC vergelijkt uitlijning: past yourcompany.com bij mailchimp.com? Nee.
• DMARC-resultaat zonder andere uitgelijnde succesvolle methode: Fail.

Beide losse controles kunnen dus slagen terwijl DMARC faalt. Dat is het uitlijningsprobleem, niet bewijs dat ieder standaard ESP-bericht faalt.

De aanpak: aangepaste domeinauthenticatie

Inventariseer marketingdiensten, CRM's en transactionele diensten en configureer waar ondersteund domeinauthenticatie voor de daadwerkelijk gebruikte stromen:

• SPF-uitlijning: Richt een eigen bouncedomein in, bijvoorbeeld bounces.yourcompany.com. De provider kan TXT, MX of CNAME voorschrijven. Alleen een verwijzing publiceren wijzigt MAIL FROM niet; configureer de dienst en controleer pass en uitlijning. Bij ontspannen uitlijning volstaat hetzelfde organisatiedomein; strikte uitlijning vereist exact hetzelfde domein als Header From.
• DKIM-uitlijning: Publiceer de voorgeschreven sleutel of delegatie en laat de dienst tekenen met d=yourcompany.com waar ondersteund. Controleer echte handtekeningen.

Bij 100 klantdomeinen vraagt dit overzicht per dienst en domein. TrekMails vereiste DNS-records kunnen de inrichting begeleiden. Controleer actuele functies, publicatie en uitlijning voor elk domein; een dashboard past niet automatisch alle externe DNS-zones of ESP's aan.

Zie ook de uitleg over DMARC-uitlijning.

Gefaseerd invoeren: het brugmodel

Te vroeg p=reject kiezen kan mail raken. Langdurig p=none gebruiken kan bewust beleid zijn, maar biedt geen gevraagd DMARC-handhavingsniveau. Het brugmodel helpt een overgang plannen met monitoring, tests en een terugvalroute.

Fase 1: monitoring publiceren (week 1-4)

Dit illustratieve record vraagt geen DMARC-quarantaine of weigering; vervang domein en rapportadres door gecontroleerde eigen waarden:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Verzamel rapporten én inventariseer systemen actief. Vier weken kan maandelijkse stromen helpen vinden, zoals salarissoftware of nieuwsbrieven die eens per maand draaien. Het garandeert geen dekking van kwartaalfacturatie; één week is vaak beperkt. Test ook zeldzame stromen en houd rekening met ontbrekende rapporten.

Fase 2: onbekende zakelijke verzenddiensten vinden

Open beschikbare rapporten met een passende tool, zie rapporten, en verdeel het verkeer in drie groepen:

• Geautoriseerd en uitgelijnd: Bekende zakelijke platforms die DMARC moeten doorstaan. Onderzoek fouten vóór verdere handhaving.
• Geautoriseerd maar niet uitgelijnd: Een marketingtool buiten IT om, een helpdesk of een CRM dat sinds 2022 verzendt. Bevestig eigenaarschap en herstel legitieme stromen.
• Mogelijke dreigingen: Onbekende IP's kunnen spoofing aangeven, maar ook vergeten diensten of forwarding. Onderzoek ze; p=reject beperkt alleen toepasselijke falende domeinspoofing waar ontvangers het beleid volgen.

Herstel en test alle bekende legitieme verzendroutes voordat je verdergaat, ook wanneer ze niet in rapporten verschijnen.

Fase 3: quarantaine testen

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

Dit beleid vraagt quarantaine of spambehandeling voor DMARC-falen; ontvangers kunnen anders handelen. Monitor zakelijke gevolgen en test kritieke stromen actief. Wacht niet uitsluitend op klachten om een misconfiguratie te ontdekken.

pct= is een historische percentage-instelling die uit de huidige DMARC-specificatie is verwijderd: pct=25 illustreert het vroegere model met 25%. Oudere implementaties kunnen verschillen; reken niet op betrouwbare actuele sampling. Sla na fase 1 en 2 niet blind alle tussenstappen over om meteen 100% te vragen; kies een getest tempo met bewaking en terugvalplan.

Fase 4: handhaving

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

p=reject kan directe misbruikpogingen met jouw From-domein beperken als ze geen uitgelijnde authenticatie hebben en de ontvanger het verzoek volgt. Het stopt geen lookalike-domeinen of alle phishing en levert geen gegarandeerde reputatieverbetering of inboxplaatsing op.

Zie DMARC instellen en de voorbeelden van DMARC-records voor verdere configuratiecontext; valideer ieder voorbeeld vóór gebruik.

Doorsturen, ARC en het belang van DKIM

"Mail werkt, maar naar mijn advocaat krijg ik een bounce." Doorsturen is een mogelijke oorzaak, geen bewezen verklaring in negen van de tien gevallen. Controleer de concrete route en hoe ontvangers DMARC-beleid toepassen.

Hoe doorsturen SPF kan laten falen

Je mailt contact@smallfirm.com, dat doorstuurt naar personal@gmail.com. Gmail ziet nu het IP-adres van smallfirm.com. Als het oorspronkelijke MAIL FROM blijft staan en jouw SPF smallfirm.com niet autoriseert, kan SPF falen.

Alleen SPF gebruiken maakt zulke routes kwetsbaar, maar betekent geen onvermijdelijke weigering: configuratie, andere authenticatie en ontvangersbeleid zijn bepalend.

Wanneer DKIM geldig blijft

De DKIM-handtekening staat in een header en dekt geselecteerde headers en body. Zij kan geldig blijven bij doorsturen als gedekte inhoud en verificatievoorwaarden intact blijven. Een onderwerpwijziging of voettekst kan haar ongeldig maken. Een geldige uitgelijnde DKIM-handtekening kan DMARC laten slagen ondanks SPF-falen.

Daarom is DKIM een belangrijke aanvullende route, en onderdeel van toepasselijke afzendereisen. Zij biedt echter geen algemene garantie voor iedere forwarding-situatie.

ARC wanneer DKIM ook wordt beïnvloed

Een mailinglijst kan een footer toevoegen; een gateway kan inhoud veranderen. Dat kan DKIM breken afhankelijk van dekking en canonicalisatie. ARC (Authenticated Received Chain) laat tussenliggende systemen eerdere authenticatieresultaten ondertekend doorgeven. Dat is een verklaring over de verwerking, geen automatische reparatie van DMARC.

Google en Microsoft kunnen ARC beoordelen, waarbij vertrouwen in de tussenpartij en lokaal beleid belangrijk zijn. De forwarding-infrastructuur verzorgt vaak deze headers; eigen relaybeheerders kunnen wel configuratiewerk hebben. Alleen ARC-headers zien bewijst geen fout of gegarandeerde acceptatie.

Meer staat in DMARC-falen en doorsturen.

RUA en RUF: welke rapporten helpen?

Met rua= kun je aggregatierapporten aanvragen, vaak als XML. Niet iedere provider rapporteert elk bericht; autorisatie voor externe rapportbestemmingen en bereikbaarheid kunnen nodig zijn. XML is leesbaar maar omvangrijk, zodat tooling het onderzoek makkelijker kan maken.

RUA: aggregatierapporten

Tag: rua=mailto:reports@yourdomain.com

Rapporten bundelen doorgaans eenmaal per dag resultaten. Een illustratie: IP 203.0.113.12 verzond 300 berichten, waarvan 295 DMARC doorstonden en 5 niet. Inhoud en tijdigheid variëren; gebruik ook de bron-IP, aantallen en authenticatieresultaten zonder volledige dekking te veronderstellen.

dmarc.org noemt hulpmiddelen; controleer actuele mogelijkheden van bijvoorbeeld Postmark en Valimail. Onderzoek fouten bij bekende én onbekende bronnen. Een onbekende IP is niet automatisch een aanval en p=reject bewijst niet dat ieder gerapporteerd falend bericht werkelijk is geblokkeerd.

De artikelen over DMARC-rapporten en DMARC RUA geven verdere analysecontext.

RUF: forensische rapporten

Tag: ruf=mailto:forensics@yourdomain.com

RUF vraagt foutmeldingsrapporten op berichtniveau. Die kunnen headers of inhoud bevatten, afhankelijk van de provider en het weglakken van gevoelige gegevens. Ze zijn niet noodzakelijk volledige kopieën en verklaren niet altijd de hele oorzaak.

Dat kan privacy- en compliancevragen opleveren bij vertrouwelijke zakelijke mail. Beoordeel bestemming, toegang, bewaartermijn en rechtsgrond voordat je zulke rapporten verzamelt.

Veel grote ontvangers bieden geen of beperkte RUF; Gmail ondersteunt deze rapporten niet. RUA is daarom vaak een praktisch startpunt. Kies RUF alleen met aantoonbare behoefte en passende bescherming; het nut en de ruis verschillen per omgeving.

Het artikel over DMARC RUF behandelt deze forensische afweging uitgebreider.

Ruis zorgvuldig beoordelen

Rapporten kunnen legacy-forwarding en spoofing bevatten, maar negeer een onbekende IP niet enkel vanwege een laag volume. Ook kritieke legitieme mail kan weinig voorkomen. Bevestig bronnen, verzendroutes en patronen; combineer rapporten met inventarisatie en echte tests.

Wanneer p=reject overwegen?

Overweeg p=reject pas als legitieme stromen voldoende zijn onderzocht en getest. Gebruik deze checklist om de beslissing te onderbouwen, niet als garantie:

• Monitoringvoorbeeld van 30 dagen: Controleer maandelijkse én kwartaalstromen actief; deze periode garandeert geen kwartaaldekking. Een week monitoring kan nog beperkter zijn.
• Hoofdstromen zijn uitgelijnd: TrekMail, Google Workspace of Microsoft 365 moet daadwerkelijk DMARC doorstaan, niet alleen losse SPF of DKIM.
• Externe diensten zijn gecontroleerd: Marketing, transactionele mail, CRM en helpdesk hebben een geschikte geldige uitgelijnde authenticatiemethode.
• Marketing heeft bevestigd: Vraag alle teams naar nieuwe diensten. Een tool die sinds vorige dinsdag verzendt, hoeft nog niet in rapporten te staan.
• Subdomeinbeleid is beoordeeld: Overerving hangt van toepasselijke records en beleidsregels af. sp=none kan in het getoonde model een ander verzoek voor gedekte subdomeinen geven: v=DMARC1; p=reject; sp=none; rua=mailto:reports@yourdomain.com. Beoordeel sp= apart en test ook eigen subdomeinrecords.

Blijf bij p=reject monitoren. Bevestig bij meer bezorgklachten eerst dat legitieme mail door het beleid wordt geraakt en gebruik zo nodig tijdelijk je terugvalplan, bijvoorbeeld p=quarantine, voordat je opnieuw aanscherpt. Controleer de wijziging bij de gezaghebbende DNS-server en relevante resolvers; caches en ontvangersbeleid verhinderen gegarandeerd onmiddellijk herstel. Al geweigerde berichten worden hierdoor niet teruggehaald. DMARC ondersteunt domeinbescherming, maar geen zekere verbetering van e-maildomeinreputatie.

Zie de uitleg over rejectbeleid en DMARC-falen: diagnose en herstel.

DMARC voor meerdere domeinen met TrekMail

Ook voor één domein is DMARC geen eenmalige klus. Een maand monitoren is slechts een voorbeeld; inventariseer, herstel uitlijning, test handhaving en controleer later wijzigingen opnieuw.

Bij tientallen of honderden domeinen vraagt ieder nieuw domein vanaf de eerste dag aandacht voor beleid en rapportage. Controleer gebruikte diensten, uitlijning en periodiek de verzamelde rapporten over je portfolio.

Handmatig bij iedere DNS-provider inloggen en records publiceren kost herhaald werk. Voor 50 domeinen kan een middag een illustratie zijn; voor 500 helpt tooling. De werkelijke duur en schaalbaarheid hangen af van inrichting en automatisering.

TrekMails vereiste DNS-records kunnen initiële instellingen helpen opstellen. Controleer waarden, rapportadres en publicatie. De DNS-statuscontrole kan afhankelijk van actuele functies overzicht bieden, maar een aanwezig record is geen bewijs dat alle berichten DMARC doorstaan.

Bij beheerde SMTP kan TrekMail domeinondertekening ondersteunen. Verifieer de actuele selector, DNS-publicatie en echte uitlijning per domein. Eigen SMTP en externe diensten hebben hun eigen configuratie nodig.

De historische vergelijking noemt Pro op $8 per maand met 100 domeinen, 300 gebruikers per domein en 50GB gedeelde opslag, tegenover $6-12 per gebruiker bij andere diensten. Controleer actuele contracten, inbegrepen diensten en grenzen; platformprijzen betekenen geen onbeperkte schaal of automatische externe DNS-configuratie.

Agency wordt beschreven voor 1,000+ domeinen. Controleer functies, capaciteit en voorwaarden in het volledige prijsoverzicht.

De kern van je DMARC-record

Beheer een DMARC-record waar het nodig is en controleer de geldige uitgelijnde authenticatie. Ontvangers hanteren verschillende eisen en filters; ontbrekend beleid maakt niet iedere mail vanzelf onbetrouwbaar, maar kan relevante bescherming en naleving beperken.

Publiceer bewust monitoringbeleid, gebruik een maand als mogelijk observatievoorbeeld, inventariseer en test alle bronnen, en overweeg gefaseerd quarantaine en reject met een terugvalplan. Blijf rapporten volgen.

Een eigen domein kan een middag werk lijken, maar vraagt blijvend beheer. Voor een klantportfolio heb je een herhaalbaar proces nodig. TrekMail kan daarin helpen, afhankelijk van actuele functies en jouw verzendconfiguratie.

Overweeg DMARC-beleid op p=reject wanneer inventarisatie, tests en risicoafweging dat ondersteunen. Vergelijk vervolgens prijsmodellen en beheerlast op basis van actuele voorwaarden.

Bekijk TrekMails gratis aanbod en controleer de huidige voorwaarden, waaronder de creditcardvereisten.