DMARC Is Now an Internet Standard. What RFC 9989 Actually Changes in Your DNS

Most companies set up a DMARC record once, usually because a marketing platform asked for it, and never touch it again. In May 2026 the IETF published RFC 9989, which replaces the original 2015 DMARC specification. Nothing in your DNS broke that day, and nothing needs an emergency fix. But three tags in a typical record are now officially obsolete, the mechanism receivers use to find your policy has been replaced entirely, and the guidance on the strictest policy setting has been reversed. If your record was written five years ago, parts of it now describe a protocol that no longer exists in that form.

1. What was published, and what it means

In May 2026 the IETF published three documents: RFC 9989 (the core DMARC protocol), RFC 9990 (aggregate reporting), and RFC 9991 (failure reporting). Together they obsolete RFC 7489 and RFC 9091. RFC 7489 was published in 2015 as an Informational document through the Independent Submission Stream — a description of what the industry was doing, not a standard the IETF had endorsed. RFC 9989 is Standards Track, at Proposed Standard maturity. For eleven years DMARC was a widely deployed convention with ambiguities that different vendors resolved differently. It is now a specification with formal consensus behind it. What did not change: records still begin with v=DMARC1. There is no DMARC2. Unknown tags must be ignored by receivers, so every record deployed today keeps working. This is a cleanup, not a migration.

2. Three tags in your record are now dead

The IANA DMARC Tags registry has been updated. Three tags are marked historic — deprecated and not expected to appear in any current implementation:

• pct (sampling rate). The tag that let you apply a policy to a percentage of failing mail is gone. RFC 9989 explains the reasoning in Appendix A.6.
• rf (failure report format).
• ri (aggregate reporting interval). Receivers should generate aggregate reports at least every 24 hours regardless.

In their place, t is now a registered tag: DMARC policy test mode, with values y or n and a default of n. Setting t=y asks the receiver to apply the level below your stated policy. p=reject; t=y → treated as quarantine. p=quarantine; t=y → treated as none. This is the intended replacement for staged rollouts with pct. Two other tags are active and underused: np (policy for non-existent subdomains) and psd (declares whether a domain is a public suffix).

3. The Public Suffix List is gone, replaced by the DNS Tree Walk

This is the largest technical change in the specification. Under RFC 7489, receivers used a Public Suffix List to work out the organizational domain for a given sending domain. The old spec never mandated a specific list, gave no guidance on how often to refresh it, and acknowledged that different receivers using different lists would produce inconsistent results. RFC 9989 replaces that with the DNS Tree Walk. A receiver queries _dmarc at your Author Domain first. If there is no valid record, it walks up the namespace one label at a time. To prevent abuse, the walk is capped at eight queries. Two practical consequences:

1. If you send from a domain with more than eight labels, publish a record at that exact name. A record at an intermediate zone cut will never be discovered by the walk.
2. Large organizations with decentralised DNS gain a tool. Publishing psd=n on a subdomain declares it as its own organizational domain, so a department can run its own policy without touching the apex record.

The general rule has not changed: publish explicit DMARC records on the domains you actually send from.

4. The guidance on p=reject has flipped

For years the standard advice was to march every domain from p=none to p=quarantine to p=reject. RFC 9989 is noticeably more cautious, and the caution is normative:

• Domains that host users who might post to Internet mailing lists should not publish p=reject. Mailing lists and forwarders routinely break SPF alignment, and a reject policy causes list software to unsubscribe your users automatically.
• Domains that do publish p=reject must not rely on SPF alone, and must apply valid DKIM signatures. DKIM signatures usually survive forwarding. SPF usually does not.
• Receivers must not reject a message solely because the sending domain publishes p=reject. In the absence of other analysis they should treat such mail as quarantine.
• To move to reject: publish p=none for at least a month, then p=quarantine for an equally long period, compare the disposition results before deciding.

This is not a retreat from enforcement. It is a recognition that eleven years of production experience showed reject causing collateral damage on indirect mail flows that nobody has yet solved technically.

5. What mailbox providers enforce, which is a separate question

The RFC describes the protocol. Google, Yahoo, and Microsoft describe the conditions under which your mail reaches their users. Google: since February 2024, senders of more than 5,000 messages a day to personal Gmail accounts must have both SPF and DKIM, a DMARC record on the sending domain (none is acceptable), From alignment with the SPF or DKIM domain, one-click unsubscribe on bulk mail, and spam rates below 0.3 percent. From November 2025 Google began ramping enforcement, with disruptions including temporary and permanent rejections. Microsoft: effective 5 May 2025, domains sending more than 5,000 messages a day to outlook.com, hotmail.com, and live.com need SPF, DKIM, and DMARC of at least p=none. Non-compliant mail goes to Junk first, then rejection with 550 5.7.515 Access denied, sending domain does not meet the required authentication level. Yahoo applies equivalent requirements. Note the shape of this: the RFC lowers the temperature on p=reject while the providers raise the floor on having authentication at all. These are not in conflict. Publish records everywhere, authenticate properly with both mechanisms, and be deliberate about enforcement level.

6. Two SPF traps the specification calls out by name

Hard fail can hide your problems. If your SPF record ends in -all, a receiver may reject the message early in the SMTP transaction, before DMARC is ever evaluated. Because the session never reaches the DATA phase, the From domain is never revealed and the message never appears in your aggregate reports. Mail that would have passed DMARC on an aligned DKIM signature gets rejected on SPF alone — invisibly. Delegated subdomains can forge your main domain. With relaxed alignment, if an attacker controls DNS for a subdomain of your organizational domain and publishes an SPF record there, they can send mail with your apex domain in the From field and obtain a DMARC pass. The mitigations are strict alignment, explicit DMARC records on every sending domain, careful control of subdomain delegation, and the ? qualifier on permissive sources in your SPF record.

7. A 30-minute check you can run today

# Your DMARC policy
dig +short TXT _dmarc.yourdomain.com

# Your SPF record
dig +short TXT yourdomain.com | grep spf1

# A DKIM selector, if you know it
dig +short TXT selector._domainkey.yourdomain.com

Then answer six questions:

1. Does the record contain pct, rf, or ri? Schedule their removal.
2. Is there a rua address, and is anything actually parsing the reports that arrive there? A reporting address nobody reads is not monitoring.
3. Do all of your sending domains have their own record, including subdomains used by CRM, ticketing, invoicing, and marketing platforms?
4. Do your parked and non-sending domains publish p=reject; np=reject? No mail flow means no interoperability risk.
5. If your policy is p=reject, is DKIM signing in place on every mail stream, or are you leaning on SPF?
6. When did anyone last read an aggregate report and act on it?

8. Why this matters specifically in Moldova and Romania

NIS2 Article 21(2) requires risk management measures and basic cyber hygiene. It does not name DMARC. What happens in practice is that assessors treat SPF, DKIM, and DMARC as the accepted technical implementation of risk management on the email channel. Publishing a record does not make you compliant, and the absence of one is hard to defend during an assessment. Romania: NIS2 transposed through OUG 155/2024, approved by Law 124/2025, in force since 10 July 2025. The competent authority is DNSC. Orders 1 and 2/2025 of the DNSC director (Monitorul Oficial no. 776, 20 August 2025) set out registration and risk assessment criteria for essential and important entities. Moldova: Law 48/2023 on cybersecurity in force since 1 January 2025. Government Decisions 860/2024 and 562/2025 identify critical sector providers and their obligations — deliberately aligned with the EU accession agenda. Personal data: Moldova's Law 195/2024 comes into force 23 August 2026. Domain spoofing ending in a fraudulent payment or harvested credentials is a security incident with a data protection dimension. One local detail worth checking first: most companies in Moldova and Romania run Google Workspace or Microsoft 365 for staff mail, then send everything else — invoicing software, hosting panel, CRM, booking system — from somewhere different. The Workspace or 365 domain is usually authenticated correctly. It is the other four or five senders that break alignment, and nobody remembers they exist until a customer says the invoice never arrived.

SECURITY · EMAIL SECURITY HARDENING

Can someone send email as your domain today?

SPF, DKIM, and DMARC configuration aligned with RFC 9989, an audit of every system that sends mail on your behalf, aggregate report monitoring, and a staged path to enforcement without breaking legitimate mail. From 400 EUR.

3 DAYS

FULL DELIVERY

Harden your email →

How the WebDirect team helps

Most email authentication problems are not a missing DNS record. They are the four forgotten systems that send mail on your behalf, the subdomain nobody documented, and the reject policy published without DKIM behind it. The WebDirect team audits the full sending surface for companies in Moldova, Romania, and the EU, brings records in line with the current specification, and moves domains toward enforcement at a pace that does not break invoices and password resets along the way. If you want to know who can send mail as your domain today, get in touch.

Sources

• RFC 9989, DMARC, IETF, May 2026.
• RFC 9990, DMARC Aggregate Reporting, IETF, May 2026.
• RFC 9991, DMARC Failure Reporting, IETF, May 2026.
• Google, Email sender guidelines, support.google.com.
• Microsoft, Outlook's New Requirements for High Volume Senders, April 2025.
• Directive (EU) 2022/2555 (NIS2), Article 21.
• Romania: OUG 155/2024, Law 124/2025, DNSC Orders 1 and 2/2025.
• Moldova: Law 48/2023, Government Decisions 860/2024 and 562/2025.
• Moldova: Law 195/2024 on personal data protection.

This material is for informational purposes only and does not constitute legal advice.

Frequently asked questions

Does RFC 9989 mean I have to rewrite my DMARC record?
No. Records still start with v=DMARC1 and every valid record deployed today continues to work, because receivers must ignore tags they do not recognise. Remove the deprecated pct, rf, and ri tags at your next DNS change and make sure you publish records on all domains you send from.What replaced the pct tag?
The t tag, DMARC policy test mode. Publishing t=y asks receivers to apply the policy one level below the one you declared: p=reject; t=y is treated as quarantine, p=quarantine; t=y is treated as none. It is a cleaner way to stage a rollout than percentage sampling.What is the DNS Tree Walk?
The mechanism that replaced the Public Suffix List for policy discovery. A receiver queries _dmarc at your sending domain, and if no valid record is found it walks up the namespace one label at a time, up to eight queries. If you send from a domain with more than eight labels, you need to publish a record at that exact name for it to be found.Should we set p=reject?
Only after DKIM signing is in place on every mail stream and after you have reviewed aggregate reports. RFC 9989 advises against p=reject for domains whose users post to mailing lists, and requires that domains publishing reject do not rely on SPF alone. Parked and non-sending domains are a different case: those can go to reject immediately.Do the Gmail and Outlook rules apply to us if we only send a few hundred emails a day?
The 5,000 messages per day thresholds define who is required to comply. Below that, authentication is still checked and still affects inbox placement, and a spoofable domain remains spoofable regardless of volume. Treat the requirements as the baseline, not a ceiling.Does DMARC satisfy NIS2?
No single control satisfies NIS2. Article 21 does not name DMARC. In practice, email authentication is treated as the accepted implementation of email channel risk management and is normally expected during an assessment.How much does an email security audit cost?
Email Security Hardening (SPF, DKIM, DMARC configuration, anti-phishing measures, and an audit of your email infrastructure) starts at 400 EUR, delivered within 3 business days.