A new standard, not an instruction to rebuild
Published in May 2026, RFC 9989 replaces the earlier DMARC specification. Its changes include removal of the percentage parameter pct.
For a business, the immediate task is an inventory review: what is published in DNS, what assumptions appear in the operating notes and who can approve a change? Publication does not demonstrate which version an individual mail provider has implemented. Ask about the systems you actually use. Replacing working DNS records wholesale would be the wrong first step. [1]
Your main mailbox is only one route
Include website forms, invoicing software, support platforms and newsletter services alongside ordinary mailboxes. Give each route an owner and record its visible sender address, sending service and a checked sample message. A successful message from webmail does not establish that the website sends correctly.
A useful review question is concrete: can the billing platform send an invoice using the intended sender domain, and can you demonstrate that from the received original? Retain the relevant headers with a timestamp. Credentials and message contents do not belong in a generally accessible DNS inventory.
DMARC passes when at least one of SPF or DKIM succeeds and its domain aligns with the visible From domain under the selected alignment mode. [1]
Sending route
Record the mailbox, website, CRM or billing service and its owner.
Authentication
Inspect SPF and DKIM results on an actual received message.
Domain alignment
Compare the authenticated domains with the visible From domain.
Evidence for each route
Record the result, time and required change. Domain authorisation does not establish that message content is trustworthy.
An illustrative review path. Assess the authentication routes separately, including their relationship to the visible From domain.
Revisit assumptions in older rollout plans
Look closely at instructions that describe gradual deployment using only pct=10 or pct=25. The earlier specification included that mechanism. Such instructions do not establish how every current receiving system behaves.
For each change, define a limited set of sending routes, a responsible person and the configuration to restore if validation fails. Confirm support with the provider concerned. There is no reason to weaken an existing, demonstrably working policy merely to perform this review. [5]
Swipe or scroll sideways to read the table.
| Area | Evidence required | Decision |
|---|---|---|
| Sending inventory | Every authorised sending service has an owner. | Investigate unidentified sources first. |
| Policy | The current DNS value and the rollback value are recorded. | Approve a traceable change. |
| Compatibility | The provider confirms behaviour in the environment concerned. | Do not assume universal implementation. |
| Acceptance | Each agreed sending route has been checked. | Then move to the next set of routes. |
Use reports to assign work
Aggregate DMARC reports describe observed sending sources and authentication results. Failure reports are a separate report type and may contain additional message data.
Our recommendation is to turn each unexpected route into an assigned investigation: is it an approved service, who will resolve it and when will it be checked again? An unfamiliar record is initially a question to investigate. Equally, a report without anomalies does not replace your own inventory. Decide who may access report files and when they will be deleted. [2] [3]
Keep provider requirements separate
Gmail distinguishes ordinary senders from bulk senders. Google requires SPF, DKIM and DMARC for the latter, and permits a DMARC policy of none for that requirement.
That minimum does not determine the protection policy appropriate for your domain. Keep two objectives in the review: meeting the destination provider’s rules and establishing a dependable authorised sending inventory. Actual delivery and spam placement remain separate observations. [4]
A practical next step
Choose a route that matters commercially, such as quotations or invoices. Use the following checklist to define an evidence-based change without altering the whole mail operation at once. The result should name the person responsible and retain enough information for someone else to repeat the check.
- Save the current DMARC record and operating instructions.
- List active sending services and their responsible owners.
- Review an authorised test message for every relevant route.
- Resolve old percentage rollout assumptions and provider support.
- Agree a change window, acceptance criteria and rollback procedure.
- After the change, review reports alongside actual delivery.