DMARCbis verandert de manier waarop delen van DMARC worden gespecificeerd en geïmplementeerd. Er wordt u niet gevraagd om uw record te hernoemen naar DMARC2. De kernspecificatie, RFC 9989, werd in mei 2026 gepubliceerd, terwijl RFC 9990 En RFC 9991 bestrijk de geaggregeerde en foutrapportage afzonderlijk.
De praktijkopdracht is om uit te zoeken welke wijzigingen invloed hebben op uw domein, uw verzenddiensten en de software die uw authenticatiegegevens verwerkt. Dat begint met het begrijpen van de huidige specificaties en deze vervolgens te vergelijken met de configuratie en processen die al in gebruik zijn. Het resultaat moet een duidelijk gereedheidsregister zijn met bewijsmateriaal, eigenaren en een beslissing voor elke bevinding.
Wijs de drie specificaties toe aan uw systemen
Gebruik de huidige documenten voor hun respectievelijke taken:
| Document | Wat te beoordelen |
|---|---|
| RFC 9989 | Kern DMARC -evaluatie, beleidsontdekking, uitlijning en semantiek vastleggen |
| RFC 9990 | Geaggregeerd rapportageformaat, genereren en verwerken |
| RFC 9991 | Storingsrapportage en de bijbehorende behandelingsoverwegingen |
Begin met de bestaande record- en configuratiegeschiedenis. Verwijder geen bedrijfsgegevens louter omdat een oudere gids ernaar verwijst RFC 7489. Identificeer de instructies die zijn gewijzigd en de software die deze implementeert.
De belangrijkste beoordelingsgebieden zijn onder meer:
- Domein ontdekking: RFC 9989 sectie 4.10 definieert DNS tree walking. Beoordeel systemen die uitgaan van een ouder detectiemodel met openbare achtervoegselslijsten.
- Beleidstags: Controleer het huidige IANA register. De
pct,rfEnRitags zijn historisch. Schattent,npEnpsdop basis van hun feitelijke reikwijdte, in plaats van ze toe te voegen als een upgradechecklist. - Testen: Bepaal hoe de relevante beoordelaar het binaire bestand implementeert
tsignaal. Een aangegeven testtoestand en de uiteindelijke instelling van een ontvanger zijn verschillende observaties. - Rapportage: Bevestig dat verzamelprogramma's en parsers omgaan met de rapportformaten en velden die u verwacht te ontvangen, zonder dat relevante oude observaties verloren gaan.
De versiemarkering blijft behouden v=DMARC1. Niet vervangen DMARC2 of mechanisch een oud percentage vervangen door een testvlag.
Vertaal de gewijzigde tags naar tests
De t flag defaults to n, met het verzoek om toepassing van de aangegeven beoordeling op DMARC fouten. Instelling t=y geeft aan dat de eigenaar aan het testen is in plaats van te vragen dat de aangegeven beoordeling direct wordt toegepast. RFC 9989 sectie 4.7 definieert een reductie van één niveau voor falende berichten: weigeren wordt quarantaine en quarantaine wordt geen. Implementaties kunnen ook een relevante speciale behandeling hebben.
De vlag verandert een mislukt authenticatieresultaat niet in een voldoende, verandert het genereren van rapporten en heeft geen invloed op een 'geen'-beleid. Het is binair en geen verzoek om een willekeurig percentage van de post te bemonsteren. Zorg voor implementatieondersteuning voordat u erop vertrouwt voor echt verkeer, en houd ontvanger-lokale filtering gescheiden van het testresultaat op beleidsniveau.
Twee andere tags zijn van invloed op de reikwijdte van de beoordeling:
- np: Specificeert de beoordeling voor niet-bestaande subdomeinen van de heersende organisatorisch domein. Indien afwezig, is de toepasselijke fallback sp indien aanwezig, anders p. A missing MX record alleen bewijst niet dat het niet bestaat.
- psd: Markeert domeingrensinformatie die tijdens de detectie wordt gebruikt. De standaard u laat het bepalen van de grenzen over aan de ontdekkingsregels; y identificeert een openbaar achtervoegsel, terwijl n een organisatorische grens voor zichzelf en zijn subdomeinen identificeert. Stel geen expliciete grenswaarde in zonder vast te stellen dat deze het domein correct beschrijft.
Een gewone organisatie mag haar domein niet bestempelen als een publiek achtervoegsel louter en alleen om gereedheid te claimen. Bekijk de feitelijke ontdekkingsaannames en gedelegeerde naamruimten. De Beleidsgids voor subdomeinen behandelt de engere kwestie van erfenis.
Identificeer de e-mail die moet blijven werken
Een domein kan veel meer vertegenwoordigen dan alleen de e-mail van werknemers. Het kan verschijnen op facturen, inloglinks, klantwaarschuwingen en berichten verzonden door externe bureaus. Een standaardupdate is een kans om deze afhankelijkheden te controleren voordat een overhaaste configuratiewijziging deze verstoort.
Vraag om drie deliverables: een inventarisatie van de diensten waarbij uw identiteit wordt gebruikt, een toelichting op de specifieke wijzigingen die voor u van belang zijn en een testplan voor kritische boodschappen. Het antwoord moet een gepubliceerde specificatie onderscheiden van een functie die al door een bepaalde ontvanger of softwareservice is geïmplementeerd.
Verdeel zowel het eigendom als het budget. Voor een wijziging in de rapportverwerking is iemand nodig die verantwoordelijk is voor de rapportagepijplijn. Een afzender die zich niet correct kan authenticeren, heeft de betrokkenheid van de bedrijfseigenaar nodig. Door beide items een DNS upgrade te noemen, wordt het werk verborgen.
Bouw een gereedheidsregister
Het volgende is een illustratief planningsregister, geen beoordeling van een echt domein:
| Finding | Work required | Evidence of completion |
|---|---|---|
| Uitrolinstructies gaan uit van procentuele steekproeven | Test de binaire vlag met behulp van de onderstaande gecontroleerde armaturen | Opgenomen verklaarde beoordeling, beoordeling na de testvlag en onafhankelijke ontvangerbeslissing |
| De rapportparser gaat uit van één verouderd schema | Controleer geaccepteerde formaten, velden en foutafhandeling | Versies van geldige, verouderde en misvormde armaturen |
| Kritische applicatie heeft geen bekende eigenaar | Breng de bedrijfsservice en ondersteunde identiteiten tot stand | Genoemde eigenaar en geverifieerd voorbeeld van ontvangen bericht |
| DNS editor wordt beheerd door een extern team | Ga akkoord met goedkeurings- en herstelverantwoordelijkheden | Exact wijzigingsvoorbeeld, goedkeuring en restauratiemateriaal |
De volgende synthetische armaturen specificeren de verwachte resultaten voor een gecontroleerde beoordelaar die RFC 9989 implementeert. Het zijn testinvoer, geen sjablonen voor productierecords of reeds uitgevoerde tests. Stel dat er een geldig toepasselijk beleid is ontdekt en dat het testbericht DMARC mislukt.
| Fixture | Input | Verwachte observatie op beleidsniveau |
|---|---|---|
| Vlag testen | p=reject; t=y | Validation remains fail; beoordeling na t=y is quarantaine, in plaats van de aangegeven afwijzing |
| Flag at none | p=none; t=y | De vlag laat het gedrag van geen beoordeling en het genereren van rapporten ongewijzigd |
| Non-existent child | Een heersend organisatiedomeinbeleid heeft p=none; sp=quarantine; np=reject, met standaard t=n; het kind wordt als niet-bestaand beschouwd en heeft geen direct beleid | De toepasselijke kindbeoordeling is afwijzen, in plaats van de sp-waarde van het bestaande kind |
Leg de evaluatorversie, input, waargenomen validatie, geselecteerde beoordeling en eventuele uiteindelijke afhandeling afzonderlijk vast. Een gecontroleerd armatuur stelt het geteste gedrag vast; het bewijst niet dat elke internetontvanger dezelfde regels toepast. Een quarantaineobservatie op beleidsniveau is geen universele belofte van plaatsing in spammappen.
Controleer ook de geschiktheid van het beleid. RFC 9989 section 7.4 raadt afwijzing voor e-maildomeinen voor algemene doeleinden af, omdat legitieme indirecte routes, inclusief mailinglijsten, kunnen breken. Een gereedheidsbeoordeling moet deze routes identificeren en de toepasselijke interoperabiliteitsrichtsnoeren beoordelen voordat sterker beleid wordt voorgesteld.
Houd configuratiewijzigingen gescheiden van software- of proceswijzigingen. Sommige bevindingen behoeven geen onmiddellijke DNS bewerking. Anderen vereisen een providerupdate, een parserfix of een gecontroleerde implementatietest.
Controleer de interoperabiliteit en de grenzen van een gereedheidsclaim
Een gereedheidsclaim moet de reikwijdte ervan benoemen. Bestrijkt het de domeinportfolio, de beleidsbeoordelaar, de rapportverwerker, of alleen? een record rekening? Dit zijn verschillende beoordelingen.
Gebruik het register om implementatieversies en onopgeloste verschillen bij te houden. Selecteer toepasselijke cases uit bestaande en niet-bestaande subdomeinen, uitlijningsmodi, indirecte mail en DNS fouten.
Behandel de discretie van de ontvanger als onderdeel van het bedrijfsmodel. Het publiceren van een specificatie zorgt er niet voor dat iedere ontvanger zich hetzelfde gedraagt. Een gepubliceerde weigeringsvoorkeur is ook geen bewijs dat elke ontvanger elk falend bericht heeft afgewezen.
Handhaaf onafhankelijke controles voor gecompromitteerde accounts, misleidende weergavenamen, vergelijkbare domeinen en goedkeuringen voor gevoelige bedrijven. DMARC gereedheid verandert domeinauthenticatie niet in een oordeel over de veiligheid van de inhoud van een bericht.
Breng de vereiste wijzigingen aan en verifieer deze
Vóór een productiewijziging moet u de vorige toestand behouden, de getroffen stromen identificeren, de juiste goedkeuring verkrijgen en de herstelvoorwaarden definiëren. Controleer vervolgens zowel de gepubliceerde configuratie als de representatieve berichten via de volledige verzendroute.
Als een resultaat niet overeenkomt met het verwachte gedrag, onderbreek dan de uitbreiding naar andere domeinen en los de compatibiliteitsbevinding op of accepteer deze expliciet.
Gebruik voor de onderliggende identiteiten de diagnosegids voor uitlijning. Voor een eerste configuratie volgt u de DMARC -creatie- en verificatieworkflow. Gebruik voor de rapportagelaag de walkthrough van het samengestelde rapport.
De praktische afhaalmaaltijd
Sluit de beoordeling af wanneer elke toepasselijke bevinding een eigenaar, een ondersteund besluit en reproduceerbaar bewijsmateriaal heeft. Houd onopgeloste implementatieverschillen zichtbaar, verifieer kritische berichten en rapportverwerking en behoud de goedgekeurde herstelvoorwaarden. Een gereedheidslabel moet naar die record verwijzen en deze niet vervangen.