DMARCbis changes how parts of DMARC are specified and implemented. It does not ask you to rename your record to DMARC2. The core specification, RFC 9989, was published in May 2026, while RFC 9990 and RFC 9991 cover aggregate and failure reporting separately.
The practical task is to work out which changes affect your domain, your sending services and the software that processes your authentication data. That starts with understanding the current specifications, then comparing them with the configuration and processes already in use. The result should be a clear readiness register with evidence, owners and a decision for each finding.
Map the three specifications to your systems
Use the current documents for their respective jobs:
| Document | What to review |
|---|---|
| RFC 9989 | Core DMARC evaluation, policy discovery, alignment and record semantics |
| RFC 9990 | Aggregate reporting format, generation and processing |
| RFC 9991 | Failure reporting and its handling considerations |
Start with the existing record and configuration history. Do not delete an operating record simply because an older guide cites RFC 7489. Identify the instructions that changed and the software that implements them.
The main review areas include the following:
- Domain discovery: RFC 9989 section 4.10 defines DNS tree walking. Review systems that assume an older public-suffix-list discovery model.
- Policy tags: Check the current IANA registry. The
pct,rfandritags are historic. Assesst,npandpsdby their actual scope rather than adding them as an upgrade checklist. - Testing: Establish how the relevant evaluator implements the binary
tsignal. A declared testing state and a receiver's final disposition are different observations. - Reporting: Confirm that collectors and parsers handle the report formats and fields you expect to receive, without losing relevant legacy observations.
The version marker remains v=DMARC1. Do not substitute DMARC2 or mechanically replace an old percentage with a testing flag.
Translate the changed tags into tests
The t flag defaults to n, requesting application of the declared assessment to DMARC failures. Setting t=y signals that the owner is testing rather than asking for the declared assessment to be applied directly. RFC 9989 section 4.7 defines a one-level reduction for failing messages: reject becomes quarantine, and quarantine becomes none. Implementations may also have relevant special handling.
The flag does not change a failed authentication result into a pass, alter report generation, or affect a none policy. It is binary, not a request to sample an arbitrary percentage of mail. Establish implementation support before relying on it for real traffic, and keep receiver-local filtering separate from the policy-level test result.
Two other tags affect the scope of the assessment:
- np: Specifies the assessment for non-existent subdomains of the prevailing organisational domain. If absent, the applicable fallback is sp when present, otherwise p. A missing MX record alone does not establish non-existence.
- psd: Marks domain-boundary information used during discovery. The default u leaves boundary determination to the discovery rules; y identifies a public suffix, while n identifies a non-public-suffix organisational boundary for itself and its subdomains. Do not set either explicit boundary value without establishing that it describes the domain correctly.
An ordinary organisation should not label its domain as a public suffix merely to claim readiness. Review actual discovery assumptions and delegated namespaces. The subdomain policy guide covers the narrower inheritance question.
Identify the mail that must keep working
A domain may represent much more than employee email. It can appear on invoices, login links, customer alerts and messages sent by outside agencies. A standards update is an opportunity to check those dependencies before a rushed configuration change disrupts them.
Ask for three deliverables: an inventory of the services using your identity, an explanation of the specific changes that affect you, and a test plan for critical messages. The answer should distinguish a published specification from a feature already deployed by a particular receiver or software service.
Allocate ownership as well as budget. A report-processing change needs someone responsible for the reporting pipeline. A sender that cannot authenticate correctly needs its business owner involved. Calling both items a DNS upgrade hides the work.
Build a readiness register
The following is an illustrative planning register, not an assessment of a real domain:
| Finding | Work required | Evidence of completion |
|---|---|---|
| Rollout instructions assume percentage sampling | Test the binary flag using the controlled fixtures below | Recorded declared assessment, assessment after the testing flag and independent receiver decision |
| Report parser assumes one legacy schema | Review accepted formats, fields and error handling | Versioned valid, legacy and malformed fixtures |
| Critical application has no known owner | Establish the business service and supported identities | Named owner and verified received-message sample |
| DNS editor is controlled by an outsourced team | Agree approval and recovery responsibilities | Exact change preview, approval and restoration material |
The following synthetic fixtures specify expected results for a controlled evaluator implementing RFC 9989. They are test inputs, not production record templates or tests already performed. Assume a valid applicable policy is discovered and the test message fails DMARC.
| Fixture | Input | Expected policy-level observation |
|---|---|---|
| Testing flag | p=reject; t=y | Validation remains fail; assessment after t=y is quarantine, rather than the declared reject |
| Flag at none | p=none; t=y | The flag leaves the none assessment and report-generation behaviour unchanged |
| Non-existent child | A prevailing organisational-domain policy has p=none; sp=quarantine; np=reject, with default t=n; the child is established as non-existent and has no direct policy | The applicable child assessment is reject, rather than the existing-child sp value |
Capture the evaluator version, input, observed validation, selected assessment and any final handling separately. A controlled fixture establishes the behaviour tested; it does not prove every Internet receiver implements the same rules. A policy-level quarantine observation is not a universal promise of spam-folder placement.
Review policy suitability as well. RFC 9989 section 7.4 advises against reject for general-purpose email domains because legitimate indirect routes, including mailing lists, can break. A readiness review should identify those routes and assess the applicable interoperability guidance before proposing stronger policy.
Keep configuration changes separate from software or process changes. Some findings need no immediate DNS edit. Others require a provider update, a parser fix or a controlled implementation test.
Check interoperability and the limits of a readiness claim
A readiness claim should name its scope. Does it cover the domain portfolio, the policy evaluator, the report processor, or only a record check? These are different assessments.
Use the register to track implementation versions and unresolved differences. Select applicable cases from existing and non-existent subdomains, alignment modes, indirect mail and DNS failures.
Treat receiver discretion as part of the operating model. Publication of a specification does not make every receiver behave identically. A published reject preference is also not evidence that every recipient rejected every failing message.
Maintain independent controls for compromised accounts, deceptive display names, lookalike domains and sensitive business approvals. DMARC readiness does not turn domain authentication into a verdict on the safety of a message's content.
Make and verify the required changes
Before a production change, preserve the previous state, identify affected flows, obtain the appropriate approval and define recovery conditions. Then verify both the published configuration and representative messages through the complete sending route.
If a result disagrees with the expected behaviour, pause expansion to other domains and resolve or explicitly accept the compatibility finding.
For the underlying identities, use the alignment diagnosis guide. For an initial configuration, follow the DMARC creation and verification workflow. For the reporting layer, use the aggregate-report walkthrough.
The practical takeaway
Close the assessment when each applicable finding has an owner, a supported decision and reproducible evidence. Keep unresolved implementation differences visible, verify critical messages and report processing, and retain the approved recovery conditions. A readiness label should point to that record, not replace it.