DMARC-controle:
blokkeert uw beleid ook daadwerkelijk iets?
Voer een domein in — de controle ontleedt elke tag en beoordeelt wat uw beleid daadwerkelijk afdwingt, niet alleen of er een record bestaat. De meeste domeinen blijven steken bij p=none, en dat blokkeert niets: het vraagt ontvangers alleen om de vervalste mail te melden die ze toch al hebben afgeleverd.
Foutloze syntaxis, nul bescherming
Een DMARC-record kan syntactisch perfect zijn en operationeel toch niets voorstellen. Elk van deze vier gevallen doorstaat een bestaanscontrole moeiteloos, maar biedt in de praktijk geen enkele bescherming.
p=none nooit uitgezet na de uitrol
Tijdens de uitrol in 2023 op „monitoring” gezet — en nog altijd op monitoring. p=none vertelt ontvangers om niets te doen: vervalste mail komt gewoon met uw naam erop in de inbox terecht, terwijl uw dashboard keurig DMARC ✓ toont.
p=none · blokkeert nietsrua= naar een niet-geautoriseerd domein
Uw rua= wijst naar het domein van een leverancier of bureau dat nooit een autorisatierecord heeft gepubliceerd. Ontvangers controleren hierop — en gooien elk rapport stilzwijgend weg. Geen bounce, geen foutmelding, geen data. Nooit.
RFC 7489 §7.1Het gat in pct=
p=reject; pct=50 — de uitrolknop halverwege blijven staan. De helft van de vervalste mail wordt geweigerd, de andere helft gewoon afgeleverd, willekeurig per bericht. Een aanvaller vindt het prima om het nog eens te proberen.
pct=50 · half afgedwongensp=none op uw subdomeinen
Een expliciete sp=none, achtergebleven uit de uitrolfase, betekent dat uw hoofddomein spoofing weigert terwijl invoices.yourdomain.com het gewoon toelaat. Aanvallers lezen ook DNS.
sp=none · subdomeinen onbeschermdreject, quarantine, none en de gaten ertussen
De p=-tag is een instructie aan elke mailontvanger ter wereld. Wij beoordelen hem als een ladder met tredes, niet als geslaagd-of-gezakt.
„Mail die niet aligneert: weiger hem bij de poort.” Volledige bescherming — het eindpunt van de ladder. Nooit sterker dan de SPF en DKIM erachter, en pas compleet bij pct=100.
„Behandel mislukkingen met argwaan” — in de praktijk: de spamfolder. Echte gedeeltelijke bescherming en de juiste middelste trede, zeker wanneer u opbouwt met pct=. Niet de top.
Monitoring: er wordt niets geblokkeerd, maar de rapporten stromen binnen en u ziet wie er namens u verzendt. De juiste eerste 90 dagen van elke DMARC-uitrol — en de permanente status van veel te veel domeinen.
Er wordt niets geblokkeerd en niemand kijkt mee. Het record bestaat puur om bestaanscontroles tevreden te stellen. Compliance in zijn meest holle vorm.
Ontvangers vallen terug op hun eigen heuristieken; hoe makkelijk uw domein te spoofen is, hangt dan af van wie er ontvangt. Steeds vaker ook een afleverbaarheidsprobleem: bulkverzenders naar Gmail/Yahoo zijn verplicht DMARC te publiceren.
Meerdere v=DMARC1-records op _dmarc worden niet samengevoegd — de opzoeking mislukt en ontvangers behandelen u alsof u niets publiceert. Hetzelfde geldt voor een verminkte taglijst.
Waar uw DMARC-rapporten naartoe gaan
DMARC-rapportage is een afspraak tussen drie partijen: u, de ontvangers en wie de rapporten leest. Wijst rua= naar een ander domein (een leveranciersdashboard, een bureau-inbox), dan eist RFC 7489 §7.1 dat dat domein hiervoor toestemming geeft:
- Voordat een ontvanger een rapport verstuurt, vraagt hij yourdomain._report._dmarc.theirdomain op, op zoek naar een v=DMARC1-record.
- Geen record → geen rapport. Stilzwijgend. Er komt geen bounce bij u binnen, nergens wordt het gelogd — uw rapportage heeft in feite nooit bestaan.
- Serieuze leveranciers publiceren een wildcard (*._report._dmarc.example.com) — een verkeerd getypt leveranciersdomein, een verlopen account of een gewone inbox van een bureau heeft dit niet.
- Wij zoeken tot 5 rua=/ruf=-bestemmingen per tag op en voeren deze opzoeking voor elk uit — de meeste checkers doen dit nooit.
De ladder
wat elke trede u oplevertWat dig u kan vertellen
Het record is met één dig te vinden, en de autorisatiecontrole is gewoon DNS zodra u weet dat die bestaat. Beoordelen wat het beleid daadwerkelijk afdwingt, vraagt meer dan één regel.
Veelgestelde vragen over DMARC
Typ hierboven uw domein in. Wij halen het TXT-record op bij _dmarc.yourdomain, controleren of er precies één v=DMARC1 is (twee betekent dat ontvangers er helemaal geen zien), en ontleden elke tag volgens RFC 7489 met de defaults expliciet uitgeschreven (p=, sp=, pct=, adkim=/aspf=, rua=/ruf=, fo=). Daarna beoordelen we het handhavingsniveau en controleren we of de rapportbestemmingen die we beoordelen daadwerkelijk rapporten kunnen ontvangen. Gratis, zonder registratie.
Het vertelt elke ontvanger: „als mail niet aan DMARC voldoet, doe dan niets — lever hem toch af, maar stuur mij een rapport.” Er wordt niets in quarantaine gezet en niets geweigerd. Een vervalste factuur komt in de inbox van uw klant terecht precies zoals wanneer u helemaal geen DMARC had. Wat p=none u wél oplevert, is zichtbaarheid: de geaggregeerde rapporten noemen elke server die namens uw domein verzendt, legitiem of niet. Dat maakt het de juiste eerste trede van een uitrol, en een verschrikkelijke plek om permanent te blijven. Staat uw record al langer dan 2 kwartalen op p=none, dan „doet u” geen DMARC. U kijkt in high definition toe hoe anderen zich voor u uitgeven.
Stap voor stap, geen sprong. Eerst: p=none met rua= gedurende één kwartaal. Lees de rapporten, spoor elke legitieme afzender op (de facturatietool die niemand zich nog herinnerde) en herstel hun SPF/DKIM-alignment. Dan: p=quarantine; pct=10, en verhoog pct naar 50 en vervolgens 100 zolang de rapporten schoon blijven. Dan: p=reject. Loopt één subdomein achter (een nieuwsbriefplatform middenin een migratie), geef dat dan een eigen _dmarc.sub-record in plaats van het hele domein op none te houden. Laat elke stap afhangen van rapportdata — de rapporten zijn het vangnet dat strengheid veilig maakt.
rua= is geaggregeerde rapportage: dagelijkse XML-samenvattingen van elke ontvanger — welke IP's namens u verzonden, hoeveel er slaagden of faalden, onder welk beleid. Dit is degene die ertoe doet; hiermee stuurt u de ladder. ruf= is forensische rapportage: kopieën van individuele mislukte berichten. De meeste grote ontvangers, waaronder Gmail en Microsoft, sturen deze om privacyredenen niet meer. Beschouw ruf= als een extraatje van kleinere ontvangers, niet als een databron waarop u kunt bouwen. Beide accepteren alleen mailto:-URI's, en op beide is de autorisatiecontrole voor externe bestemmingen van toepassing die deze tool uitvoert.
De klassieke oorzaak is precies de controle waarvoor deze tool bestaat: uw rua= wijst naar een domein dat niet van u is, en dat domein heeft nooit het autorisatierecord gepubliceerd. RFC 7489 §7.1 verplicht ontvangers om eerst toestemming te verifiëren: ze vragen yourdomain._report._dmarc.destinationdomain op en verwachten een v=DMARC1-antwoord. Geen antwoord → het rapport wordt stilzwijgend weggegooid, zonder bounce en zonder foutmelding die u ergens ziet. Dit gebeurt wanneer het leveranciersdomein verkeerd getypt is, of wanneer u van leverancier wisselt maar het record niet aanpast. Het gebeurt ook wanneer rapporten naar een bureau-mailbox gaan die nooit is ingesteld voor rapportage over domeingrenzen heen. Wij voeren de opzoeking uit voor elke bestemming die we beoordelen en tonen u het exacte ontbrekende record.
Alignment is hoe DMARC SPF/DKIM koppelt aan de From:-regel die uw lezer ziet. Relaxed (de default, r) accepteert een match op organisatiedomeinniveau — mail ondertekend door news.yourdomain.com aligneert met yourdomain.com. Strict (s) eist een exacte match. Relaxed is voor bijna iedereen de juiste keuze; strict dicht een smal gat (een gecompromitteerd of gedelegeerd subdomein dat voor uw hoofddomein instaat) tegen de prijs dat elke subdomein-afzender die u vergeten was, breekt. Zet pas op strict nadat uw rapporten een kwartaal lang schone, exacte-domeinalignment laten zien.
Het stopt spoofing op exact hetzelfde domein bij meewerkende ontvangers — en dat is het merendeel van het wereldwijde mailboxvolume. Er blijven drie gaten over. DMARC beoordeelt alleen alignment, dus het is precies zo sterk als de SPF en DKIM eronder. Een SPF met permerror of een ingetrokken DKIM-sleutel verzwakt reject zonder dat u het merkt. Een pct<100 of een zwakkere sp= laat bewuste gaten open. En look-alike-domeinen (yourcompany-billing.com) vallen buiten bereik, omdat geen enkel DMARC-record van u kan spreken namens een domein dat u niet bezit. Controleer de hele stack: onze SPF- en DKIM-tools dekken het eerste gat.
Gratis tools zijn pas het begin.
Uptimia houdt uw sites gezond.
Uptime, SSL, Vervaldatum domein, paginasnelheid, transacties — gemonitord vanuit 171+ locaties wereldwijd. 30 dagen gratis.