In this guide · 8 sections
Short answer
RFC 9989 makes pct, rf and ri historic and adds t (test mode), np (policy for non-existent subdomains) and psd. Most records like v=DMARC1; p=quarantine; rua=... still work unchanged. If you used pct to roll out slowly, replace it with t=y or simply move policy step by step.
What RFC 9989 is, and why it matters now
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the DNS record that tells Gmail, Outlook and other receivers what to do with mail that claims to come from your domain but fails SPF and DKIM checks. Until 2026 its rulebook was RFC 7489, an Informational RFC published outside the IETF standards process.
RFC 9989, dated May 2026, is a Standards Track document. Its header says it obsoletes RFC 7489 and RFC 9091 (the experimental public suffix DMARC spec). Reporting moved into two companion documents, RFC 9990 for aggregate reports and RFC 9991 for failure reports. Mailbox providers and DMARC tools will move to the new text over time, so it is worth knowing what changed before a report tool or a DNS checker starts flagging your record.
Why pct was dropped and what t=y does instead
Many rollout guides told domain owners to move from p=none to p=quarantine with pct=10, then 25, 50 and 100. Appendix A.6 of RFC 9989 explains why that stopped: operational experience showed pct "was usually not accurately applied" unless the value was 0 or 100, and results varied widely between receivers.
The value pct=0 had become useful for another reason. Some mailing lists and forwarders treated it as a signal to rewrite the From header, which let domain owners see how much mail would break before enforcing. The new t tag keeps that: t=y is meant to work like pct=0 and t=n (the default) like pct=100. Section 4.7 says that with t=y, a quarantine policy is applied as none and a reject policy as quarantine.
Old rollout (RFC 7489)
- p=quarantine; pct=25
- Receivers applied the percentage inconsistently
- pct is now historic and ignored
Best for: Records you inherited and have not reviewed.
New rollout (RFC 9989)
Use this- p=quarantine; t=y while you test
- Receivers treat it as one step softer
- Remove t=y when reports are clean
Best for: Anyone moving to enforcement in 2026 or later.
If your record still says pct=50, a receiver following the new standard ignores pct and applies your p value to all failing mail. In other words, your policy is now fully on. Check your aggregate reports before assuming the slower rollout is still happening.
The np tag and the new DNS tree walk
Attackers often spoof made-up subdomains such as invoices.yourcompany.com.sg. RFC 9989 imports the np tag from RFC 9091 so you can set a policy just for subdomains that do not exist in DNS. If np is absent, the sp policy applies, and if sp is also absent, the p policy applies (section 4.7). For most small businesses with p=reject or p=quarantine already, the default behaviour covers non-existent subdomains, so np is optional.
The bigger technical change is how receivers find your organisational domain. RFC 7489 relied on the Public Suffix List; RFC 9989 replaces that with a "DNS Tree Walk" (section 4.10) that queries up the domain labels, capped at eight queries. Appendix C.3 notes that receivers still using RFC 7489 and receivers using RFC 9989 could reach different answers in unusual set-ups, and says this is avoided by publishing explicit DMARC records for every domain you send from. For a .com.sg or .sg domain with one DMARC record at _dmarc.yourdomain, nothing changes.
Should you still aim for p=reject?
Section 7.4 adds advice that RFC 7489 did not spell out. It says domains with staff who might post to internet mailing lists SHOULD NOT publish p=reject, because list forwarding breaks SPF and can get subscribers removed from lists. Domains that do publish p=reject MUST sign with DKIM and not rely on SPF alone. It also suggests p=none for at least a month, then p=quarantine for a similar period, before reject.
For most Singapore SMEs that use Microsoft 365 or Google Workspace for normal staff email, p=quarantine with DKIM on every sending service is a sensible end point. Reject suits domains that only send invoices or notifications. Our guide to choosing between none, quarantine and reject walks through the decision, and Microsoft's DMARC set-up page and Google's DMARC help cover the provider side.
Five-minute check of your DMARC record
Look up your current record with any DNS lookup tool (query TXT on _dmarc.yourdomain.com.sg), then work through these steps.
Confirm there is exactly one DMARC record
Section 4.10 says that if more than one DMARC record is returned for the same name, all are discarded. Two records means no DMARC at all.
Check that v=DMARC1 comes first
The record must start with v=DMARC1. Anything else makes receivers ignore the whole record.
Remove pct, rf and ri
They no longer do anything under RFC 9989. Removing them avoids confusion when someone reads the record later.
Add t=y only if you are mid-rollout
If you are testing quarantine or reject, use t=y while you read reports, then remove it.
Keep rua pointing at a mailbox or tool you read
Without rua, receivers must not send aggregate reports (section 4.7). Our DMARC report tools comparison covers free and paid options.
A clean small-business record after RFC 9989 can be as short as v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com.sg. If mail is already landing in spam, fix SPF and DKIM first; our guide to SPF, DKIM and DMARC for spam problems explains the order.
Do it yourself or get help?
If you have one domain, one email provider and a DMARC record you set up yourself, the RFC 9989 clean-up is a two-minute DNS edit. It gets harder when several services send as your domain (newsletter tool, accounting software, website forms) and you are not sure which ones pass DKIM.
RFC 9989 record check
IT Sorted is a Singapore-based team of developers with over 10 years of experience. Our Emails Land in Spam: Fix (S$249) inventories every service sending as your domain, sets up SPF, DKIM and DMARC, monitors DMARC for 14 days and then moves you to enforcement safely. If you only need records added or a domain moved, Domain & DNS Setup (S$99) covers that.
Frequently asked questions
Usually not. A record with v=DMARC1, a p policy and an rua address stays valid. RFC 9989 tells receivers to ignore tags they do not recognise, so old tags such as pct do not break the record. It is still worth removing pct, rf and ri so nobody assumes they still have an effect.
RFC 9989 marks pct as historic and no longer lists it as a valid tag, so a receiver that follows the new standard ignores it and applies your p policy to all failing mail. If you were relying on pct to soften a rollout, use t=y instead while you test, then remove it when reports are clean.
It is the new test mode tag from RFC 9989. With t=y, you ask receivers to apply one level less than your stated policy: quarantine is treated as none and reject as quarantine. Reports are still sent as normal. The default is t=n, which applies the policy as written.
Only if you want a different policy for subdomains that do not exist in DNS. Without np, the sp policy applies, and without sp, your main p policy applies to all subdomains. If your p is already quarantine or reject, made-up subdomains are already covered.
RFC 9989 says domains whose users might post to mailing lists should not publish p=reject, and that any domain using reject must sign mail with DKIM. Many small businesses are better served by p=quarantine. Domains used only for invoices or system notifications can use reject after a period of clean reports.