Bij het uitvoeren van een DMARC-controle wordt het _dmarc-TXT-record voor uw domein opgehaald en uiteengezet wat het ontvangers opdraagt te doen. Zo leest u dat resultaat en handelt u naar de onderdelen die er het meest toe doen.
Hoe u uw DMARC-controleresultaten leest
De checker rapporteert vier zaken: of er een geldig v=DMARC1-record bestaat, het handhavingsbeleid (p=), de uitlijningsmodus voor SPF en DKIM, en waar rapporten naartoe worden gestuurd (rua/ruf). Een gezond resultaat heeft één record, een beleid sterker dan none, en ten minste een geaggregeerd rapportageadres zodat u zicht heeft op wie er als uw domein verstuurt.
De drie DMARC-beleidsregels: none, quarantine, reject
p=none- alleen monitoren. Mislukte post wordt nog steeds afgeleverd; u verzamelt alleen rapporten. Dit is het startpunt, niet de bestemming.p=quarantine- mislukte post wordt naar spam/ongewenst gestuurd. De eerste echte handhavingsstap.p=reject- mislukte post wordt direct geblokkeerd. Dit is het doel, en wat domeinimitatie stopt.
De juiste uitrol is none → quarantine → reject, waarbij u pas een stap hoger gaat zodra uw rapporten aantonen dat elke legitieme afzender slaagt. Onbeperkt op p=none blijven is de meest voorkomende DMARC-fout - het biedt geen enkele bescherming.
SPF- en DKIM-uitlijning: waarom DMARC mislukt zelfs als SPF slaagt
DMARC controleert niet alleen of SPF of DKIM is geslaagd - het controleert of ze uitlijnen met het domein in het zichtbare From-adres. Een bericht kan SPF doorstaan voor het eigen domein van de verzenddienst en toch DMARC niet doorstaan omdat dat domein niet overeenkomt met uw From-header. De aspf- en adkim-tags bepalen hoe strikt die overeenkomst moet zijn: r (relaxed) staat subdomeinen toe, s (strict) vereist een exacte overeenkomst; onze gids over het begrijpen van SPF-uitlijning legt het verschil uitgebreid uit. Wanneer een geldig SPF-record toch DMARC niet doorstaat, is verkeerde uitlijning vrijwel altijd de reden - en een geslaagd, uitgelijnd SPF-record hangt ervan af dat uw SPF om te beginnen correct is.
Veelvoorkomende DMARC-misconfiguraties
- Geen record, of verkeerde host. Het record moet op
_dmarc.uwdomein.comstaan, niet op de apex. - Twee DMARC-records. Slechts één is toegestaan; een tweede maakt beide ongeldig.
- Vast op
p=none. Eeuwig monitoren biedt nul handhaving. - Geen
rua-adres. Zonder geaggregeerde rapporten handhaaft u blind.
Geaggregeerde versus forensische rapporten
Geaggregeerde rapporten (rua) zijn dagelijkse XML-samenvattingen van elke bron die als uw domein verstuurt en of deze is geslaagd - hier vindt u ongeautoriseerde afzenders en bevestigt u dat uw eigen afzenders uitgelijnd zijn. Forensische rapporten (ruf) leggen individuele mislukte berichten vast voor diepgaander onderzoek. Om de ruwe XML in iets leesbaars om te zetten, ontleedt en visualiseert ons zusterproduct DMARC Report het voor u.
DMARC, SPF en DKIM werken samen
DMARC is de beleidslaag bovenop twee controles: SPF (de verzendende server) en DKIM (een handtekening die bewijst dat het bericht niet is gewijzigd). Omdat DMARC-handhaving een geslaagd, uitgelijnd SPF-resultaat vereist, is het geldig houden van uw SPF-record en onder de 10-lookuplimiet fundamenteel - AutoSPF regelt dat automatisch. Lees het volledige verhaal in onze DMARC-gids.