Moving DMARC from p=none to p=quarantine without losing legitimate mail

A DMARC record with p=none asks mailbox providers to report on mail that fails authentication, but to deliver it as usual. It is the right place to start, and the wrong place to stay: anyone can still send mail with your domain in the From line, and receivers have no instruction from you to treat it as suspicious.

Moving to p=quarantine tells receivers that failing mail should be treated as suspicious, which in practice usually means the spam folder. The risk is not the change itself. The risk is a legitimate service (invoicing, help desk, CRM, newsletter) that still fails DMARC on the day you switch, so your own messages land in spam.

The short answer: read your aggregate reports until every legitimate sender passes with aligned DKIM, switch to p=quarantine with test mode first, compare reports, then remove test mode. The details follow. If you need a refresher on the 3 records, see SPF, DKIM and DMARC explained.

What p=none really does

DMARC is now defined in RFC 9989, published in May 2026, which replaced RFC 7489. It calls p=none Monitoring Mode and explains why it exists: in all but the simplest setups, a domain owner can overlook a server or a third party sending agreement, and the reports reveal it.

The value quarantine means the domain owner considers failing mail to be suspicious. The final decision stays with the receiver, but for most mailbox providers that means the spam folder. Google describes it plainly in its recommended DMARC rollout: messages that do not pass DMARC go to the recipient's spam folder.

Step 1: get every legitimate sender to pass

RFC 9989 is direct about the order. Legitimate mail streams that fail because their identifiers are unaligned or missing MUST be fixed before you publish an enforcing policy.

Work through your aggregate reports (our guide on how to read a DMARC aggregate report walks through the XML) and list every source:

• Your main mail provider: should pass with aligned DKIM and SPF.
• Each third party tool that sends as your domain: enable DKIM signing with your own domain in its settings. A tool that only passes SPF on its own envelope domain does not align and will fail DMARC.
• Forwarders and mailing lists: these often break SPF. DKIM signatures generally remain valid when mail is relayed, which is another reason to rely on DKIM, not SPF alone.
• Unknown sources that fail: these are what the new policy is meant to stop.

How long to watch is your call. Google suggests at least 1 week at p=none, since that is usually enough for reports to cover all your mail streams. RFC 9989 notes that, depending on how often you send, it may take many months. Think of mail you send once a quarter or once a year: payroll notices, annual invoices, renewal reminders. If those have not appeared in your reports yet, you have not seen them pass.

Step 2: switch with test mode first

Under RFC 7489 the usual way to ease in was the pct tag (apply the policy to a percentage of failing mail). RFC 9989 removed pct because receivers applied values other than 0 and 100 inconsistently. In its place there is a test mode tag, t:

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@example.com"

With t=y you ask receivers to apply 1 level below the stated policy, so p=quarantine; t=y is handled like none, while intermediaries such as mailing lists can already adjust how they handle your mail. The tag does not change reporting. Compare your reports before and after: they show how much of your mail passes through relays that would fail once the policy is enforced.

Some providers still document the older percentage approach; Google's rollout guide, for example, shows pct=5 as a starting value. Receivers that do not yet support t simply ignore it, so treat test mode as a soft start, not a safety net.

Step 3: enforce and keep watching

When test mode reports look clean, remove the tag:

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

In the first weeks after the change:

• Read reports daily and look for disposition values of quarantine on sources you recognize.
• Ask the teams that send to customers (finance, sales, support) to tell you if replies drop or customers say mail went to spam.
• Treat every new tool that sends as your domain as a change request: DKIM with your domain before it goes live.
• Keep DNS access tidy. A DMARC record quietly set back to p=none by a helpful contractor undoes the work.

Subdomains and domains that send nothing

Without an sp tag, the p policy also applies to subdomains. If a subdomain sends marketing mail from a separate platform, check it in reports before the switch, or give it its own _dmarc record. The np tag sets a policy for subdomains that do not exist at all, a common choice for names nobody should ever send from.

Domains you own but never use for mail (old brand names, defensive registrations) are the easy case: with no legitimate senders, they can go straight to an enforcing policy. These are exactly the domains that are attractive for fake invoice scams, because nobody watches them.

Before you go further to p=reject

p=reject is the next step, but RFC 9989 is cautious about it for domains whose users post to mailing lists. It recommends running p=none for at least a month, then p=quarantine for an equally long period, and comparing results first. Large mailbox providers already expect DMARC from bulk senders, as covered in Gmail and Yahoo sender requirements, so a stable p=quarantine is a solid position on its own.

A short checklist

• Aggregate reports collected for long enough to include rare mail streams.
• Every legitimate sender passes DMARC with aligned DKIM.
• p=quarantine; t=y published and reports compared before and after.
• Test mode removed, reports read daily for the first weeks.
• Subdomains and unused domains covered with sp, np or their own records.

Where Guarding fits

Once your policy is enforced, the main risk is that it quietly changes back. We watch your SPF, DKIM and DMARC records and the rest of what we guard from the outside every day, without entering your systems. If a record is weakened or a DKIM selector disappears, a person reviews it and you get the exact change to make, as described in what happens when we find something. The example dashboard shows how it looks.