Publishing `p=none` gets you reports. Tightening to `p=quarantine` or `p=reject` is what actually stops someone spoofing your domain. This page covers when you have earned that move, what changes for your recipients, and what goes wrong if you do it too early.

## What each policy asks receivers to do

| Policy | What a receiver does with mail that fails DMARC |
|---|---|
| `p=none` | Nothing. Delivers as normal, sends you a report. |
| `p=quarantine` | Treats it as suspicious — typically the spam folder. |
| `p=reject` | Refuses it at the SMTP conversation. |

The asymmetry between the last two is the thing to understand before you act:


Quarantined mail lands somewhere a determined recipient can still find it — they look in spam and there it is. **Rejected mail is destroyed in transit.** It never reaches a folder, the recipient never knows it existed, and there is nothing to retrieve. If you tighten to `p=reject` while a legitimate sender is still failing alignment, that sender's mail is simply gone.


This is why the ladder has a middle rung, and why it is worth standing on it for a while.

## The readiness criteria

SendOps shows a readiness card for each domain that states every criterion alongside your measured value — "pass rate 97.2%, needs 98%" rather than a bare red cross. When a domain is not ready, the criteria it fails **are** your to-do list.


**Infrastructure → Domain Auth**, on the domain's page — alongside setup rather than with the reports. That placement is deliberate: the action this card leads to is publishing a DNS record, and the record to copy is right there.

**Reports → Authentication** shows only a one-line verdict for each domain, linking here. If your blocker is unreviewed sources, the card links the other way, straight to the sources list.


### Moving from `p=none` to `p=quarantine`

| Criterion | Threshold | Why it exists |
|---|---|---|
| Coverage | ≥ 14 days of reports | A week cannot show you a monthly billing run or a quarterly statement. |
| Volume | ≥ 1,000 messages | A pass rate computed over 40 messages is an anecdote, not a measurement. |
| Providers | ≥ 3 distinct reporters | See below — this is the one people skip. |
| Pass rate | ≥ 98% | Every message below the line is mail a stricter policy drops. |
| Unreviewed sources | none above 100 messages / 30 days | An unreviewed source is an unanswered question. |
| Unaligned SendOps sending | none | It is *your* mail that stops. |

### Moving from `p=quarantine` to `p=reject`

All of the above, plus:

| Criterion | Threshold | Why it exists |
|---|---|---|
| Pass rate | ≥ 99.5% | At reject, the remaining half-percent is mail destroyed with no recovery. |
| Time at current policy | ≥ 30 days | Enough time for a monthly cycle to complete at quarantine first. |
| New unknown sources | none first seen in the last 14 days | A source that appeared last week has not been understood yet. |

### Why three providers matters more than it looks

This is the criterion people are most tempted to wave through, and it is the one that catches the sender who breaks on the day you publish `p=reject`.

**One provider only shows you the mail you sent to that provider.** If 90% of your reports come from Google, your pass rate describes your mail to Gmail addresses. It says nothing about the internal system that mails your Microsoft-hosted customers, or the European partner on a mail service you have never heard of. Those senders can be failing alignment for months without appearing anywhere in your data — until you tighten the policy and they stop working.

Three distinct reporters is a low bar deliberately. It is not a guarantee of full coverage; it is the minimum at which the picture stops being about one mailbox provider's view of you.

### Why an unreviewed source blocks the move

An unreviewed source is a question you have not answered. Tightening your policy answers it by breaking it — if the source was legitimate, you find out when someone complains their mail stopped arriving.

Only sources above **100 messages in 30 days** block readiness. A handful of stray messages will not hold you back; a sender with real volume will.

## We never change your DNS


SendOps does not write DNS records, and it never advances your DMARC policy for you. Not automatically, not with a confirmation dialog, not at all. When the readiness card says you are ready, the change is yours to make in your own DNS provider.


## Why there is no `pct=` ramp

DMARC has a `pct` tag that nominally applies your policy to a percentage of failing mail. SendOps does not offer it, deliberately.

Receivers implement it inconsistently, so "25%" does not mean the same thing at two different providers, and reasoning about the results is harder than reasoning about the unramped policy. More to the point: a domain that meets the criteria above does not need a partial rollout, and a domain that does not meet them should fix what is failing rather than expose a quarter of it.

## Rolling back

If something breaks, revert the record. Set `p` back to its previous value and republish.

Propagation is **minutes to hours**, governed by the TTL on your DMARC record and the caches of every receiver in between. That is fast, but it is not instant, and at `p=reject` the mail lost in the meantime is not recoverable. This is the whole reason the ladder exists — quarantine gives you a rung where a mistake is survivable.

## What to expect after you advance

The readiness card retargets to the next rung. If you have just moved to `p=quarantine`, the card immediately begins measuring you against the reject criteria, including the 30-day clock at your new policy — which starts now, not when you first published DMARC.

Days at the current policy are counted from **the reports, not your DNS record**. Every aggregate report states the policy the receiver actually applied, so your reports are a dated log of your own policy written by third parties. That is a more reliable history than a single current sample of your DNS.

## If your domain shows as regressed

A regressed domain means SendOps has observed receivers applying a **stronger** policy recently than the one your record publishes now. Your DMARC record has become weaker than it was.

This is almost always an unintended DNS edit — a record restored from an old backup, a change made by another team, a migration between DNS providers that dropped a tag.

Fix that before anything else. SendOps reports the regression plainly rather than hiding the card, because the fact that your protection silently weakened is exactly the thing worth telling you.

## Related

- [Reading Your Source Table](/domain-auth/reading-your-source-table) — resolving the sources blocking your readiness
- [Setting Up DMARC Reporting](/domain-auth/setting-up-dmarc-reporting)
- [DNS Configuration](/domains/dns-configuration)