How to handle SPF and DKIM alignment for MSP clients
Updated on 14 Aug 2026: We updated this guide for RFC 9989 and added an ongoing alignment maintenance workflow for MSP teams.
SPF and DKIM alignment for MSP clients is handled by treating every sending source as an identity decision. The domain in the visible From address, the SPF return-path domain, and the DKIM signing domain have to be understood before DMARC enforcement can work without breaking legitimate mail.
I start with a sender inventory, then move each source into one of four practical paths: native DKIM using the client domain, a custom return-path domain for SPF, a delegated vendor subdomain, or removal. For an MSP program, the hard part is repeating the work across client domains with different vendors, DNS owners, approval processes, and risk tolerances.
What alignment means in client delivery
DMARC does not only ask whether SPF or DKIM passed. It also checks whether at least one passing mechanism uses an authenticated domain that matches the visible From domain under the selected mode. That comparison is SPF alignment or DKIM alignment, depending on which authentication path passed.
For MSP service delivery, I record four domains on every source: the Author Domain in the visible From address, the return-path domain checked by SPF, the d= domain in the DKIM signature, and the Organizational Domain used for relaxed comparison. If one SPF or DKIM identifier passes and has alignment with the Author Domain, DMARC passes.
Relaxed alignment, the default, accepts domains with the same Organizational Domain. Strict alignment requires an exact domain match. The DMARC adkim and aspf tags set those modes. RFC 9989 uses a DNS Tree Walk to discover Organizational Domains, so delegated subdomains and explicit subdomain DMARC records need to be part of the client review.
A client can pass SPF and DKIM at the protocol level and still fail DMARC. That usually happens when the authenticated domain belongs to a platform, reseller, shared mail system, or gateway instead of matching the client domain under the selected alignment mode.
- SPF: The return-path domain passed SPF and matched the visible From domain under the selected alignment mode.
- DKIM: The signing domain passed DKIM and matched the visible From domain under the selected alignment mode.
- DMARC: At least one passing path had identifier alignment with the visible From domain.
Infographic showing visible From, SPF path, DKIM signer, and DMARC pass.
The MSP onboarding sequence
The cleanest MSP workflow is repeatable by design. I want evidence before any DNS change. That means collecting aggregate DMARC reports, grouping sources, assigning ownership, and only then fixing SPF and DKIM. A mail platform list is not enough because clients often have old CRMs, scanners, accounting systems, form tools, and ticketing systems still sending mail.
- Inventory: Collect every source seen in aggregate DMARC reports and compare it with the client approved sender list.
- Classify: Mark each source as core mail, business application, marketing system, legacy device, or unauthorized traffic.
- Assign: Name the owner for the vendor login, DNS zone, change window, and testing contact.
- Fix: Enable DKIM with a matching client domain first where possible, then repair SPF return-path alignment where DKIM is unavailable or unreliable.
- Enforce: Move policy only after legitimate traffic passes consistently across normal business and reporting cycles.
Flowchart for MSP DMARC onboarding from adding a domain to enforcement.
A platform view matters once the work becomes recurring. Suped's DMARC monitoring workflow lets an MSP watch client domains, identify unverified sources, and turn authentication failures into assigned fix tasks instead of spreadsheet rows.
MSP organizations page showing client organizations, domain counts, email volume, and domain status columns
How to fix SPF alignment
SPF alignment depends on the return-path domain, not the visible From domain. That catches many MSP teams during onboarding. A vendor can appear in an SPF record and still fail DMARC if its authenticated return-path belongs to the vendor. The usual fix is a custom return-path or bounce domain under the client's Organizational Domain, with SPF authorization published at that return-path domain.
SPF and return-path example
Visible From: billing@example.com Return-path: bounces.vendor-mail.net SPF result: pass SPF alignment: fail Visible From: billing@example.com Return-path: bounce.example.com SPF result: pass SPF alignment: pass
I prefer DKIM as the durable fix when a source supports it. SPF still matters, but forwarding often changes the connecting server without changing the original return-path, which can make SPF fail. SPF evaluation also limits DNS-querying terms. When a client has many senders, Suped's Hosted SPF gives the MSP one workflow for authorized-source changes while keeping the published SPF response within protocol limits.
Native return-path
- Best use: Use when the sender supports a custom bounce domain for the client.
- DNS need: Publish the exact CNAME, MX, or TXT records supplied by the vendor.
- Verification: Confirm a real message uses the custom return-path and passes SPF with alignment.
SPF include only
- Best use: Use for authorization, not as proof that DMARC will pass.
- DNS need: Publish vendor authorization at the domain used in the return-path.
- Verification: Check both the SPF result and its alignment with the visible From domain.
Do not keep adding SPF includes until a client record works by chance. SPF permits no more than 10 terms that cause DNS queries during one evaluation, and nested includes count toward that limit. A permerror can interrupt otherwise legitimate mail authentication.
How to fix DKIM alignment
DKIM alignment is usually the better MSP target because a valid signature can survive forwarding and does not depend on the connecting IP. The practical task is to get each sender signing with a domain that matches the client's visible From domain under the selected alignment mode. For Microsoft 365 and Google Workspace, that usually means enabling DKIM for the accepted domain and publishing the records the platform generates.
Microsoft 365 Defender DKIM setup screen showing domain status and CNAME records.
|
|
|
|
|---|---|---|---|
 Microsoft 365 | Native DKIM | Add CNAMEs | Confirm d= domain |
 Google Workspace | Native DKIM | Publish TXT | Check active selector |
Marketing app | Domain signing | Add CNAMEs | Check test alignment |
Scanner | Relay through mail | Use connector | Review signed message |
Common DKIM handling by sender type
Microsoft 365 now supplies provider-generated CNAME targets, and newer custom domains can use a different target format than older domains. Retrieve both current values from the tenant instead of constructing them from an old template. Publish both selectors, enable signing, confirm the d= domain in a delivered message, and retain both records so selector rotation can complete cleanly.
Third-party applications vary. Some give the client a DKIM selector and CNAME targets. Some only sign with the vendor domain. Some support custom domains only on higher plans. I document the exact limitation in the client runbook because it determines whether to change DNS, change the vendor plan, isolate the sender, or replace it.
DKIM selector example
selector1._domainkey.example.com CNAME selector1-vendor.example.net selector2._domainkey.example.com CNAME selector2-vendor.example.net
How to treat exceptions and shared senders
MSP clients always have exceptions. The mistake is treating every exception as a reason to stay at monitoring forever. I give each exception a named owner and a recorded disposition. A temporary exception gets a due date. An accepted exception is isolated under a subdomain when possible. A blocked exception is removed from the approved sender list and included in client security reporting.
Use the root domain
Use the client root domain for core business mail when the platform supports DKIM with the client domain and the sender is operationally important.
- Example: User mail, invoices, service desk, and client-facing notifications.
Use a subdomain
Use a dedicated subdomain when a sender needs separation, has weaker controls, or sends mail with a different risk profile than normal business messages.
- Example: Marketing campaigns, event mail, surveys, and bulk notices.
Subdomains make client risk easier to discuss. A marketing platform can use mail.example.com while the main company mail stays on example.com. Keep control of the delegated DNS boundary, publish an explicit DMARC record where needed, and record which vendor can authenticate with that subdomain. This gives the MSP a cleaner enforcement path because a vendor delay does not hold the entire client domain open.
Keep alignment working after onboarding
Alignment is recurring change control, not a one-time DNS project. New applications appear, vendor return-paths change, selectors rotate, and client domains move between tenants. The sender inventory remains the source of truth after enforcement.
- Approve new senders before launch: Require the visible From domain, return-path option, DKIM setup, owner, and test evidence in the change ticket.
- Track selector rotation: Keep old and new DKIM selectors published until reports show the new selector in normal use and the vendor confirms the old key is retired.
- Review delegated subdomains: Check who controls DNS, which DMARC policy applies, and whether relaxed alignment grants more authority than the client intended.
- Triage new report sources: Investigate new volume, alignment failures, and unknown providers before adding anything to SPF or publishing a DKIM key.
- Plan client offboarding: Hand over the sender inventory, current policy, open exceptions, DNS dependencies, and aggregate-report destination before access ends.
A monthly review should answer two questions for every client domain: which legitimate source changed, and which new source needs approval or removal? Policy enforcement can stay in place when those questions have owners.
When to move policy
Policy staging is where service delivery becomes visible to the client. I do not move a domain to quarantine or reject because the DNS looks correct once. I move it when normal mail flow has been observed, high-volume legitimate sources pass DMARC, known exceptions have written decisions, and the change record has rollback criteria.
DMARC enforcement gates
A practical MSP policy model based on observed mail flow and controlled change windows.
Monitor
p=none
Collect reports and identify legitimate or unauthorized senders.
Quarantine
p=quarantine
Apply quarantine after source alignment and exceptions have been verified.
Reject
p=reject
Request rejection after full reporting cycles meet the client's acceptance criteria.
DMARC policy stages
v=DMARC1; p=none; rua=mailto:dmarc@example.com v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com v=DMARC1; p=reject; rua=mailto:dmarc@example.com
RFC 9989 made the pct tag historic because receivers did not apply percentage sampling consistently. Do not present pct=25 as a controlled 25% rollout. Stage enforcement by client domain or dedicated sending subdomain, observe full reporting cycles, and keep a tested rollback path.
RFC 9989 also introduced t=y to request policy test mode. It is not percentage sampling, and receiver handling remains subject to local policy, so the MSP still needs test evidence and rollback criteria.
A staged policy gives account managers a clear client conversation. The report becomes a list of vendors that are fixed, vendors waiting on access, exceptions with decisions, and senders the client has retired.
Where Suped fits
Suped is our DMARC and email authentication platform. MSP teams use its multi-tenant view to separate client organizations, group sending sources, investigate SPF and DKIM alignment failures, record remediation work, and watch for changes after enforcement.
- Multi-tenant view: Use organization switching to manage client domains without mixing reporting data.
- Issue detection: Turn failing sources into specific SPF, DKIM, or alignment checks for the assigned engineer.
- Hosted controls: Use hosted DMARC, Hosted SPF, SPF flattening, or hosted MTA-STS when the client approves delegated management.
- Reputation context: Add blocklist (blacklist) monitoring when delivery triage needs IP or domain reputation evidence.
Suped's domain health checker gives the onboarding engineer a quick view of published DMARC, SPF, and DKIM records before aggregate reporting is used to verify real mail flow.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The MSP process should be simple enough for every engineer to repeat: add the domain, collect reports, verify sources, fix DKIM, repair SPF where needed, then move policy through documented change windows.
Client communication and documentation
The technical work fails commercially when the client cannot see progress. I keep a short client-facing record for each domain: approved senders, current DMARC policy, sources fixed, sources awaiting access, and sources recommended for removal. That keeps the MSP from owning vendor delays silently.
|
|
|
|---|---|---|
Sender | Client or MSP | Approved |
DNS | MSP | Pending |
Vendor | Client | Waiting |
Policy | MSP | Staged |
Client reporting fields
I also avoid saying a sender is fixed until I have seen a real message pass DMARC in reporting or in a controlled test. DNS publication proves a setup step happened. Passing mail proves the sender is using the setup correctly.
Do not let one weak sender block enforcement for the whole client domain without a decision. Isolate it to a subdomain, replace it, or document the accepted risk with the client.
A practical operating model
The right way to handle SPF and DKIM alignment for MSP clients is to standardize the work. Use aggregate DMARC reporting to discover real senders, fix DKIM first where the signing domain matches the client domain, use custom return-path domains when SPF must carry the pass, and isolate weaker senders under controlled subdomains.
Once the MSP has this operating model, every client domain moves through defined evidence gates. Each exception has an owner, every policy change has rollback criteria, and recurring review catches sender or selector changes before they become delivery incidents.
