How to manage DMARC enforcement exceptions for clients
Published 2 Aug 2026
Updated 9 Oct 2026
13 min read
Summarize with
Updated on 9 Oct 2026: We updated this guide for current DMARC policy rules and added rollback steps for client exceptions.
DMARC has no per-sender enforcement exception. An MSP can manage a client exception by fixing SPF or DKIM alignment, moving the affected sender to a dedicated subdomain with its own DMARC policy, or delaying enforcement for the entire policy domain. The retired pct tag is not an allowlist. Receiver-side allowlisting is a local override, not a sender-published exception.
Treat an exception as a time-limited change record, not a permanent bypass. Record the exact source, business owner, affected domain, reason, approval, expiry date, risk, and exit test. Keep the main client domain at the strongest safe policy, then contain any temporary relaxation within the smallest subdomain boundary available.
What DMARC can and cannot exempt
DMARC evaluates the visible From domain against SPF and DKIM authentication results. A message passes when at least one of those mechanisms passes with domain alignment. The published policy applies after DMARC fails. The record has no tag that names an approved vendor, IP address, envelope sender, or DKIM selector.
Valid controls
- Fix alignment: Configure aligned DKIM or an aligned SPF return path for the source.
- Isolate the sender: Move legacy mail to a dedicated subdomain with a specific policy.
- Stage enforcement: Use quarantine before reject while remediation work remains active.
- Separate mail streams: Give transactional or legacy traffic its own visible From domain.
False exceptions
- Using pct: pct is historic and does not select one approved source.
- Listing an IP: DMARC records contain no source IP allowlist mechanism.
- Trusting SPF alone: SPF satisfies DMARC only when its authenticated domain also meets alignment requirements.
- Requesting receiver bypasses: Local receiver decisions are inconsistent and cannot be managed through sender DNS.
Prefer an authentication fix because it preserves one policy boundary and removes the failure at its source. Aligned DKIM is often the durable option for third-party platforms because SPF can break during forwarding and shared infrastructure can complicate return-path control. Confirm the vendor's actual capability with test headers, not sales documentation alone. Check aspf and adkim: relaxed alignment accepts a shared organizational domain; strict alignment requires an exact domain match. Changing either setting affects every sender governed by that record.
A subdomain policy is a containment boundary, not permission to leave authentication broken. Restrict who can send with that subdomain, monitor it separately, and restore enforcement after the sender passes with alignment. If the application cannot change its From domain or authentication, the client must decide whether its business value justifies delaying wider enforcement.
A p=reject policy requests rejection of messages that fail DMARC. Receiving systems retain local discretion, so an MSP can control the client's authentication and policy but cannot guarantee every receiver's final action.
Explain this boundary clearly in client reports. The published policy communicates the domain owner's requested treatment, while the receiver makes the final delivery decision. This avoids promises that every noncompliant message will receive identical handling across all destinations.
Operationally, manage what the client controls: sender authorization, aligned authentication, domain structure, DNS policy, and evidence. Receiver behavior belongs in monitoring and incident analysis, not in the exception design.
DMARC evaluation showing the visible From domain, SPF or DKIM authentication, domain alignment, and policy action.
Choose the smallest exception boundary
Start with a complete sending-source inventory. Identify the exact visible From domain, envelope domain, DKIM signing domain, selectors, source IPs, message purpose, owner, and expected volume. Aggregate reports identify authentication patterns, but sample headers and controlled test messages confirm alignment.
If the sender already uses a distinct subdomain, publish a specific DMARC record there and leave the organizational domain protected. If it shares the apex From domain, there is no DNS-level carveout for only that sender. The choices are to repair alignment, change its From domain, migrate it, or keep the wider domain below reject until the risk owner accepts the remaining exposure. A p=none exception covers all mail using that From domain, including unauthorized traffic. With relaxed alignment, subdomain SPF or DKIM credentials can also authorize the parent From domain; restrict delegated access and test strict alignment before changing it.
|
|
|
|---|---|---|
Legacy app | Stable source | Dedicated subdomain |
Bulk sender | Vendor headers | Aligned DKIM |
Forwarded mail | Known route | Aligned DKIM; receiver-trusted ARC |
Unknown source | No owner | Block or investigate |
Compact exception routing guide
Forwarding deserves separate analysis because SPF often breaks when the forwarding system changes the connecting IP. A valid aligned DKIM signature can preserve DMARC pass unless message changes invalidate it. ARC gives the final receiver additional evidence only when it trusts the intermediary; it does not change a DMARC fail into a pass. Use a repeatable forwarding troubleshooting process before relaxing policy.
Build an exception record
Every exception needs enough detail for another engineer to validate, operate, and close it without relying on memory. Store the record beside the client's change history and service notes. A shared register also stops one technician's temporary decision from becoming an undocumented standard across the portfolio.
- Define scope: Name the client, policy domain, subdomain, sender, and affected mail stream.
- Record the risk: Document the business reason, delivery impact, current and requested policies, and exposure accepted by the client.
- Assign ownership: Record the MSP engineer, client business owner, and client approver.
- Attach evidence: Keep headers, report samples, ticket references, the latest DNS snapshot, and the approved rollback target.
- Set an expiry: Set separate review and expiry dates; require fresh approval before extending the expiry.
- Define closure: Specify the alignment result, observation period, and change needed to enforce.
A standard register is part of reliable DMARC for MSPs delivery. It lets service managers see which clients carry accepted risk, which owners owe actions, and which exceptions have passed their expiry date.
Use consistent states such as proposed, approved, remediating, ready to close, and closed. A state change should record who made it, when it happened, and which evidence supports it. This provides an audit trail without turning the register into a second ticketing system.
Example exception register entryYAML
client: Northwind domain: legacy.example.com source: Legacy billing relay state: remediating temporary_policy: p=none owner: Client finance systems msp_owner: MSP messaging engineer approved_by: Client IT director reason: Legacy relay lacks aligned DKIM risk: No DMARC rejection requested for this subdomain next_review: 2026-10-17 expires: 2026-11-15 sending_cadence: daily exit_test: Aligned DKIM across all expected daily runs for 7 days rollback_policy: p=none (approved only for this subdomain)
Prepare a rollback for legitimate mail failures
Agree the rollback trigger and approver before changing policy. Trigger it for confirmed DMARC rejection or quarantine of an approved business mail stream after enforcement, using the client's delivery tolerance. Failures from spoofed or unknown sources alone are not a rollback trigger.
- Confirm the cause with receiver SMTP responses, bounce messages, delivery logs, or trusted Authentication-Results headers. Separate DMARC enforcement failures from unrelated delivery problems.
- Restore the last approved policy only at the affected From domain. If the sender shares the apex domain, record the wider exposure and obtain the required client risk approval.
- Keep rua reporting enabled, record DNS values and change times, and retest the affected mail stream at impacted receivers after cached records expire.
- Assign a new review deadline and remediation action. Keep the rollback exception open until evidence supports another enforcement attempt.
Lower TTL far enough in advance for the previous TTL to expire; a rollback cannot recall already rejected messages. Use delivery logs and direct tests during incidents because aggregate reports arrive after the traffic they summarize.
Apply DNS policy without creating a bypass
DMARC policy discovery checks the exact From domain first. RFC 9989 uses a DNS tree walk when no valid exact record exists. A valid record at _dmarc.legacy.example.com takes precedence for legacy.example.com. Publish at the exact From domain rather than relying on intermediate-parent inheritance across receiver implementations.
Back up the current records and lower the DNS TTL before an approved maintenance window when the provider supports that change. Verify the resolved TXT answer contains only one DMARC policy record. Duplicate DMARC records are discarded at that host; under RFC 9989, discovery continues through the DNS tree walk.
Parent and temporary subdomain policiesDNS
_dmarc.example.com TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com" _dmarc.legacy.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
Keep aggregate reporting on the exception subdomain so remediation remains measurable. An explicit subdomain policy needs its own rua value; reporting destinations are not merged with the parent record. Confirm external reporting authorization when the destination has a different organizational domain. Check the exact host name, quoting, tag separators, URI, and duplicate-record state before publishing.
RFC 9989 removed pct; omit it from new records. Stage enforcement with subdomain policies or whole-policy changes. The t=y flag requests reject-to-quarantine or quarantine-to-none treatment of failures, not a sender exception. Receivers without t support ignore it and apply the published policy, so it cannot guarantee a safe test everywhere.
Before approving an exception, check SPF at the envelope sender domain for duplicate v=spf1 records and the limit of 10 DNS-lookup-causing terms during evaluation. Exceeding that limit returns permerror. Adding an SPF include at the visible From domain does not fix a vendor-owned return path. Verify the DKIM selector record and signing domain before relaxing policy.
Suped's Hosted DMARC gives MSP teams a practical way to stage policy changes and manage client domains without repeatedly editing raw TXT values. The change still needs an approved exception record and DNS validation. Hosted policy control does not create a sender-level bypass that DMARC itself lacks.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Validate both the parent record and every explicit exception subdomain after DNS propagation. Save the parsed result with the ticket, then compare it with the intended change. A syntactically valid record can still enforce the wrong boundary if it is published at the wrong host.
Send controlled messages through the affected application and inspect the receiving system's trusted Authentication-Results header. Confirm the visible From domain, aligned mechanism, DMARC pass or fail, and expected source identity. Use receiver logs or bounce data to confirm enforcement actions. DNS validation alone cannot prove that the application signs or routes production mail correctly.
Roll out and monitor the exception
An exception is operational work until it closes. Use Suped's DMARC monitoring to track volume, alignment, new sources, and policy disposition by client and subdomain. Establish a baseline before the DNS change, then compare the same source after remediation. Raw pass rate alone can hide an unexpected sender if total volume changes.
In aggregate XML, auth_results contains raw SPF and DKIM checks; policy_evaluated.spf and policy_evaluated.dkim show the DMARC alignment outcome. Review policy_evaluated.reason for receiver overrides. Disposition describes DMARC handling, not inbox placement. RFC 9990 defines these report fields. Keep delivery logs alongside reports; missing report coverage is not proof of successful delivery.
Suggested exception review SLA
These are internal MSP operating targets, not DMARC protocol requirements. Adjust them in the client service agreement.
New
0-7 days
Owner and evidence confirmed
Remediation
8-30 days
Technical fix in progress
Escalated
31-60 days
Client decision required
Risk review
Over 60 days
Renew or close formally
Review reports as they arrive during policy changes, then at least weekly during active remediation. Compare aligned and unaligned volume for the named source, check whether unrelated sources have appeared on the relaxed subdomain, and verify that the business owner still needs the mail stream. Unexpected traffic on an exception subdomain needs investigation because attackers also benefit from relaxed enforcement.
Before closing, require a stable observation window that covers the sender's real cadence. A monthly billing system needs evidence across its monthly run, while a daily notification platform can produce useful evidence sooner. The exit test should state the period and permitted failure rate rather than relying on a vague status such as fixed. Calculate readiness on approved sources separately from spoofed and unclassified traffic.
Use the DMARC checker after each policy update, then send a real message and inspect its authentication result. Escalate missed milestones to the client approver. Do not silently extend the expiry because a vendor ticket remains open.
MSP DMARC exception lifecycle: detect a failure, confirm ownership, contain scope, fix alignment, observe results, and enforce policy.
Close the exception with an approved policy change, saved before-and-after evidence, and a client notification. Set the subdomain to p=reject, or remove its record only after confirming the inherited policy and reporting destination. If retiring the sender, remove unused SPF authorization and DKIM keys or DNS delegations. Continue monitoring after enforcement so delayed or low-volume mail does not create a surprise. If failures return, open a new incident linked to the closed exception instead of reopening history without a fresh risk decision.
Operate exceptions across client portfolios
MSP scale changes the problem. Separate spreadsheets, mailbox rules, and engineer memory make expiry dates easy to miss. Use one queue with client, domain, source, status, owner, approval, next action, due date, and evidence links. Give service managers a portfolio view and engineers the source-level detail needed for remediation.
Suped, our DMARC reporting and email authentication platform, gives MSP teams a shared view of client domains. Use its issue detection and fix steps to investigate failing sources, route authentication alerts to the responsible team, and attach source evidence to the exception ticket. Hosted policy controls support approved changes, while client reporting supports risk reviews.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Open the affected source, review the detected authentication issue, assign the fix in the service ticket, validate the DNS or sender change, and preserve the evidence for the client. Keep client approval and the MSP's risk record in the service management workflow.
Keep the portfolio queue tied to normal service management. An exception that blocks a policy milestone belongs in the client's regular operational review, with the same owner and due date shown in both places. Duplicate systems with different statuses create disputes about which record is current.
A healthy portfolio has few active exceptions, named owners, current evidence, and visible closure dates. A growing exception count indicates a remediation backlog or weak client governance, even when aggregate DMARC pass rates look high.
Set client and MSP responsibilities
The client owns business acceptance and sender decisions. The MSP owns technical evidence, safe implementation, monitoring, and escalation within the agreed service scope. Put those responsibilities in the onboarding pack and change process before the first enforcement rollout. Use explicit reject readiness criteria so commercial pressure does not override unresolved evidence.
Set escalation contacts before enforcement begins. The technical contact can approve routine DNS work, but a business risk decision needs someone authorized to accept lost protection or interrupted mail. Recording both contacts prevents an urgent exception from stalling when one person is unavailable.
MSP responsibilities
- Collect evidence: Identify the failing source and authentication path.
- Design containment: Choose the narrowest safe policy boundary.
- Implement safely: Back up DNS and verify every change.
- Escalate expiry: Raise overdue decisions to the named approver.
Client responsibilities
- Name owners: Identify who controls each business mail stream.
- Approve risk: Accept temporary exposure through an authorized decision maker.
- Fund remediation: Authorize vendor work, migration, or application changes.
- Confirm closure: Validate the business process after enforcement.
Define what happens when a client misses a deadline. The practical choices are renewed approval with a new date, migration to an isolated subdomain, suspension of the affected sender, or formal acceptance that the wider domain cannot yet move to reject. Record the decision and its effect on the client's protection level.
Frequently asked questions
No. DMARC has no IP allowlist tag. Make the source pass with aligned SPF or DKIM, or move its visible From address to a dedicated subdomain with a separate policy.
No. pct is historic, and t=y tests policy across failing mail rather than selecting a sender. Use a dedicated From subdomain or repair authentication.
Yes. A valid record at the exact From subdomain takes precedence. Without one, existing subdomains use the discovered organizational domain's sp policy, or p when sp is absent; np applies to non-existent subdomains.
Only as long as the approved remediation plan requires. Set a fixed review date, monitor the source through its real sending cadence, and require fresh risk approval for any extension.
Keep the corrected DNS or sender configuration, controlled test headers, aggregate reporting across the agreed observation window, proof that expected traffic passes with alignment, and approval for the enforcement change.
