Done-for-you DMARC enforcement: how the managed path to p=reject works

17 June 2026 · 13 min read

Reaching p=reject is not the hard part. Anyone can change one DNS record from p=none to p=reject in thirty seconds. The hard part is reaching p=reject without silently dropping legitimate mail: the invoice from your billing platform, the password reset from your help desk, the newsletter from your marketing tool, the calendar invite forwarded by a customer. Enforcement is where DMARC stops being a monitoring exercise and starts actively telling the world's inboxes to bin anything that fails authentication. Get it wrong and the failures are your own mail.

A done-for-you service exists to make that final policy change boring. The work is not the switch itself; it is the weeks of evidence-gathering, source identification, and gradual exposure that come before it, plus the watching that comes after. This article explains exactly how the managed path to enforcement works on DMARC Engine: what the platform automates, what stays your decision, and the specific safety check applied at each stage so that the day you hit p=reject is an anticlimax rather than an incident.

What "enforcement" actually means

DMARC has three policies, set by the p= tag in your _dmarc TXT record:

• p=none: monitor only. Receivers report on what passed and failed but take no action. Nothing is blocked. This is the safe starting state and, by itself, provides no protection against spoofing.
• p=quarantine: failing mail is treated as suspicious, usually delivered to spam or held. A partial enforcement state, and a useful intermediate step.
• p=reject: failing mail is refused at the SMTP layer. The receiving server returns a rejection and the message is never delivered.

There is more to a policy than the headline word. The pct= tag controls what fraction of failing mail the policy applies to. The sp= tag sets a separate policy for subdomains. The adkim= and aspf= tags control whether alignment is strict or relaxed. The managed ramp moves all of these together in a deliberate sequence, not just the single p= value. If you want the full picture of how a domain travels from monitoring to reject, the enforcement journey doc walks the whole route; this article is the operational view of how the service drives it.

The reason enforcement matters at all is that p=none offers no defence. A domain on p=none is still spoofable; the policy tells receivers to do nothing. The mailbox providers know this, which is why Google, Yahoo and Microsoft now require an enforced DMARC policy for bulk senders. We cover that mandate in the Gmail, Yahoo and Microsoft requirements explainer. The destination is p=reject. The managed path is how you get there alive.

The principle: ramp slowly, watch constantly, never guess

Every safe enforcement rollout rests on one idea: before you tell receivers to reject failing mail, you must be certain that all of your legitimate mail passes DMARC. "Certain" does not mean "fairly sure"; it means you have seen, in aggregate reports from real receivers over a real reporting window, that every sending source you care about is producing an aligned SPF or DKIM pass.

DMARC passes when at least one of two things happens, and the identifier aligns with your From: domain:

• SPF authenticates the envelope sender and the envelope domain aligns with From:, or
• DKIM verifies a signature and the signing domain d= aligns with From:.

You only need one of the two to pass and align. The mechanics of that "and align" are the single most misunderstood part of DMARC, and the reason mail that looks authenticated still fails; the alignment explainer covers why a passing SPF check with a mismatched domain still produces a DMARC failure. The managed service's entire job before enforcement is to drive every one of your sources into that passing, aligned state, and to prove it with report data rather than assumption.

That is why the ramp is slow and why it is data-driven. You do not move to the next stage on a timer. You move when the reports say it is safe.

Stage 0: deploy monitoring and gather a baseline

Nothing happens to your policy until the platform can see your mail. The first stage is pure observation.

When you add a domain, DMARC Engine publishes a p=none record with a rua= reporting address pointed at the platform's ingestion endpoint. From that moment, every participating receiver (Google, Microsoft, Yahoo, Comcast, La Poste and hundreds of others) sends a daily aggregate report describing the mail they saw claiming to be from your domain: the source IP, the volume, the SPF result, the DKIM result, and crucially the alignment outcome.

What is automated here:

• Publishing or guiding the _dmarc record with the correct rua so reports start flowing. If you delegate DNS to the platform, this is done for you; the DNS delegation doc explains how that works.
• Receiving, parsing and de-duplicating the XML aggregate reports.
• Resolving each sending IP into a recognisable source: "this is SendGrid", "this is your Microsoft 365 tenant", "this is your own mail server", "this is an unknown forwarder in a residential range".
• Building a per-source ledger of pass and fail rates over time.

What you decide:

• Which domains and subdomains to bring under management.
• How long to bake the baseline. A week sees your weekday traffic; a full month catches the monthly invoicing run, the quarterly newsletter, the payroll provider that only fires on the 28th. The service recommends a window based on observed volume, but the call to proceed is yours.

The safety check at this stage is simple and absolute: you do not leave Stage 0 until the platform has identified your legitimate sources and can account for the bulk of your volume. A domain where 30% of mail comes from sources nobody recognises is not ready to enforce, and the platform will say so. Your first reports will almost certainly contain surprises, which is normal and expected; your first DMARC report is usually a list of senders you forgot you had. You can inspect any raw report yourself with the DMARC report analyzer.

Stage 1: fix the authentication gaps

A source that fails DMARC is not necessarily malicious. Far more often it is a legitimate service you simply have not authorised correctly. Stage 1 is about closing those gaps so that every real source produces an aligned pass. This is the longest and most hands-on stage, and it is where the "done-for-you" label earns its keep.

For each unauthenticated legitimate source, there is a standard remedy:

• A sender missing from SPF. Your marketing platform sends from its own IPs, but those IPs are not in your SPF record, so SPF fails. The fix is to authorise them. If adding them pushes you over the ten-DNS-lookup limit that SPF imposes, you hit a permerror and SPF breaks for everyone; the SPF permerror explainer describes this trap. DMARC Engine's hosted SPF flattening keeps you under the limit automatically, covered in how SPF flattening works. Check your current record any time with the SPF checker.
• A sender not signing with DKIM, or signing with the wrong domain. The fix is to publish the provider's DKIM public key at the right selector and enable signing. DKIM is the more durable of the two passes because, unlike SPF, it survives forwarding. The DKIM selectors explainer covers how selectors let multiple providers each sign for you. Verify a selector with the DKIM checker.
• A source that passes authentication but fails alignment. The provider signs with their own domain, so DKIM verifies but does not align with your From:. The fix is to configure the provider to sign as your domain, or to send from a subdomain you control. This is the case behind the common "DMARC fails but SPF and DKIM pass" confusion.

What is automated:

• Maintaining the SPF record under the lookup limit through hosted flattening, and re-flattening when an upstream provider changes their published IPs.
• Hosting DKIM keys and, where the platform manages signing, rotating them on schedule per DKIM key rotation so a leaked key has a short blast radius.
• Continuously re-checking each source against incoming reports so the platform knows the moment a fix takes effect, rather than waiting for you to ask.

What you decide:

• Whether an unrecognised source is legitimate. The platform can tell you that an IP belongs to a Mailchimp range; it cannot tell you whether you actually use Mailchimp. Source classification is the one judgement that must stay human, because only you know your business.
• How to handle sources you cannot fully authenticate, such as a partner who mails on your behalf from infrastructure you do not control. Options range from moving them to a dedicated subdomain to accepting that their mail will fail once you enforce.

The safety check here is the gate to enforcement: the platform tracks a "ready to enforce" signal per domain that only turns green when every classified-legitimate source is producing an aligned pass at a stable rate across recent reports. Until that signal is green, the ramp stays parked. This stage is the heart of the whole exercise, and reaching p=reject without breaking email goes deeper into the source-by-source method.

Stage 2: partial quarantine, the controlled first cut

Once your legitimate sources pass, the policy starts to bite, but gently. The first enforcement move is not reject and not even full quarantine. It is quarantine applied to a fraction of mail using the pct= tag.

A typical first step is p=quarantine; pct=10. This tells receivers: for 10% of mail that fails DMARC, treat it as suspicious; for the other 90%, carry on as before. The effect is deliberately small. If you have missed a legitimate source, only a tenth of its mail is affected, and it lands in spam rather than vanishing. That gives you a recoverable signal instead of a silent outage.

What is automated:

• Publishing the staged policy with the chosen percentage.
• Watching aggregate reports for the appearance of any failing source that is being quarantined, and flagging it against your known-good source list.
• Comparing failure volume before and after the change, so an unexpected jump is caught quickly.

What you decide:

• The starting percentage and the ramp shape. A high-volume transactional domain might start at pct=5; a small domain with well-understood mail might jump to pct=50. The platform proposes; you approve.
• Whether to hold, advance or roll back at each step. Rollback is a one-click reduction of the percentage or a return to p=none, and DNS propagation means it takes effect within the TTL, usually minutes.

The safety check is differential: the platform does not just look at whether failures exist (some always will, from spoofers and broken forwarders), it looks at whether any failing source matches something on your legitimate list. A spoofer failing quarantine is exactly what you want. Your own newsletter failing quarantine is a stop signal, and the ramp halts.

Stage 3: full quarantine, then the climb to 100%

With a small percentage proving safe, the percentage climbs: pct=25, pct=50, pct=100, each step held long enough to gather a fresh reporting window. By the end of this stage you are at p=quarantine; pct=100: every failing message is being quarantined, none is being delivered to the inbox.

This is a genuinely strong position. Full quarantine already defeats most spoofing, because mail that fails authentication no longer reaches the inbox. Many organisations could stop here and be materially safer than they were at p=none. The reason to continue to reject is that quarantine still delivers the failing mail somewhere (the spam folder), and a determined recipient can fish it out; reject refuses it outright, and it is the policy the mailbox providers most want to see.

What is automated:

• Stepping the percentage on a schedule that is gated by report data, not by the calendar alone.
• Holding the ramp automatically if a new legitimate source appears in the failing set between steps.
• Keeping SPF flattening and DKIM signing healthy throughout, since a provider changing their IPs mid-ramp is a classic cause of a sudden new failure.

What you decide:

• The pace. Some teams want a fortnight at each step for maximum caution; others, confident in a small and stable sender list, move every few days.
• Whether quarantine is your final destination. For some domains, particularly parked or non-sending ones, full quarantine or even reject is reached almost immediately because there is no legitimate mail to protect.

The safety check stays the same differential test, now at full coverage: at pct=100 quarantine, you should see all your legitimate mail still passing and only illegitimate mail being quarantined. If that holds across a reporting window, you are ready for the final step.

Stage 4: p=reject, the anticlimax

The final change is p=quarantine; pct=100 to p=reject. If the previous stages were done honestly, this changes almost nothing about which messages are blocked: the same mail that was being quarantined is now being rejected. The behavioural difference is small precisely because the risky discovery work already happened at quarantine, where mistakes were recoverable.

What is automated:

• Publishing the p=reject record.
• Continuing to ingest aggregate reports, because enforcement is not a finish line. New SaaS tools get adopted, marketing changes providers, an acquisition brings a new mail stream. Any of these can introduce an unauthenticated source that will now be rejected outright.
• Monitoring for changes to your DNS records, so that if your SPF, DKIM or DMARC record is altered or removed (by a well-meaning colleague or an attacker), you find out immediately. Set this up via monitoring and change alerts and setting up alerts.

What you decide:

• Whether to set sp=reject for subdomains, or a different subdomain policy. By default a subdomain inherits the organisational policy, but you can decouple them; the subdomain policy explainer covers when a separate sp= makes sense, for instance leaving a noisy subdomain at quarantine while the root is at reject.
• Whether to tighten alignment from relaxed to strict, which is a meaningful change you should only make with eyes open.

The safety check at reject is ongoing rather than one-off: the same source-matching logic that guarded the ramp now guards production, alerting you the moment a recognised-but-newly-failing source appears so you can authorise it before anyone complains about missing mail.

The two things that break enforcement, and how the ramp handles them

Two phenomena cause most enforcement incidents, and a managed ramp is built specifically to absorb them.

Forwarding. When a message is forwarded, SPF breaks, because the forwarding server is not in your SPF record. If the message also lacks an aligned DKIM signature, it fails DMARC and, under reject, gets bounced. This is why DKIM matters so much: a DKIM signature survives forwarding where SPF does not. The forwarding and DMARC explainer covers the failure mode in detail. The ramp handles it by insisting on a healthy aligned DKIM pass for every important source before enforcement, so that forwarded copies still authenticate via DKIM even after SPF has broken.

SPF lookup overflow. SPF allows a maximum of ten DNS lookups. Authorising one more provider can tip you over, producing a permerror that makes SPF fail for all your mail at once, often discovered only when enforcement turns those failures into rejections. Hosted flattening prevents this by resolving your includes into a flat list of IP addresses that stays within the limit, and re-resolving when upstreams change. The mechanism is in how SPF flattening works, and you can pressure-test your own record with the SPF checker.

What stays your decision, summarised

The platform automates the mechanical and the observational: publishing records, parsing reports, classifying IPs, flattening SPF, hosting and rotating DKIM, stepping the percentage, and alerting on change. What it never automates is judgement that depends on knowing your business:

• Which unrecognised sources are legitimately yours.
• How aggressive a ramp pace your organisation can tolerate.
• When to hold, advance or roll back at a given step.
• Whether to treat subdomains differently with sp=.
• The final approval to publish each policy change.

This division is deliberate. A service that auto-published p=reject on a timer without your sign-off would be faster and far more dangerous. The point of done-for-you is not to remove you from the decisions that need your knowledge; it is to remove you from the toil that does not, and to make sure no decision is ever taken without report data behind it. You can see exactly what the platform sees, at any stage, through the dashboard at app.dmarcengine.com.

Where to start

If you are at p=none, or you have no DMARC record at all, the first move costs nothing and tells you where you stand. Run your domain through the DMARC checker to see your current policy and alignment posture, then the DMARC report analyzer if you already have reports to read. If you want the conceptual map before the operational one, the enforcement journey and the p=none false-security piece explain why monitoring alone is not protection. The full set of free diagnostics lives on the tools page, and the requirements page lays out what the mailbox providers now expect.

The managed path does not make enforcement risk-free; nothing does. What it does is replace guesswork with evidence at every stage, keep every step recoverable until the last, and make sure the day you finally publish p=reject is the least eventful day of the whole project.