How to Move DMARC from p=none to p=reject Without Blocking Your Own Email

You published a DMARC record with p=none months ago, and it's still sitting there. You know p=reject is the end goal, but you're worried that flipping it will bounce your own invoices, order confirmations or helpdesk replies, and you can't tell which of your tools would break.

That worry is reasonable. A p=reject policy tells every receiving server to refuse mail that claims to be from your domain but can't prove it, and that includes your own mail when a tool isn't set up properly. The fix is to find every sender first, then tighten the policy in stages. Here's how.

What p=none, quarantine and reject actually do

DMARC checks one thing: does the domain in the visible From address match a domain that passed SPF or DKIM? It passes if either of these is true:

• SPF passed, and the envelope sender domain (the Return-Path) matches your From domain.
• DKIM passed, and the signing domain (the d= value in the signature) matches your From domain.

"Matches" means aligned. By default alignment is relaxed, so news.yourdomain.com aligns with yourdomain.com because they share the same organizational domain. The p= tag tells receivers what to do when neither check aligns:

Policy	What the receiver is asked to do
p=none	Deliver as normal and send you reports.
p=quarantine	Treat the message as suspicious, which usually means the spam folder.
p=reject	Refuse the message during the SMTP conversation.

p=none protects nothing. Anyone can still send mail with your domain in the From line, and receivers will deliver it. The value of p=none is the reports, and the reports are what make the move to p=reject safe.

Step 1: List every service that sends as your domain

Before you open DNS, write down everything that sends email with your domain in the From address. Most small businesses have more of these than they expect:

• Your mailbox provider (Google Workspace, Microsoft 365) for everyday email.
• Your email marketing platform for newsletters and automations.
• Your store. WooCommerce order confirmations, password resets and "new order" admin emails go out through WordPress, which by default uses your web host's mail server unless you've installed an SMTP plugin.
• Helpdesk and chat tools that reply as [email protected].
• Invoicing, accounting and booking tools that email customers "from" you.
• Contact forms and other website notifications.

The reports in the next step will show you the senders you forgot.

Step 2: Publish p=none with reporting turned on

If you don't have a DMARC record yet, add a single TXT record at _dmarc.yourdomain.com:

Name:  _dmarc.yourdomain.com
Type:  TXT
Value: v=DMARC1; p=none; rua=mailto:[email protected]

A few details that trip people up:

• One record only. If two v=DMARC1 records exist at _dmarc, receivers treat it as if you have no DMARC policy at all.
• rua is the important tag. It's where aggregate reports go: daily XML summaries from receivers listing which servers sent mail as your domain and whether SPF and DKIM passed and aligned. ruf requests per-message failure reports, but many large mailbox providers don't send them, so don't plan around them.
• Reports to another domain need permission. If rua points at an address on a different domain, such as a DMARC reporting service, that domain has to publish a record authorizing it, at yourdomain.com._report._dmarc.theirdomain.com with the value v=DMARC1 (RFC 7489, section 7.1). Reporting services usually do this for you. Check before you assume reports are arriving.
• Keep the TTL short (an hour or less) while you're working on this, so a rollback takes effect quickly.

Raw XML is hard to read, so use a DMARC report viewer that turns it into a list of sending sources.

Step 3: Read the reports for a few weeks

Give the reports long enough to cover your whole sending cycle. A week catches daily mail, but monthly invoices, a quarterly newsletter or a once-a-month billing run won't show up until they actually go out. Wait until at least one month-end has passed.

Sort every source in the reports into one of four groups:

1. Yours, passing and aligned. Nothing to do.
2. Yours, failing. This is your to-do list. A typical example is your web host's server sending WooCommerce order emails with no DKIM signature and an envelope sender on the host's domain.
3. Forwarders and mailing lists. University and alumni forwarding addresses, or a Google Group, resend your mail from their own servers. SPF fails after forwarding, but a DKIM signature usually survives if the message isn't modified, which is one more reason to rely on DKIM.
4. Not yours. Servers you've never heard of, sending as your domain. This is the spoofing that p=reject exists to stop.

Step 4: Fix each legitimate sender, DKIM first

For each source in group 2, get it to pass with alignment. DKIM signed with your own domain is the better fix, because it survives forwarding and doesn't depend on whose servers sent the mail.

• Google Workspace: until you turn on DKIM in the Admin console and publish the key it gives you, mail is signed with a Google domain instead of yours, so it doesn't align.
• Microsoft 365: enable DKIM for your custom domain in the Defender portal and publish the two CNAME records it shows.
• Your web host's mail: the most common culprit on WooCommerce stores. The usual fix is an SMTP or transactional email plugin that sends WordPress mail through a provider that signs with your domain.
• Other SaaS tools: look for a "custom domain," "domain authentication" or "sender authentication" page in the tool's settings. If a tool can't sign with your domain, change its From address to one that isn't on your domain, or send that tool's mail from a subdomain that has its own DMARC record.

When you add SPF includes for these tools, watch the limit. SPF allows at most 10 DNS lookups per evaluation (RFC 7208, section 4.6.4), and nested includes count. Go over it and SPF returns a permanent error for all of your mail, even though the record looks fine. PostBeagle's free deliverability checker counts the lookups for you and tells you whether your DMARC policy actually enforces anything.

If you send campaigns with PostBeagle, this part is already handled for that stream. PostBeagle generates a DKIM key for your domain, you publish it as a single TXT record at s1._domainkey.yourdomain.com, and mail is signed with your own domain. The domain setup guide walks through the records.

Step 5: Move to p=quarantine

When the reports show no legitimate sources failing for a couple of weeks, change the policy:

v=DMARC1; p=quarantine; rua=mailto:[email protected]

Keep reading the reports. Anything you missed will now land in spam instead of disappearing completely, which is a much easier mistake to recover from.

What about pct?

Many guides tell you to ramp up with pct=25, then pct=50, and so on, so that only a share of failing mail is affected. Don't count on it. The updated DMARC specification, published in May 2026 as RFC 9989, drops the pct tag. Existing records that include it still parse, but receivers that follow the new spec ignore it. The quarantine stage is your safety net, not a percentage.

Step 6: Move to p=reject

After a few clean weeks at quarantine, make the final change:

v=DMARC1; p=reject; rua=mailto:[email protected]

Leave rua in place permanently. When you add a new tool, such as a helpdesk or a booking system, its mail shows up in the reports as failing before your customers notice.

If something goes wrong, roll back to p=quarantine or p=none, fix the sender, and come back. With a short TTL, the rollback takes effect within the hour.

Subdomains

Subdomains without their own _dmarc record inherit your main domain's policy, or the sp= value if you set one. If you send marketing from mail.yourdomain.com or news.yourdomain.com, check that subdomain in the reports too. Giving a subdomain its own DMARC record lets you move it through these stages separately from your main domain.

Why this matters even if nobody is spoofing you

Most small senders don't move to p=reject because of an attack. They do it because mailbox providers now expect authenticated, aligned mail from anyone sending in volume. Google's email sender guidelines and Yahoo's sender best practices both require bulk senders to publish DMARC and to send mail that aligns with their From domain. p=none meets the minimum, but the work in steps 1 to 4 is what makes your mail pass. Once every legitimate stream aligns, moving to reject costs you nothing, and receivers will refuse mail from anyone else using your domain.

If your mail is reaching spam even with authentication in place, the cause is usually your list or your sending pattern rather than DNS. Why my emails go to spam and how to fix it covers those causes.

The short version

1. List every tool that sends as your domain.
2. Publish p=none with rua reporting.
3. Read the reports through at least one month-end.
4. Fix every legitimate failing source, preferring DKIM with your own domain.
5. Move to p=quarantine and watch.
6. Move to p=reject, and keep reading reports.

To see where your domain stands right now, run it through the PostBeagle deliverability checker. It's free and doesn't need an account. If you want a sending platform that signs with your own domain from day one, see how PostBeagle sets up your domain.