DMARC policy: how to move from p=none to p=reject without losing real email

Many organisations published a DMARC record in early 2024, when Gmail and Yahoo started requiring one from bulk senders, and have not touched it since. The record says p=none. That was enough to keep mail flowing, but it tells receivers to deliver mail that fails authentication as normal. Anyone can still send email that claims to come from your domain, and it still lands in your customers' inboxes.

This post explains what each DMARC policy value does, and gives a staged plan to move from p=none to p=reject without blocking your own invoices, password resets and newsletters.

What the DMARC policy values mean

A DMARC record is a TXT record at _dmarc.yourdomain.com. The p tag tells receiving mail servers what to do with a message that claims to be from your domain but fails DMARC:

A message passes DMARC when SPF or DKIM passes and the domain that passed is aligned with the domain in the visible From address. Alignment is the part most often missed. A marketing platform can pass SPF for its own bounce domain and still fail DMARC for yours.

The other tags you will meet:

• rua: where receivers send daily aggregate reports. Without it you are working blind.
• sp: the policy for subdomains, which defaults to p.
• np: new in the current standard, the policy for subdomains that don't exist, such as invoices-billing.yourdomain.com invented by a phisher.
• adkim and aspf: relaxed (default) or strict alignment. Relaxed is right for most domains.
• t: new in the current standard. t=y asks receivers to apply one level less than your policy, as a test.

DMARC is now RFC 9989

The IETF published the updated DMARC standard in May 2026 as RFC 9989, with aggregate and failure reporting in RFC 9990 and RFC 9991¹. Records still start with v=DMARC1. The main changes for anyone running a domain:

• pct is gone. It was rarely applied accurately at anything other than 0 or 100. The t flag replaces it: t=y roughly means the old pct=0.
• np is part of the standard, so you can reject mail from made-up subdomains without changing the policy for real ones.
• Receivers find the organisational domain by walking the DNS tree rather than using the public suffix list.

Receivers ignore tags they don't recognise, and many will run RFC 7489 behaviour for some time. Don't build your rollout on pct or t. Build it on what the reports show.

Why p=none is not enough

The mailbox providers' rules only require a record, not enforcement:

• Gmail has required bulk senders (5,000 or more messages a day to personal Gmail accounts) to publish DMARC since February 2024, with p=none accepted, and started rejecting more non-compliant traffic from November 2025².
• Yahoo has the same minimum, p=none, with aligned SPF or DKIM³.
• Outlook.com started rejecting mail from high-volume senders without SPF, DKIM and at least p=none DMARC in May 2025, with the error 550 5.7.515⁴.

Meeting those rules gets your mail delivered. It does nothing about someone else's mail. A bank, an insurer or a retailer whose domain is at p=none can be impersonated in a phishing campaign, and receivers will deliver it. Banks, payment providers and retailers are obvious targets, because their customers expect email from them about money.

You can read any domain's records yourself. Here are ours: vigilbase.com is at p=reject, with aggregate reports going to Cloudflare's DMARC Management.

$ dig +short TXT _dmarc.vigilbase.com
"v=DMARC1;p=reject; rua=mailto:712fd1db16dd4fb1b597133ec87f95bb@dmarc-reports.cloudflare.net;"
$ dig +short TXT vigilbase.com | grep spf1
"v=spf1 include:_spf.mx.cloudflare.net include:spf.protection.outlook.com include:146670049.spf07.hubspotemail.net include:_spf.google.com ~all"

Check where your domain stands now with the DMARC Checker. It reads your policy and reporting address and runs the full Email Security scan, which also grades SPF, DKIM, MTA-STS and BIMI.

The rollout, step by step

Plan for two to three months. The time goes on finding and fixing senders, not on DNS changes, and a domain with few senders can move faster.

Step 1: publish p=none with a reporting address

If you have no record, or a record without rua, start here. Build the record with the DMARC Generator, which runs in your browser:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Aggregate reports are XML files, one per receiver per day. Read them with a DMARC reporting tool rather than by hand. If your DNS is on Cloudflare, its DMARC Management feature is available on all plans, still in beta, and shows each source sending as your apex domain with its SPF, DKIM and DMARC results⁵.

You don't need a ruf address. Failure reports can contain personal data, and many large mailbox providers don't send them.

Step 2: list every service that sends as your domain

After a week or two of reports, you will have a list of sending sources. Expect more than you thought. A typical list:

• Your main mailbox provider, such as Microsoft 365 or Google Workspace.
• A marketing or newsletter platform.
• A CRM, a helpdesk or ticketing system, and a live-chat tool.
• Invoicing, accounting and payroll systems.
• Your own applications sending password resets and notifications.
• Forwarders and mailing lists that relay your mail.
• Sources you don't recognise. Some will be forgotten tools; some will be spoofing.

Put each one in a table with an owner, and mark it as legitimate, to be retired, or not yours.

Step 3: align SPF or DKIM for each legitimate sender

For each legitimate service, get at least one of these aligned with your From domain:

• DKIM (preferred): set up a custom DKIM signing domain in the service, usually by publishing one or two CNAME or TXT records it gives you. DKIM survives most forwarding, SPF doesn't. Check it with the DKIM Checker.
• SPF: add the service to your SPF record, or better, give it a subdomain such as mail.example.com with its own SPF record and a custom return-path.

Watch SPF's limits while you do this. A record may cause at most 10 DNS lookups for include, a, mx, ptr, exists and redirect, and receivers return permerror above that⁶. Adding one more include for every new tool is how most domains break SPF. The SPF Checker counts the lookups, and the SPF Generator helps you rebuild the record.

Retire the services nobody owns. Don't add a sender to SPF just because it appears in the reports.

Step 4: move to p=quarantine

When the reports show your legitimate sources passing with alignment for a couple of weeks, move to quarantine:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com

Tell the service desk before you change it. The usual symptoms of a missed sender are "customers say our invoices went to spam" or "the password reset email never arrived". Check the reports daily for the first week. A legitimate source that starts failing goes back on the fix list; it is not a reason to roll back the whole domain.

Step 5: move to p=reject and cover subdomains

After a few quiet weeks at quarantine, move to reject, and decide what to do with subdomains:

- v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com
+ v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc-reports@example.com

• sp=reject applies the policy to real subdomains too. If some subdomain still has an unaligned sender, give that subdomain its own _dmarc record at a lower policy while you fix it.
• np=reject rejects mail from subdomains that don't exist in DNS. Receivers that don't support np yet fall back to sp, then p.
• Parked domains that send no email should go straight to v=DMARC1; p=reject; with an SPF record of v=spf1 -all. There is nothing to wait for.

Keep reading the reports after you reach reject. New tools get bought, and the first sign is usually a new failing source.

Mailing lists and forwarding

Some legitimate mail fails DMARC because of what happens after you send it. Forwarders send your message from their own servers, which breaks SPF. Mailing lists that add a footer or change the subject break DKIM too. Most large lists now rewrite the From address to avoid this. ARC (RFC 8617), which lets intermediaries vouch for the original authentication, is still an experimental standard⁷, and receivers decide for themselves whether to trust it.

In practice, aligned DKIM covers most forwarding. If staff rely on a specific mailing list that still breaks, raise it with the list operator rather than holding your whole domain at p=none.

If your mail is being rejected

Two common bounce messages point to authentication:

• 550 5.7.26 from Gmail: the message was unauthenticated, failed SPF with -all, or failed your DMARC policy⁸. Find the sending service in your reports and fix its alignment.
• 550 5.7.515 from Outlook.com: the sending domain doesn't meet Microsoft's authentication requirements for high-volume senders⁴.

How the checkers score each record, and what to fix first, is in our email checkers documentation. Once you reach enforcement, BIMI can show your logo in supporting inboxes; it requires p=quarantine or p=reject.