begrip · dmarc-check

Hoe voer je een DMARC-check uit voor applicatiemail?

Een DMARC-check moet vier afzonderlijke dingen verifiëren: er is een geldig beleid te vinden in DNS, de verplichte tags worden correct geparsed, op een echt bericht is ten minste één geauthenticeerde SPF- of DKIM-identifier uitgelijnd met het zichtbare From-domein, en elke legitieme afzender in de applicatie is meegenomen vóór de handhaving. Vraag de _dmarc-naam op, inspecteer het record en bekijk daarna de authenticatieresultaten van gecontroleerde verzendingen. Een DMARC-pass valideert geautoriseerd gebruik van het domein; het bewijst geen bezorging of plaatsing in de inbox.

Behandel een DMARC-check als vier tests, niet als één lookup

Een bruikbare check heeft vier lagen. Ten eerste: vind het beleid dat geldt voor het auteursdomein van het bericht. Ten tweede: valideer het TXT-record als DMARC-beleid in plaats van elke tekst te accepteren die DNS teruggeeft. Ten derde: test de alignment van identifiers op een echt bericht: het met SPF geauthenticeerde MAIL FROM-domein of een geverifieerd DKIM-ondertekeningsdomein moet uitgelijnd zijn met het domein in de zichtbare From-header. Ten vierde: bevestig de operationele dekking door te verzenden via elke legitieme applicatie, provider, regio en berichtklasse die het domein gebruikt. Een groene DNS-lookup dekt slechts een deel van de eerste twee lagen. Hij kan niet aantonen dat een provider ondertekent met het bedoelde domein, dat een aangepast return path actief is, dat doorsturen het SPF-gedrag heeft veranderd of dat een over het hoofd gezien systeem een handhavingsbeleid overleeft.

Vraag de juiste DNS-naam op en volg de beleidsdiscovery

Begin met het exacte domein in de RFC5322 From-header, vaak het auteursdomein genoemd. Vraag het TXT-record op _dmarc gevolgd door dat domein op. Voor een bericht van alerts@notify.example.test begin je bij _dmarc.notify.example.test en niet bij de websitehost, de MX-host of het return-path-domein. RFC 9989 definieert beleidsdiscovery als meer dan één lookup: als het auteursdomein geen geldig record heeft, kan een ontvanger de DNS-boom doorlopen om het toepasselijke beleid van het organisatiedomein of het public suffix te vinden. De afhandeling van subdomeinen kan uit de tag sp, np of p komen, afhankelijk van wat er bestaat en waar het beleid wordt gevonden. Een checker moet dus zowel de opgevraagde naam rapporteren als het beleidsdomein dat hij daadwerkelijk heeft geselecteerd. Een resultaat dat alleen "record gevonden" meldt, kan fouten in de overerving verbergen, of een expliciet subdomeinbeleid dat de verwachte behandeling verandert.

Valideer de recordstructuur voordat je het beleid interpreteert

Een DMARC-beleidsrecord gebruikt tag-waardesyntaxis. Onder RFC 9989 is v=DMARC1 vereist, hoofdlettergevoelig en moet het als eerste verschijnen; een geldige p-tag levert het gevraagde beoordelingsbeleid. Veelvoorkomende beleidswaarden zijn none, quarantine en reject. Optionele tags beschrijven rapportagebestemmingen, gedrag voor subdomeinen en strict of relaxed SPF- en DKIM-alignment. Herstel niet stilzwijgend verkeerd gespelde tags, een ontbrekende p-waarde, dubbele of conflicterende records, ongeldige scheidingstekens of een waarde die met citeerartefacten van een DNS-provider is gekopieerd. Behandel een permanente evaluatiefout als een resultaat dat correctie vereist, niet als een DMARC-pass of -fail. Maak ook onderscheid tussen een tijdelijke DNS-lookupfout en een onjuist gevormd record. Probeer een tijdelijke resolverfout opnieuw via een gecontroleerd pad, maar beweer niet dat het domein geen beleid heeft totdat gezaghebbende DNS betrouwbaar kan worden opgevraagd.

Controleer SPF- en DKIM-alignment op een echt bericht

DMARC wordt geëvalueerd op basis van de authenticatie van het bericht, niet op basis van de DNS-configuratie alleen. Vergelijk voor SPF het geauthenticeerde MAIL FROM-domein met het zichtbare From-domein. Vergelijk voor DKIM het d=-domein van elke succesvol geverifieerde handtekening met het zichtbare From-domein. Relaxed alignment accepteert domeinen met hetzelfde organisatiedomein; strict alignment vereist identieke domeinen. Een bericht slaagt wanneer ten minste één geauthenticeerde identifier slaagt voor het onderliggende mechanisme en uitgelijnd is. Een return path van een provider kan SPF bijvoorbeeld laten slagen voor het domein van de provider, maar niet uitgelijnd zijn met billing.example.test. Als DKIM verifieert met d=example.test onder relaxed alignment, kan het bericht toch voor DMARC slagen. Leg de ruwe Authentication-Results-header vast van gecontroleerde ontvangeraccounts, maar interpreteer die in context: hij rapporteert het resultaat van de evaluerende ontvanger en kan meerdere hops of handtekeningen bevatten.

Lees de resultaten pass, fail, none en error nauwkeurig

Een DMARC-pass betekent dat een beleidsrecord van toepassing is en een geauthenticeerde SPF- of DKIM-identifier is gealigned met het auteursdomein. Een fail betekent dat een beleid van toepassing is maar er geen gealigneerde geauthenticeerde identifier bestaat. None betekent dat geen toepasselijk beleid is ontdekt. Permerror en temperror wijzen op fouten tijdens DMARC-evaluatie; een bericht met een DNS-fout kan niet worden beschouwd als geslaagd of gefaald voor DMARC. Deze resultaten zeggen niet waar de mailboxprovider het bericht heeft geplaatst. RFC 9989 beperkt een pass expliciet tot validatie dat het gebruik door de domeineigenaar was geautoriseerd; het stelt niet dat het bericht veilig, gewenst, betrouwbaar of inboxwaardig is. Houd provideracceptatie, acceptatie door de ontvangende server, DMARC-resultaat, klachtsignalen en waargenomen plaatsing als afzonderlijke velden in diagnostiek en dashboards.

Breng elke legitieme afzender in kaart vóór de handhaving

Inventariseer alle systemen die het domein in From zetten: productieapplicaties, authenticatiemails, factuurmeldingen, supporttools, marketingplatforms, monitoringmeldingen, CRM-workflows, regionale accounts en noodsystemen. Leg voor elke stroom het zichtbare From-domein, het MAIL FROM-domein, het DKIM d=-domein en de selector, het provideraccount, de eigenaar, de berichtklasse en het verwachte volume vast. Verstuur gecontroleerde berichten via het normale productiepad en verifieer zowel authenticatie als alignment. Aggregate DMARC-rapporten kunnen bronnen tonen die het domein gebruiken, maar ze moeten worden geïnterpreteerd en kunnen doorgestuurd of ongeautoriseerd verkeer bevatten. Begin met monitoring zolang de inventaris onvolledig is, en herstel legitieme niet-uitgelijnde stromen voordat je een strengere afhandeling door ontvangers aanvraagt. Wijzig geen gedeeld organisatiebeleid alleen om één applicatie groen te krijgen, en ga niet over op handhaving op basis van één testbericht.

Diagnosticeer veelvoorkomende fouten bij applicatiemail

Als er geen beleid wordt gevonden, verifieer dan de DNS-zone en de recordnaam voordat je de waarde bewerkt. Als het record een permanente fout heeft, breng het terug tot één geldig beleid en controleer de volgorde en syntaxis van de tags. Als DKIM faalt, controleer dan of de verwachte selector bestaat, of de provider het geteste bericht daadwerkelijk heeft ondertekend, of de body of de ondertekende headers onderweg zijn veranderd en of het geverifieerde d=-domein uitgelijnd is. Als SPF slaagt maar DMARC faalt, vergelijk dan het MAIL FROM-domein met het zichtbare From-domein in plaats van elke SPF-pass als voldoende te beschouwen. Als alleen doorgestuurde mail faalt, bedenk dan dat doorsturen vaak het envelope-pad verandert en SPF kan breken, terwijl een geldige uitgelijnde DKIM-handtekening kan blijven werken. Als een uitrol tot afwijzingen leidt, bewaar dan de falende headers en de respons van de ontvanger, stop verdere escalatie van het beleid en herstel de verantwoordelijke stroom in plaats van niet-gerelateerde authenticatiecontroles af te zwakken.

Pas providerspecifieke alignmentregels bewust toe

Externe afzenders hebben configuratie nodig die hun geauthenticeerde identifiers koppelt aan een domein dat de organisatie beheert. Amazon SES documenteert twee routes: een uitgelijnd aangepast MAIL FROM-domein voor SPF en een uitgelijnd DKIM-ondertekeningsdomein. Het standaard return path dat eigendom is van de provider kan met SPF authenticeren zonder uitgelijnd te zijn met het zichtbare From-domein; DKIM is daarom vaak het praktische uitgelijnde mechanisme, tenzij er een aangepast MAIL FROM-domein is geconfigureerd. Andere providers gebruiken andere namen voor return paths, bouncedomeinen, domeinauthenticatie en ondertekeningsidentiteiten. Verifieer het daadwerkelijk verzonden bericht in plaats van aan te nemen dat een badge "geverifieerd" in een dashboard DMARC regelt. De huidige richtlijnen van Gmail voor afzenders vereisen ook authenticatie en alignment voor verkeer waarop ze van toepassing zijn, en bevelen DMARC-rapportage aan. Eisen van ontvangers en functies van providers kunnen veranderen; controleer daarom hun officiële documentatie opnieuw bij de lancering en tijdens incidentreviews.

Gebruik providerbewijs zonder het als DMARC-oordeel te behandelen

SendHQ ondersteunt verzending vanaf geverifieerde domeinen, bezorgevents, suppressies en een webdashboard. Gebruik de informatie over verzenddomeinen en bezorging om een berichtenstroom te onderzoeken, verifieer vervolgens DMARC aan de hand van de Authentication-Results-header van de ontvanger en scheid bewijs voor SPF, DKIM en alignment. Provideracceptatie en bezorgevents bewijzen geen inboxplaatsing.

Leg een controleerbaar resultaat van de DMARC-check vast

Een duurzaam resultaat bevat het auteursdomein, het tijdstip van de query, de resolver, de opgevraagde _dmarc-naam, het geselecteerde beleidsdomein, het exacte genormaliseerde record, de beleids- en alignmentmodi, de DNS-status en of het parsen bruikbare syntaxis, permerror of temperror opleverde. Voeg per gecontroleerd bericht één rij toe met een niet-gevoelige bericht-identifier, verzendend systeem, zichtbaar From-domein, geauthenticeerd SPF-domein en resultaat, geverifieerde DKIM-domeinen en selectors, alignmentbeslissingen, uiteindelijk DMARC-resultaat en ontvanger. Bewaar ruwe headers in afgeschermde opslag, omdat ze adressen, routeringsdetails en interne identifiers kunnen blootleggen. Koppel elke bevinding aan een eigenaar en een hersteldatum. Controleer opnieuw nadat DNS-TTL's verlopen, na wijzigingen in de providerconfiguratie, sleutelrotatie, nieuwe berichtstromen of escalatie van het beleid. Dit bewijs maakt de check reproduceerbaar en voorkomt dat een screenshot of badge van een tool permanent bewijs wordt nadat de onderliggende configuratie is veranderd.

Veelgestelde vragen

Waar moet je een DMARC-record controleren?

Begin met het TXT-record op _dmarc plus het exacte domein in het zichtbare From-adres. Bepaal ook welk beleidsdomein via de actuele DMARC-discoveryregels wordt geselecteerd, omdat een beleid van het organisatiedomein of een subdomein van toepassing kan zijn wanneer de eerst opgevraagde naam geen geldig record heeft.

Betekent het vinden van v=DMARC1 dat DMARC slaagt?

Nee. Het draagt alleen bij aan een geldig beleidsrecord. Een bericht slaagt pas nadat SPF of DKIM authenticeert met een domein dat is uitgelijnd met het zichtbare From-domein. Test een echt bericht en inspecteer de authenticatieresultaten van de ontvanger.

Kan DMARC slagen als SPF niet uitgelijnd is?

Ja. Een succesvol geverifieerde DKIM-handtekening kan de uitgelijnde geauthenticeerde identifier leveren die DMARC nodig heeft. Het omgekeerde kan ook: uitgelijnde SPF kan een pass opleveren wanneer DKIM dat niet doet, al vermindert vertrouwen op één mechanisme de robuustheid.

Bewijst een DMARC-pass dat een bericht in de inbox belandt?

Nee. Het valideert geautoriseerd gebruik van het auteursdomein voor dat bericht. Een ontvanger kan nog steeds signalen over reputatie, inhoud, ontvanger, misbruik en lokaal beleid toepassen bij het accepteren, weigeren, in quarantaine plaatsen of categoriseren van het bericht.

Moet een applicatie direct overstappen op p=reject?

Meestal niet zonder inventarisatie- en monitoringbewijs. Breng elke legitieme afzender in kaart, valideer alignment op gecontroleerde berichten, beoordeel aggregate-rapporten, herstel fouten en stem beleidswijzigingen met de domeineigenaar af voordat je om strengere afhandeling vraagt.

Wat moet je opnieuw controleren na een overstap naar een andere e-mailprovider?

Controleer opnieuw het beleid dat voor elk From-domein wordt gevonden, de MAIL FROM- en DKIM-domeinen van de provider, de DNS van de selector, de SPF- en DKIM-resultaten, relaxed of strict alignment, aggregate-rapporten en elke gecontroleerde berichtklasse van de applicatie, voordat je het productieverkeer verhoogt.

Bronnen