DMARC in 2026: what RFC 9989 changes for email senders

One protocol, three specifications

DMARC connects SPF or DKIM authentication to the visible From domain and lets a domain owner publish a requested policy for failing messages. The 2026 update separates that protocol from its reporting formats.

All three have Proposed Standard status on the IETF Standards Track. RFC 7489 was Informational. These are specification changes, not evidence that every mail service has switched implementations.

• Review DMARC alignment and policy

The important changes are in discovery and policy tags

RFC 9989 replaces reliance on a Public Suffix List with a bounded DNS Tree Walk for policy discovery and organizational-domain determination. This matters when a message uses subdomains and when a parent domain publishes policy.

Use this table to ask informed questions, rather than adding or deleting tags mechanically. Check the source record and your provider’s supported behavior before making a change.

• RFC 9989 Appendix C — changes from RFC 7489

A passing result still needs an aligned identity

A message needs at least one passing SPF or DKIM identity aligned with its From domain to pass DMARC. A passing signature belonging only to an unrelated provider does not establish that connection.

For a practical investigation, record the visible From domain, the SPF identity, each relevant DKIM signing domain and the receiving system’s DMARC result. If two reports differ, compare their original headers and sending routes before treating one as wrong.

• Work through SPF and DKIM passing while DMARC fails
• Find the original receiving headers

Stricter policy is a decision about your mail flows

Do not treat p=reject as an automatic end point for every domain. RFC 9989 advises general-purpose email domains against it because ordinary mail can travel through mailing lists and forwarding services that create interoperability problems.

Start by identifying who sends for your domain and how legitimate messages reach recipients. Review aggregate reports alongside individual message tests before deciding whether enforcement is appropriate. A passing test from one mailbox does not cover every newsletter, invoice system or forwarded message.

• RFC 9989 §7.4 — interoperability considerations
• Inventory your sending services

What should you do with your current setup?

Keep a baseline before changing provider settings or DNS. The useful comparison is the same sending service before and after an explainable change.

1. Capture a real message from each service

   Record its From domain, authentication identities, receiving provider and test date. Include the actual route you are troubleshooting.

2. Ask your provider about its implementation

   Use the RFC numbers and the discovery or tag behavior you need to understand. Do not infer a receiver’s supported version from the publication date alone.

3. Separate message tests from reporting

   A temporary CheckDMARC address tests a message. It is not an aggregate-report collection mailbox and should not be used as your rua destination.

4. Test again after an agreed change

   Allow for DNS caching and repeat the same sending route. If the issue involves a forwarded or list-delivered message, keep the original headers from that destination as well.

• Follow the testing walkthrough
• Create a test address

What CheckDMARC can tell you today

CheckDMARC interprets receiver authentication results and adds current DNS evidence and limited alignment diagnostics. Its computed fallback and alignment display are not a complete RFC 9989 implementation. Pasted headers also do not independently verify a DKIM signature or an ARC chain.

Use the report to investigate one message, keeping the receiver’s recorded result distinct from current DNS and locally computed checks. CheckDMARC does not collect aggregate or failure reports; the reporting RFCs explain a separate part of operating a domain’s email.

• Read the test’s limits
• Explore a fictional sample report