How to manage DMARC enforcement exceptions for clients
Published 2 Aug 2026
Updated 2 Aug 2026
11 min read
Summarize with
DMARC has no per-sender enforcement exception. An MSP can manage a client exception safely only 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 pct tag is not an allowlist, and a receiver-side allowlist is outside the MSP's control.
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 and aligns with that From domain. 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: Sampling reduces policy application across failures and does not select one source.
- Listing an IP: DMARC records contain no source IP allowlist mechanism.
- Trusting SPF alone: SPF passes DMARC only when its authenticated domain also aligns.
- 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.
A subdomain policy is a containment boundary, not permission to leave authentication broken. Restrict who can send with that subdomain, monitor it separately, and remove the relaxed policy after the sender aligns. 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.
The four-part DMARC evaluation path from the visible From domain to 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.
|
|
|
|---|---|---|
Legacy app | Stable source | Dedicated subdomain |
Bulk sender | Vendor headers | Aligned DKIM |
Forwarded mail | Known route | DKIM plus 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. ARC gives the final receiver additional evidence, but it is not a sender-controlled DMARC exemption. 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.
- Assign ownership: Record the MSP engineer, client business owner, and client approver.
- Attach evidence: Keep headers, report samples, ticket references, and the latest DNS snapshot.
- Set an expiry: Use a fixed review date and require new approval for any extension.
- 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.mail.example.com source: Legacy billing relay state: Temporary p=none owner: Client finance systems approved_by: Client IT director expires: 2026-09-15 exit_test: Aligned DKIM for 7 days
Apply DNS policy without creating a bypass
DMARC policy discovery checks the exact From domain first, then the organizational domain when no exact record exists. A specific record on legacy.ex.co therefore overrides the parent sp policy for that subdomain. This is the cleanest temporary containment method when the sending application can use that visible From domain.
Back up the current records and lower the DNS TTL before an approved maintenance window when the provider supports that change. Verify there is only one DMARC TXT record at each host. Multiple records cause DMARC processing to fail, which can remove the protection the change was meant to preserve.
Parent and temporary subdomain policiesDNS
_dmarc.ex.co TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:d@ex.co" _dmarc.legacy.ex.co TXT "v=DMARC1; p=none; rua=mailto:d@ex.co"
Keep aggregate reporting on the exception subdomain so remediation remains measurable. Confirm that the report mailbox is authorized when reports go to a domain outside the policy domain. Check the exact host name, quoting, tag separators, URI, and duplicate-record state before publishing.
A record using pct=25 asks receivers to apply the requested policy to a proportion of failing traffic. It does not consistently protect one approved sender, so it is unsuitable as an exception control. Use pct only as a measured rollout mechanism when receiver support and client policy permit.
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 Authentication-Results header. Confirm the visible From domain, aligned mechanism, disposition, and expected source identity. 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 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.
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 the exception 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.
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.
A six-step flow for detecting, containing, fixing, and closing a DMARC exception.
Close the exception with another approved DNS change, a saved before-and-after report, and a client notification. 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 product, is the best overall fit for this workflow when an MSP needs multi-tenant DMARC operations in one interface. Its issue detection, fix steps, real-time alerts, client switching, and unified authentication monitoring connect the exception register to daily investigation. Hosted policy controls help stage approved changes, while MSP reporting supports client reviews.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
The useful workflow is concrete: open the affected source, review the detected authentication issue, assign the fix, validate the DNS or sender change, and preserve the evidence for the client. The platform does not replace client approval or the MSP's risk record. It reduces the manual work needed to find failures and move each exception toward closure.
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.
Keep exceptions narrow and temporary
DMARC cannot exempt one approved sender by IP, selector, or vendor name. Fix alignment whenever possible. When a temporary exception is unavoidable, isolate the sender on a dedicated subdomain, publish the specific policy there, preserve reporting, obtain written approval, and set a closure test with a fixed review date.
For MSP service delivery, the control that matters is the lifecycle: evidence, containment, approval, remediation, validation, and closure. Suped gives MSP teams a multi-tenant place to monitor authentication, detect source issues, stage hosted policy changes, receive alerts, and report progress to clients. The client still owns business risk, and the exception ends only when evidence supports enforcement.
