DMARC enforcement readiness

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

Most DMARC tools ship a button that flips your policy. We ship a workflow that earns it.

Mimecast DMARC Analyzer 2.0, EasyDMARC, dmarcian, PowerDMARC — every major analyzer now offers an “enforcement journey” UI. Look closely and most of them reduce to the same primitive: a UI for changing the p= tag in your DMARC record. Click a button, push a new policy. The journey is the click.

DMARCit's enforcement-readiness workflow is structurally different. It's a pct= ladder gated on alignment-rate evidence at each step — your domain advances when the data says it can, and pauses when it can't. The button 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 paragraph explains why “just set p=reject” is the advice that breaks businesses, and the rest of this page explains what to do instead.

Start your readiness check Book a 20-min walkthrough

[VERIFY: /tools/dmarc-checker ships in Phase 2Q follow-up — fallback to /pricing until live. /book-demo URL existence is meta-issue #9 from Phase 2T — fallback to /contact if absent.]

The problem: DIY enforcement breaks businesses

Three failure modes show up in every “we tried DMARC ourselves” post-mortem we've read or run. Customers who churned out of dmarcian, EasyDMARC, and Mimecast for one of these reasons are the cohort this page is written for.

(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 Phase 2D customer-driven source-marking UX framing applies here. 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: a `pct=` ladder gated on alignment-rate evidence

DMARC's spec ships a quiet superpower most teams don't use: the pct= tag. It tells receiving servers what percentage of failing mail to apply your policy to. p=quarantine; pct=10 means “quarantine 10% of mail that fails alignment; deliver the rest.” The other 90% gives you visibility without the breakage.

That's the lever. The product is what you build around it.

DMARCit's staged ladder runs four stages with explicit evidence gates between each. The ladder is the same one Microsoft and the DMARC RFC explicitly recommend (pct=10/25/50/75/100); the difference is what we require before each rung is unlocked.

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; pct=10. The first stage where mail actually moves. The 10% sample is small enough that an unexpected breakage is recoverable; large enough that the alignment-rate evidence becomes meaningful. The advance gate from Stage 1 is the evidence: ≥99% alignment over the last 14 days, no policy-override reasons (forwarded, mailing_list, local_policy, sampled_out per RFC 7489) in the unclassified bucket. If a new sender shows up in this window, the ladder pauses until it's classified.

Stage 2 ramp — pct=25 → 50 → 75 → 100. Each rung increment requires the same evidence at the new sample size. The ramp isn't time-gated; it's data-gated. A domain with clean alignment at pct=10 for a week can advance the same week. A domain with a flaky third-party sender stays at pct=25 until the sender is fixed or marked. This is the differentiator. Mimecast 2.0 ships an enforcement journey too; theirs is policy-toggle (a UI for flipping p=). Ours is the pct= ladder gated on alignment-rate evidence at each step — senders annotated and approved before they earn enforcement weight.

Stage 3 — p=quarantine; pct=100. The full quarantine policy applied to all failing mail. 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. 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.

What you'll see in the product

DMARCit's enforcement-readiness surface is anchored on four product elements. Some ship in v1; some are scoped in spike #11 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=, 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. [VERIFY: ships in spike #11 — current scope confirmed; verification poll loop scoped, audit log scoped.]

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. [VERIFY: ships in spike #11 — v1 is customer-driven tagging per Phase 2D; full automated classification deferred to v2.]

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, sampled_out) 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. Replaces the red/yellow/green binary every other tool ships. The output is a recommendation with the data behind it — never a single “safe to advance” claim. [VERIFY: ships in spike #11 — readiness rule defaults flagged for Adam decision; UI surface confirmed.]

We're labeling unshipped product surface honestly because the comparison-page family ( /compare/easydmarc, /compare/mimecast, /compare/dmarcian, /compare/powerdmarc) explicitly does. Promising more than the product ships is how trust gets burned in the first 90 days of a new customer relationship — exactly the trust we're asking you to extend.

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, and any tool selling you the next button is selling you breakage. Fix the foundation first.

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.
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.”
Do you know which of your legitimate senders pass SPF alignment, which pass DKIM alignment, and which pass both? Some passes 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.)
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.
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.
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.
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. We treat this checklist as a credibility wedge against tools that just sell the “set p=reject and pray” approach. If a vendor's onboarding doesn't ask you these questions, it's because they don't want to slow your purchase. We'd rather slow your purchase than ship you the breakage.

Pricing snapshot

The staged-quarantine workflow is a first-class feature on Pro and above — not a setting buried inside a generic analyzer.

Plan	Price	Built for
Pro	$39/mo	Multi-domain, staged-quarantine workflow, hosted SPF, full source-marking UX, transparent self-serve
Enterprise	Contact Sales	Multi-tenant, MSP / partner pricing

Pro at $39/mo is the tier built around this page. The staged-quarantine workflow — the pct= ladder, the alignment-rate 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 [VERIFY: /pricing not live in production at time of writing — falls through to /signup]. [VERIFY: per-domain inclusions on Pro at $39/mo — Adam to ratify entitlement model before publish. MTA-STS hosting believed Q3 2026 roadmap; BIMI workflow present in some tier flows; full BIMI/VMC on roadmap.]

Two paths from here

If you've read this far, you've earned a real choice between them. Both are honest.

Run the readiness check first. Five minutes, public, no email gate on the headline. You'll get a stage-aware grade for your domain and a list of the next concrete actions. If you're already at Stage 1 with clean evidence, the check will tell you the ladder is ready. If you're not, the check will tell you that, too — without a sales pitch.

Or talk to the founder. Twenty minutes. We'll walk through your DMARC posture, the senders visible in public DNS, realistic ladder timing for your setup, and whether DMARCit is actually the right tool — or whether you'd be better served by a free monitor for another 30 days first. We've talked teams out of the purchase before; we'll do it again if it's the right call.

Start your readiness check Book a 20-min walkthrough

[VERIFY: /book-demo URL existence — fallback to /contact if not yet shipped.]

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