DMARC none to reject: the rollout steps, and where 3,034 software domains sit today

DMARC none to reject is a choice, not a requirement: Google, Yahoo and Microsoft all accept p=none from bulk senders. For a newsletter, the order we'd use is p=none with reports, then quarantine, then reject, on a sending domain you control. We also counted what 3,034 listed software domains publish today.

We read the provider pages and RFC 9989 on 28 October 2026. Sender rules and DNS standards change, so check the current pages before you edit a record. This is not legal or deliverability advice: a wrong policy can bounce your own mail, so test on a low-stakes stream first.

Why dmarc none to reject is optional for bulk senders

All three big mailbox providers set the same floor. None of them asks you to reach reject, and they differ mainly in who counts as a bulk sender.

Microsoft's page says non-compliant mail from high-volume senders goes to the junk folder and, "if issues remain unresolved," may be rejected with error 550; 5.7.515. Microsoft is the one provider that names the consequence and the error code, and it concerns missing or failing authentication, not being stuck at none.

So why go further? The p tag decides what a receiver is asked to do with mail that fails: Google's setup page says none means "take no action on the message and deliver it to the intended recipient," while quarantine sends it to spam and reject refuses it. In our reading, only the last two stop someone else from sending as your domain. Google's page also notes that if your domain uses BIMI, the policy must be quarantine or reject. That is the practical reason to leave none, and it is a reason of your own, not a provider rule.

Where 3,034 software domains sit: 73% already enforce

We ran the same lookups on every product site in the directory. On 28 October 2026 we queried DNS TXT records (through the 1.1.1.1 resolver) for the website host of each of Upfynd's 3,151 published listings, then reduced each host to its registrable domain. That is an approximation: the last two labels, or three for a short list of country suffixes such as co.uk, not the full Public Suffix List. It left 3,119 distinct domains. We dropped 11 shared or platform domains (such as google.com and github.io) and 74 with no MX record, which leaves 3,034. For each we read the DMARC record at the host, then at its parent domain. A re-check of 30 random domains through a second resolver (8.8.8.8) returned the same p value every time.

Three details matter more than the headline split.

• Monitoring with no one listening. 2,500 domains (82.4%) publish an rua address. But 176 of the 640 domains at p=none (27.5%) have none. RFC 9989 says that without the tag, receivers "MUST NOT generate aggregate feedback reports," so those domains are at none without the reports that would tell them when to leave it.
• Half-finished ramps. 91 of the 1,016 quarantine records (9.0%) still carry a pct value below 100, which means partial enforcement.
• SPF is near universal. 2,954 domains (97.4%) publish an SPF record, so the gap is in DMARC, not in basic authentication.

By primary category, Email & Newsletters is at the top: 46 of its 50 primary-category domains (92%) publish quarantine or reject, 36 of them reject. The lowest groups are Branding & Identity at 25 of 50 and Photography at 26 of 49. Each group is only about 50 domains, so read these as a tendency, not a ranking.

Two limits apply. A product's website domain is not always the domain it sends mail from, so this is a count of what public product sites publish, not an audit of anyone's email. And a higher reject share is not a score: as the next sections show, reject is the wrong setting for some domains.

The sending platforms themselves

Seven email platforms listed on Upfynd, with the record at their root domain on 28 October 2026. This is the root domain, not necessarily the domain that carries your mail.

How to check what your domain publishes today

Three DNS lookups tell you where you start. Replace example.com with your sending domain.

1. Run dig +short TXT _dmarc.example.com. Google's setup page puts the record at that host name. An empty answer means no DMARC record at that name.
2. Run dig +short TXT example.com and look for a line that starts with v=spf1. That is your SPF record.
3. Run dig +short TXT selector._domainkey.example.com, using the selector your sending platform gave you when you set up its domain authentication. A v=DKIM1 line means the key is published.

If step 1 is empty on a subdomain, check its parent: a subdomain with no record of its own is covered by the parent's record, using the sp tag if there is one and the p tag if not, per RFC 9989. For a real message, send one from the domain and paste its headers into Google's Messageheader tool, as Google's troubleshooting page suggests; it should show SPF, DKIM and DMARC all passing.

The dmarc none to reject rollout, step by step

Step 1: List every system that sends as your domain

Your newsletter platform is one of several. Helpdesk, CRM, billing and your own app's transactional mail can all send with your domain in the From line. Google's setup page tells you to make sure each third-party sender passes SPF and DKIM before you publish DMARC, and the reports in step 4 will show the ones you forgot.

In our view, give the newsletter its own subdomain, such as news.example.com, and publish the record there. A reject policy then covers a stream that only your sending platform uses, and the mailboxes your staff write from stay on a domain with a gentler policy.

Step 2: Get DKIM passing and aligned first

Google says SPF and DKIM should be authenticating mail for at least 48 hours before you turn DMARC on. A message passes DMARC if it passes SPF with SPF alignment or DKIM with DKIM alignment, so one aligned check is enough, but RFC 9989 is blunt about reject: domains that publish it "MUST NOT rely solely on SPF" and "MUST apply valid DKIM signatures."

Alignment is where newsletter platforms trip people. If the platform signs mail with its own domain, DKIM can pass without aligning to your From domain. Complete the platform's custom-domain authentication step, which usually means publishing the DNS records it gives you.

Step 3: Publish p=none with a place for reports

Add one TXT record at _dmarc.example.com with a value like this: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. Google's page says v and p must come first. It also advises a dedicated mailbox, a group or a third-party report service for the rua address, because a busy domain can receive many reports a day. If the address is on another domain, that domain needs a DNS record that authorizes it.

Step 4: Read the reports before you tighten anything

Google's rollout page says to start at none for one week, which it says is "usually enough time for the daily reports to contain data representative of all your mail streams." RFC 9989 asks for more from one kind of domain: those whose users might post to mailing lists should publish p=none "for at least a month," then p=quarantine for as long, before reject.

The sources differ, and the situations probably do too. In our view, a newsletter-only subdomain with one platform can follow Google's week, as long as the reports show every source passing. A domain that carries staff mail should take the RFC's month.

Step 5: Move to quarantine first

In the dmarc quarantine vs reject choice, quarantine in our view is the rehearsal. Failing mail lands in spam, where a recipient can still find it, instead of bouncing. Google's rollout example is p=quarantine; pct=5, and it says a small organization might start at 10% of messages. Keep reading reports through this stage. In our view, a legitimate sender that fails will show up as a failing source with real volume.

Step 6: Move to reject, keep the reports

When quarantine has run clean, change p to reject and keep the rua tag. A team that adds a new sending tool later may fail DMARC the first time it sends, and in our view the reports are how you find out. Then send a test message and check its headers again.

The dmarc pct tag: Google still recommends it, RFC 9989 removed it

Google's rollout page, last updated 2026-10-22, still uses pct to ramp enforcement. RFC 9989, published in May 2026, dropped the tag. Its Appendix A.6 says pct "was usually not accurately applied, unless the value specified was either 0 or 100," and that implementations varied widely. It replaces pct with a t tag, y or n, which stands in for pct values of 0 and 100. With t=y, a reject policy is treated by the receiver as quarantine and a quarantine policy as none.

We could not verify how much any receiver still honors pct, so treat a percentage ramp as approximate and judge each step by your reports, not by the number. In the directory, 4 of the 3,034 records carry a t tag; 91 quarantine records still carry a pct below 100.

Where reject goes wrong: forwarding, mailing lists and the sender you forgot

RFC 9989 explains why DKIM matters at reject. When mail is relayed through alumni forwarders, role-based aliases or mailing lists, it "will most likely fail SPF checks," while DKIM signatures "will generally remain valid." That is why the sentence about not relying solely on SPF exists.

The RFC goes further for ordinary mail domains. Domains that host users who post to mailing lists "SHOULD NOT publish" a policy of reject, and the change notes say domains for general-purpose email SHOULD NOT deploy it. It also says receivers "SHOULD NOT reject messages solely because of a published policy" of reject. So reject is a request, not a guarantee, and it is a poor fit for a domain your whole team writes from.

Skip reject if your staff mailboxes live on the same domain as your newsletter and some of them post to public mailing lists. Stay at quarantine on that domain and put the newsletter on its own subdomain with its own record, as in step 1. Skip DMARC changes entirely if nobody will read the reports: in our view a record you cannot learn from is a guess.

Pick the sending platform, then set the policy

The platform decides how easy steps 1 and 2 are. As of 28 October 2026, Upfynd lists 140 products in Email & Newsletters, from API senders to newsletter platforms. Whichever you use, look in its help center for custom-domain authentication before you plan the DMARC change, because that step determines whether your DKIM aligns.

Your next step takes a minute: run the first lookup above on your sending domain. If it comes back empty, publish p=none with an rua address today and set a reminder for a week from now.