How to implement DMARC p=reject policy safely to avoid email deliverability issues?
Updated on 22 Oct 2026: We clarified DMARC test-mode behavior, report review, and rollback checks for safer reject rollouts.
Implement p=reject safely by proving that every legitimate sender passes DMARC through aligned SPF or aligned DKIM, then moving through p=none, p=quarantine, and p=reject. RFC 9989 makes pct historic and defines t=y for policy testing. Check receiver support before using test mode. Do not change a busy root domain straight to reject unless aggregate reports already prove that every legitimate sender is known and aligned.
The main risk is hidden mail. Password resets, billing emails, cron alerts, support tools, sales systems, and vendor mail often use a domain long before the security team sees them. Their authentication failures become false positives under enforcement. Auto-forwarding adds another risk: SPF usually fails after forwarding, and DKIM fails when a forwarder or mailing list changes signed content.
- Baseline: collect DMARC aggregate reports at p=none until legitimate and unauthorized sources are separated.
- Fix: make each approved sender pass DMARC through aligned DKIM or SPF.
- Stage: check receiver support before testing quarantine or reject with t=y, then apply each policy with t=n after legitimate failures are resolved.
- Gate: promote only when reports, bounce logs, and support channels show no legitimate breakage across a complete sending cycle.
The safe rollout order
The safe approach is a controlled rollout. A useful DMARC monitoring workflow should show the sending source, envelope sender, DKIM domain, SPF result, DKIM result, From-domain alignment, and receiver disposition. Without that view, a policy change is based on assumptions.
Use this sequence for domains that already send customer or employee mail. Keep each stage active through at least one complete sending cycle, including monthly billing, scheduled alerts, campaigns, and low-frequency vendor traffic. This can take weeks or months, depending on sending cadence.
|
|
|
|
|
|---|---|---|---|---|
Observe | p=none | Not applicable | None requested | All legitimate sources inventoried |
Test quarantine | p=quarantine | t=y | None where t is supported | Legitimate failures resolved; receiver support checked |
Apply quarantine | p=quarantine | t=n | Quarantine | Full sending cycle is stable |
Test reject | p=reject | t=y | Quarantine where t is supported | Quarantine stable; receiver support checked |
Complete | p=reject | t=n | Reject | Reports and support remain stable |
A practical DMARC enforcement ladder for active sending domains.
Test mode is not a delivery guarantee
Receivers supporting t=y apply one level less enforcement: p=quarantine; t=y requests none, and p=reject; t=y requests quarantine. t=n is the default when omitted. Older implementations can ignore t and enforce the published p value. Resolve legitimate failures before publishing either test policy. See RFC 9989.
What p=reject changes
DMARC passes when SPF or DKIM passes and the authenticated domain matches the visible From domain under the configured alignment mode. p=none expresses no handling preference. The rua tag requests aggregate reports under any policy. p=quarantine tells receivers that failing mail is suspicious. p=reject tells receivers that use of the domain on failing mail is not valid and requests rejection.
Receivers still apply local policy. Some accept mail despite a reject request when they trust an indirect mail path or have other evidence. A DMARC pass also does not guarantee inbox placement; sender reputation and receiver filtering still affect delivery. Reject addresses unauthorized use of your exact domain, while lookalike domains and display-name impersonation require separate controls.
Before reject
- Visibility: reports show who sends with your domain.
- Tolerance: p=none requests no DMARC enforcement; receivers still filter mail.
- Risk: exact-domain spoofing is not blocked by the DMARC policy.
After reject
- Protection: receivers get a clear request to reject failures.
- Exposure: forgotten legitimate systems can be blocked.
- Evidence: support tickets and bounce logs matter alongside aggregate reports.
Gmail's bulk sender requirements accept p=none for DMARC and require both SPF and DKIM. A stricter policy alone does not establish compliance.
Replace the example domain and report mailbox with your own values. Edit the existing DMARC TXT record rather than adding a second policy record.
Staged DMARC TXT examplestext
Start in reporting mode Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com Test quarantine (expect none where t is supported) Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com Apply quarantine Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=quarantine; t=n; rua=mailto:dmarc@example.com Test reject (expect quarantine where t is supported) Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=reject; t=y; rua=mailto:dmarc@example.com Apply reject Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=reject; t=n; rua=mailto:dmarc@example.com
Build the sender inventory
Start with mail seen in aggregate reports and cross-check it with team inventories and outbound mail logs. Reports show what participating receivers saw. They do not cover every recipient or every sending path, so a quiet report period does not prove that no other senders exist.
A root domain needs special care because many departments have used it over time. Product notifications, finance mail, internal monitoring, sales sequences, one-off event tools, HR systems, and old servers can all appear. A subdomain created for one narrow mail stream is easier to enforce because ownership is clear.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Suped's product supports this inventory workflow by grouping DMARC sources, showing alignment results, and separating verified senders from sources that need investigation. A reject policy is ready only when unknown traffic has been investigated and every approved source passes DMARC.
- Transactional: password resets, receipts, invoices, account alerts, and product notifications.
- Operational: cron jobs, monitoring alerts, internal tools, and legacy servers.
- Commercial: campaign platforms, sales outreach, event mail, and partner systems.
- Corporate: employee mail, shared mailboxes, help desk aliases, and executive mail.
Before tightening policy, run a broad domain check and confirm that visible DNS records match the senders in aggregate reports. A point-in-time check is useful, but DMARC safety depends on authentication results from real traffic.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Fix missing, duplicate, or conflicting records before changing policy. Keep a single DMARC policy record at each _dmarc name. Continue monitoring after the fix because a valid DNS record does not prove that each mail stream uses it correctly.
Read DMARC reports before each policy change
Aggregate reports usually cover a daily period. Check the reporting window and observed policy before attributing failures to a DNS change; a report spanning the change can contain results under both policies. RFC 9990 defines the report format.
|
|
|---|---|
Source IP and message count | Identify the sending service and its volume. |
Authentication and alignment | Compare raw SPF/DKIM results with DMARC evaluation; authentication alone can pass while DMARC fails. |
Disposition and override reason | Check receiver handling and explanations for policy exceptions. |
Receiver and reporting period | Compare the same mail stream across recipient providers and time windows. |
Fields to review when deciding whether to advance enforcement.
Calculate pass rates for legitimate mail separately from spoofed traffic. A high overall rate can hide a failing password-reset system, so investigate failures by sender and recipient provider. No universal percentage establishes that reject is safe.
If reports are missing, verify the rua destination and any required external reporting authorization at the destination domain. Reports arrive after the reporting period and are not real-time delivery logs; use outbound logs and bounce responses for immediate incidents.
Protect subdomains before reject
A policy on the organizational domain also affects subdomains that do not publish their own DMARC record. Under RFC 9989, sp sets the policy for existing subdomains and np sets it for non-existent subdomains. If np is absent, non-existent subdomains inherit sp when present, otherwise p. Existing subdomains use p when sp is absent. Publishing the intended values explicitly makes the scope easier to audit.
|
|
|
|---|---|---|
p | Domain publishing the record and applicable subdomains | Set after its legitimate senders are aligned |
sp | Existing subdomains without their own record | Audit delegated and forgotten subdomains first |
np | Non-existent subdomains | Use reject when those names never send mail |
Subdomain record | One specific Author Domain | Use a temporary exception while its senders are fixed |
How organizational and subdomain DMARC policies interact.
Subdomain policy examplestext
Organizational domain at full enforcement Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=reject; sp=reject; np=reject; t=n; rua=mailto:dmarc@example.com Temporary reporting-only policy for one active subdomain Host: _dmarc.marketing.example.com Type: TXT Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com
Audit delegated subdomains
A delegated subdomain can have separate DNS ownership and sending systems. Confirm its owner, DMARC record, and aligned authentication before the organizational policy reaches reject. Keep any weaker per-subdomain policy temporary and documented. Assign an owner and an expiry date to each exception.
Fix domain alignment before enforcement
Aligned DKIM is a useful foundation for each legitimate sender because it can survive forwarding. Aligned SPF also produces a DMARC pass, but forwarding commonly breaks SPF. DKIM survives forwarding when the signed headers and body are unchanged, so domains at reject should not rely on SPF alone.
Relaxed alignment is the default: a DKIM d=mail.example.com or Return-Path domain bounce.example.com matches a visible From domain of example.com. Strict alignment (adkim=s or aspf=s) requires an exact domain match. Review Google's DMARC documentation before changing alignment modes, and keep that change separate from enforcement.
Validate syntax before every policy change. Use the DMARC checker for the current record, and use a record generator to create a staged record without missing tags.
Authentication fixes that matter
- DKIM: sign with a domain that matches the visible From domain under the chosen relaxed or strict alignment mode.
- SPF: authorize approved sources within the limit of 10 DNS-querying terms per evaluation, including nested includes; exceeding it returns permerror. See RFC 7208.
- Return path: use a domain that meets the configured SPF alignment mode when SPF is expected to carry the DMARC pass.
- Selectors: rotate DKIM keys cleanly and retain old public keys until messages signed with them have cleared delivery queues.
One aligned authentication path is enough for a DMARC pass, but configure both where the sender supports them. A sender that passes aligned DKIM can tolerate SPF failure after forwarding. A sender that relies only on aligned SPF has a known forwarding weakness. Retire or fix any source that fails both before reject.
Sender-level acceptance checklisttext
For each source: 1. Identify owner and business purpose. 2. Confirm visible From domain. 3. Confirm DKIM pass and DKIM alignment. 4. Confirm SPF pass and SPF alignment where possible. 5. Send live messages to key recipient providers; inspect Authentication-Results. Compare header.from with header.d and smtp.mailfrom. 6. Watch DMARC reports after the next scheduled send.
Handle forwarding and legitimate failures
Forwarding needs deliberate testing. When a user forwards mail between providers, SPF usually fails because the forwarding server is not authorized by the original envelope sender. DKIM survives only if the forwarder leaves the signed message content intact.
Mailing lists, role-based aliases, and alumni forwarders can also modify or relay mail in ways that break DMARC. Some receivers recognize trusted indirect paths and override the published disposition, but that local decision does not remove the need for aligned DKIM and gradual enforcement.
DMARC decision flow showing SPF or DKIM checks, domain alignment, and receiver handling.
Breaks more often
- SPF: fails when the forwarder is not authorized by the envelope sender domain.
- Body changes: can break DKIM when footers or banners alter signed content.
- Old systems: often send without aligned DKIM or a managed return path.
Survives better
- DKIM: survives forwarding when signed content stays unchanged.
- ARC: can provide evidence about authentication before forwarding, but it does not create a DMARC pass.
- Staging: shows which providers and mail streams create failures.
Mailing lists can remain incompatible with reject
Domains whose users post to external mailing lists need extra caution. RFC 9989 advises against reject for these domains; before proceeding, it recommends at least a month at p=none and an equally long period at p=quarantine, comparing dispositions. If testing shows unresolved legitimate failures, hold enforcement and resolve the indirect path. See RFC 9989.
Use gates and rollback triggers
A staged rollout needs explicit promotion, hold, and rollback rules. Define them before the DNS change so that business impact, not rollout momentum, determines the next action.
Promotion gates for reject rollout
Use evidence-based gates that account for the domain's complete sending cadence.
Promote
Legitimate mail aligned
Every legitimate source is known and passes aligned SPF or DKIM.
Hold
Known legitimate failure
A legitimate sender is failing but has an owner and remediation plan.
Rollback
Confirmed user impact
Critical customer or employee mail is blocked.
Monitor
One full sending cycle
Keep each stage long enough to include every normal scheduled mail stream.
A written policy transition plan should name the approver for each step, the owner of each sender fix, and the person authorized to roll back. Lower the DMARC record's DNS TTL at least one existing TTL interval before the change window, then restore the normal TTL after the policy is stable. A rollback also depends on cached DNS records expiring, so it is not instant. Restore the last known good policy and confirm delivery with fresh test messages; messages already rejected need to be resent after the failure is fixed.
- Prepare: save the last known good record and confirm the rollback owner before changing DNS.
- Promote: remaining failures are unauthorized, retired, or controlled test traffic.
- Hold: a legitimate sender fails DMARC but has a clear owner and fix path.
- Rollback: customer mail, employee mail, security alerts, or billing mail is blocked.
- Document: record each policy change with its time, owner, reason, and observed result. Require new senders to prove aligned authentication before launch, and keep monitoring after reject.
Monitor the rollout with Suped
Suped's product connects a reject rollout to the operational work behind it: source discovery, alignment diagnostics, issue alerts, and remediation steps. Teams can review aggregate report data and policy status in the same workflow instead of handling raw XML manually.
For organizations managing many domains, Suped's MSP and multi-tenancy dashboard keeps domains, reports, sender issues, and enforcement status in one view. The relevant outcome is a traceable decision about which domains are ready to advance and which need remediation.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
With Hosted DMARC, teams can apply policy changes without requesting a manual DNS edit for each rollout step. DNS access is still needed for the initial hosted configuration, and receivers can continue using cached records until their TTL expires.
Manual workflow
- Reports: aggregate XML needs parsing and source grouping.
- Ownership: teams identify senders through manual follow-up.
- Changes: DNS edits depend on access and change windows.
Suped workflow
- Reports: sources, pass rates, and alignment issues are summarized.
- Fixes: issue pages show steps for the detected failure.
- Alerts: notifications flag authentication changes during rollout.
Frequently asked questions
A verified non-sending domain can move directly to reject. An active domain with a complete sender inventory and stable authentication can also proceed once legitimate and indirect mail paths have been tested. For other active domains, use quarantine to measure the effect before reject.
Forwarding usually breaks SPF, and DKIM survives only when signed content is not changed. Aligned DKIM, indirect-path testing, and receiver override data in aggregate reports help identify the remaining risk.
Keep each stage active through a complete sending cycle. Include monthly billing, scheduled campaigns, vendor notifications, and low-frequency systems. Complex domains can require several months of aggregate report analysis before reject is safe.
Quarantine provides enforcement and is a useful transition stage, but receivers can place failing mail in spam or apply another local action. Keep quarantine while legitimate failures or mailing-list incompatibilities remain unresolved. Move to reject after those issues are resolved and indirect paths have been tested.
Confirm that the domain and relevant subdomains have no legitimate sending sources, publish an SPF fail-all record such as v=spf1 -all, and set DMARC to p=reject. An unused domain does not need DKIM keys because it signs no legitimate mail.
