DMARC enforcement readiness

From p=none to p=reject, in evidence-gated steps

You published a DMARC record, tried to move it to enforcement, and something broke. So you rolled back to p=none and stayed there.

That is the position this page is written for. DMARCit's enforcement-readiness workflow moves your policy (p=none to p=quarantine to p=reject) on alignment-rate evidence at each step. Your domain advances when the data says legitimate senders won't get caught, and pauses when it can't. The policy doesn't move unless the evidence does.

If you arrived here because a checker said your domain is in the 91% that has a DMARC record but no enforcement, you're in the right place. The next section explains why “just set p=reject” is the advice that breaks businesses, and the rest of this page explains what to do instead.

The problem: DIY enforcement breaks businesses

Three failure modes show up in every “we tried DMARC ourselves” post-mortem. If you tried enforcement, broke something, and rolled back, one of these is probably why.

(a) Flipped p=reject before legitimate senders aligned. The classic. A team reads “set p=reject to stop spoofing,” reads it as a configuration step, and pushes the change on a Friday. Monday, sales is screaming because Salesforce-routed quote emails are bouncing, the CFO's payroll provider is in quarantine, and a marketing automation domain you forgot about is throwing 5xx replies all over the support inbox. The fix is to roll back to p=none, which restores delivery but also resets the credibility of any future enforcement attempt with whoever just got blocked.

(b) Flipped to p=quarantine without monitoring rua=. Subtler and worse. A legitimate sender (often something seasonal like a billing system or a one-off third-party survey vendor) silently fails alignment. There's no bounce; mail just disappears into recipients' Junk folders. The team doesn't see the failure for weeks because nobody is reading the aggregate XML. By the time a customer calls in, you've trained one sender's recipients to ignore mail from your domain.

(c) No staged ramp, no rollback path. The variant nobody talks about. The team did the right thing: moved from p=none to p=quarantine cleanly, watched the dashboard for a week, no fires, advanced to p=reject. Two weeks later a known-good sender's IP rotation breaks SPF alignment. The team can't unwind cleanly because there's no audit trail of the ramp, no checkpoint to revert to, and no record of which sender's evidence justified each advance.

The 91% who have a record but no enforcement isn't 91% of the population that hasn't tried. It's heavily weighted with teams that tried, broke something, rolled back to p=none, and stayed there. They don't need another button to flip policy. They need a workflow that proves the next step is safe before they take it.

The approach: an evidence-gated policy ladder

The gate is your alignment-rate evidence: the policy advances only when the data shows legitimate senders won't get caught, and it pauses the moment a new sender shows up unclassified. (This replaces the old pct tag, the sampling ramp that RFC 9989 removed in Appendix A.6 for being ambiguous and for letting teams park at a 10% sample forever.) The replacement isn't a smaller sample. It's moving the policy itself only when the evidence supports it.

The evidence is the lever. The product is what you build around it.

DMARCit's staged ladder runs four stages with explicit evidence gates between each. The stages are the same policy values the spec has always defined (p=none, p=quarantine, p=reject); the difference is what we require before each rung opens.

Stage 1: Monitoring (p=none). You're collecting rua= aggregate reports and you've started classifying the senders showing up in them. Goal: identify every legitimate sender, get them aligned (SPF, DKIM, or both), and tag the long tail of unauthorized or one-off senders. Stage 1 ends when (a) every legitimate sender has a documented alignment posture, (b) rua= reports are flowing reliably for at least 14 days, and (c) the unclassified-source count is at zero. Most domains spend 2-6 weeks here.

Stage 2 entry: p=quarantine. The first stage where mail actually moves. Quarantine routes failing mail to spam instead of dropping it, so an unexpected breakage is recoverable while the alignment-rate evidence stays meaningful. The advance gate from Stage 1 is the evidence: publish p=quarantine once your alignment rate for legitimate senders is at or above 99% over the last 14 days, with no policy-override reasons (forwarded, mailing_list, local_policy per RFC 9989) sitting in the unclassified bucket. If a new sender shows up in this window, the ladder pauses until it's classified.

Stage 2 hold: p=quarantine under watch. The hold is data-gated, not time-gated. A domain with clean alignment for a week clears the gate to reject review that week; a domain with a flaky third-party sender stays at quarantine until the sender is fixed or marked. Every policy move is gated on alignment-rate evidence, with senders annotated and approved before they earn enforcement weight. RFC 9989 removed the pct sampling ramp, so there's no 25%-then-50%-then-75% dial to climb. The low-risk way to dip a toe now is the t=y testing flag: publish your target policy with t=y and receivers report on it without acting, so a misaligned sender surfaces in rua= before any mail moves. Drop t=y (the default is t=n) once the evidence is clean.

Stage 3: p=quarantine, holding. Full quarantine applied to all failing mail, sustained long enough to trust it. A common stable resting point. Many enterprises stay here permanently rather than advance to reject, on the reasoning that quarantine gives spam-folder visibility while reject silently drops mail.

Stage 4: p=reject. The final step. Recommended only after a stable Stage 3 with no override reasons surfacing in rua= data, no new unclassified senders, and an explicit operator sign-off. One caveat RFC 9989 makes explicit (Section 7.4): receivers MUST NOT reject on p=reject alone. Your policy is one input alongside their own analysis, so treat p=reject as your stated intent, not a guarantee every receiver drops the mail. Every advance generates a pre-computed rollback TXT value with rua=/ruf= preserved, so reverting one rung doesn't lose your reporting addresses.

None of the rungs are timer-gated. The pace is set by your alignment data, not a calendar. A clean domain with three well-behaved senders can climb the ladder in two weeks. A messy domain with twenty annual third-party vendors might take a quarter to classify before Stage 1 even closes. Both are correct outcomes for their inputs.

Two RFC 9989 tags worth setting before you climb. np= sets the policy for non-existent subdomains (Section 4.7), separate from sp=, which only covers subdomains that actually exist. Start it at np=quarantine and watch your reports for typo hostnames before you tighten to np=reject, or you'll silently kill a real service nobody documented. If you run a public suffix domain, psd= (Section 3.2.15) declares it. Both tags are read during the DNS Tree Walk (Section 4.10), which RFC 9989 uses to find your policy in place of the old Public Suffix List lookup.

What you'll see in the product

DMARCit's enforcement-readiness surface is anchored on four product elements. Some ship in v1; some are still scoped and labeled here honestly.

The DNS-change safety flow. The product never writes DNS for you. Every advance generates a new TXT value (with all your existing tags preserved: rua=, ruf=, adkim=, aspf=, sp=, np=, psd=, anything else), shows you the diff, and walks you through applying it at your registrar. After you confirm the change, the product polls DNS to verify the new value propagated, then locks the new stage in. If the propagation poll fails, the product warns you. If you applied the wrong value, it tells you.

Source-marking UX (customer-driven tagging). Every sending IP that shows up in your rua= reports gets surfaced in a worklist. You mark each one, legitimate, unauthorized, forwarded (mailing-list / list-serv pattern), or needs-review, and the readiness evaluator uses your tags to decide whether the next stage gate is open. The tagging is yours; the product doesn't pretend to know which sender is your CRM.

Alignment-rate dashboard. Not just a single pass-rate line. A trend over the last 14, 30, and 90 days, broken out by sender, with policy-override reasons (forwarded, mailing_list, local_policy) called out as separate signals so a forwarder doesn't look like a failure. The unclassified-source count is shown alongside the pass rate: a 99% alignment rate with three unclassified sources is not a Stage 2 advance signal; it's a Stage 1 worklist.

Readiness evaluator. Returns one of: insufficient_data, blocked, needs_review, eligible_for_staged_quarantine, or eligible_for_reject_review. The output is a recommendation with the data behind it, not a single “safe to advance” light.

Each element above is labeled for what it is: shipped in v1, or still scoped. Where a surface isn't built yet, it says so on the element itself rather than reading as if it already exists.

Honest readiness checklist

Before you start a staged enforcement workflow (with us, or with anyone) answer these. If you answer no to two or more, you're not Stage-1-ready yet. Fix the foundation first.

1. Do you have rua= aggregate reports flowing to a mailbox or a tool, with at least 14 days of history? Without aggregate reports there's no evidence. Without 14 days, there's not enough.
2. Have you identified every legitimate sender you use? Not most. Every. Including the seasonal ones, the marketing-automation tools your CMO signed up for, the seasonal billing partner, the one-off vendor someone's using “just for this campaign.”
3. Do you know which of your legitimate senders pass SPF alignment, which pass DKIM alignment, and which pass both? Some pass one, some pass the other, some need both. Mixed alignment is the most common Stage 1 hangup. (See /learn/spf-permerror if your SPF is throwing PermError, that has to be fixed before alignment is meaningful.)
4. Is your DMARC record syntactically clean and currently p=none? A broken record with p=quarantine already in place is a different problem than a clean p=none record. The fix order is different.
5. Do you have a documented rollback plan for every DNS change you make to the DMARC record? If “we'll figure it out if it breaks” is the plan, the plan is wrong. Rollback values should be pre-generated, with rua=/ruf= preserved.
6. Is there an owner (a person, with a name, on a calendar) who watches the alignment-rate dashboard at least weekly during the ramp? DMARC enforcement isn't fire-and-forget. The ladder pauses for a reason.
7. Have you set expectations with your team that mail might get quarantined during the ramp, and that the response is “investigate, don't roll back”? Most rollbacks happen because finance complained one email landed in spam. Investigate before reverting, otherwise you'll never advance.

DMARCit itself publishes p=reject on dmarcit.io. We run the same ladder we're asking you to run. If the answers above aren't all yes, the honest move is to fix the foundation before advancing, not to push the next button. We'd rather slow the ramp than ship you the breakage.

Pricing snapshot

The staged-quarantine workflow is a first-class feature on Pro and above.

Pro at $49/mo is the tier built around this page. The staged-quarantine workflow (the evidence gates, the DNS-change safety flow, the readiness evaluator) is the headline feature, not an upsell.

For per-tier domain limits, MTA-STS hosting status, and BIMI/VMC workflow status, see /pricing.

Related reading

• DMARCit vs EasyDMARC (head-to-head on standalone DMARC, MSP fit)
• SPF PermError: causes and fix (common Stage 1 blocker)