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 — "2.3 messages a day, needs no more than 10" 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.


### What decides: the cost of publishing, counted in messages

The question you are actually asking is **what stops arriving when I flip this**, and that is the question the card answers. It is counted in messages a day, not as a percentage — ten a day means the same thing at 3,000 messages a month and at 300,000, which a percentage does not.

| Population | Budget |
|---|---|
| Senders you have **reviewed** | **10 failing messages a day**, averaged over 30 days. Somebody has looked at them, so the mail that stops is a decision rather than a surprise. |
| Senders still **unreviewed** | **None.** Any unreviewed sender with 100 or more failing messages in 30 days blocks on its own. |


The card states your pass rate against a target — 98% at quarantine, 99.5% at reject — because it explains the impact figure. **It is not a criterion.** A domain at 95.5% whose entire shortfall is 68 messages across three senders you have already reviewed is ready; a percentage would have said otherwise, and been wrong. Read the impact figure, not the rate.


An unreviewed source no longer blocks you merely by *existing* — it blocks by **contributing impact**. A large, healthy sender nobody has got round to reviewing, whose mail enforcement would not touch, no longer holds up a rung.

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

| Criterion | Threshold | Blocks? | Why it exists |
|---|---|---|---|
| Coverage | ≥ 14 days of reports | Yes | A week cannot show you a monthly billing run or a quarterly statement. |
| Volume | ≥ 1,000 messages | Yes | An impact figure computed over 40 messages is an anecdote, not a measurement. |
| Providers | ≥ 3 distinct reporters | Yes | See below — this is the one people skip. |
| Acceptable impact | ≤ 10 messages/day reviewed; no unreviewed sender ≥ 100 failing | Yes | What publishing actually costs you. |
| Unaligned SendOps sending | none | Yes | It is *your* mail that stops. |
| Pass rate | ≥ 98% | **No** | Reported, to explain the impact figure. |

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

All of the above, plus:

| Criterion | Threshold | Blocks? | Why it exists |
|---|---|---|---|
| Time at current policy | ≥ 30 days | Yes | Enough time for a monthly cycle to complete at quarantine first. |
| New unknown sources | none first seen in the last 14 days | Yes | A source that appeared last week has not been understood yet. |
| Pass rate | ≥ 99.5% | **No** | Reported. The extra caution at reject is about *time*, and the two criteria above ask for it directly. |

There is deliberately **no second impact budget** at reject. A second number would be the same caution counted twice.

### "Not measured yet" blocks, and there is a button for it

If the nightly classification pass has not measured what publishing would cost, the criterion reads **not measured yet** and holds the rung. Granting a rung on an unanswered question is the one direction this card will not err in.

The same applies to an **unmeasured tail** — sending addresses the last pass did not get to. If that tail could on its own exceed the ten-a-day budget, it blocks, and the card says **"Measure them before publishing"** beside a **Re-measure now** button that reruns the pass for that one domain instead of waiting for 03:10.

One case where it does *not* block: a domain with more sending addresses than one nightly read can cover. There the tail is cut before classification begins and would be cut again identically tomorrow, so no button clears it. The bound is still stated, the rung goes through, and the card says re-measuring will not help.

### 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.

## Accepting a cost before you publish

Some mail of yours breaks for a reason you cannot fix. The commonest is **relay-broken forwarding**: a forwarder re-sends your own mail and breaks the signature on the way. Recipients choose to forward, so there is nothing to publish and nothing to configure.

Because you cannot reach it, that mail is left out of the verdict — and because nothing is judging it, nothing else would ever make you look at it. So the card asks you to **acknowledge** it before it hands you the record:

- Every criterion is met, but the card shows **ready, pending acknowledgement** rather than ready, and the record to publish is withheld until you accept.
- The figure you accept is **frozen** at that moment — the volume, the senders named, and the wording you were shown.
- **An acknowledgement covers one rung.** Accepting "this forwarded mail goes to a spam folder" at quarantine is not accepting "it is refused" at reject, so you are asked again at the next rung.
- If the cost later **grows by half again, and by at least 100 messages**, you are asked again, with the growth stated. A drift from 12,000 to 12,400 does not re-ask — that would just train you to click through.

This is not a waiver, and it does not make anything ready that was not. It is the one cost the ladder stopped blocking on, put somewhere you will read it.

## Lower your TTL first

Before you publish, set the TTL on your `_dmarc` record to **300 seconds**. The card states this as a step, because it is easy to skip and impossible to apply retrospectively.

A `_dmarc` record commonly inherits a zone default of an hour or a day. This is the one change where the undo needs to be fast: at 300 seconds a mistake is five minutes of quarantined mail, rather than however long your zone's default happens to be.

## The record SendOps offers you carries `sp=`

The record on the card is `v=DMARC1; p=…; sp=…; rua=mailto:…`, with `sp` matching `p`.

`sp` is the policy for **subdomains**. With no `sp`, subdomains follow `p` — the same outcome today, and a different one the moment anybody adds an `sp` for one subdomain. Stating it is what stops that being silent. It is also the tag most likely to be already present in your record and already *different*: a domain carrying an explicit `sp=none` under `p=none` that tightens `p` alone leaves every subdomain unprotected while the card announces enforcement.

Because a change like that is invisible in a side-by-side read of two long TXT records, SendOps shows you a **field-level diff** — each tag that changes, and one sentence on what that tag does — rather than two strings to compare yourself.

## 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 had a `pct` tag that nominally applied your policy to a percentage of failing mail. SendOps has never offered it, and as of May 2026 **the tag is no longer part of DMARC**: [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989) removed it, and Appendix A.6 records the working group's reasoning.

If you find `pct=` in an existing record, it is not a live setting. SendOps echoes it back so you can find it in your own record, but a value there means the tag is still published — not that a percentage is in force. Receivers that still honour it disagree about what it means.

Graduation in SendOps is **publish → watch → hold or roll back**, which the watch window below is for.

## 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.

### The 14-day watch window

Publishing is not the end of the move. For **14 days** after a policy change SendOps watches what receivers actually did with your mail, and then tells you which of three things happened:

| Verdict | What it means |
|---|---|
| **Hold** | The change held. It has not yet earned the next rung, and nothing is wrong. |
| **Advance** | It held, and you now meet the criteria for the rung above. |
| **Roll back** | The change is costing you mail. Your own sending has broken since you tightened, and you are losing messages now. |

Without this you would hear nothing for a fortnight after doing exactly what you were asked. The verdict that matters is the third: a pass rate moving two weeks after a policy change is easy to read as an unrelated fault, and this is what connects it back to the change you made.

The card carries a **rollback record** alongside the record to publish — the previous value, ready to paste back. It is not a second version of the record to publish, and the two are labelled apart deliberately: the rollback is the thing you want under pressure, from a position where your mail is already failing.

## 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.

**The record you need is on the timeline.** Your current record *is* the damage, so knowing it weakened is not enough — you need the previous value to paste back. [Change history](/domain-auth/change-history) keeps the `_dmarc` record verbatim as it stood before each change, with the date.

## Related

- [Reading Your Source Table](/domain-auth/reading-your-source-table) — resolving the sources blocking your readiness
- [Change History](/domain-auth/change-history) — what changed, when, and whether it worked
- [Setting Up DMARC Reporting](/domain-auth/setting-up-dmarc-reporting)
- [DNS Configuration](/domains/dns-configuration)