How to explain SPF, DKIM, and DMARC alignment to clients
Updated on 23 Oct 2026: We clarified vendor alignment fixes, header checks, and the difference between a DMARC pass and bulk-sender requirements.
DMARC alignment means a message passes SPF or DKIM using a domain that matches the visible From domain under the selected relaxed or strict mode. Authentication and domain matching are separate parts of the decision.
For MSP clients, keep the explanation practical. SPF checks whether the sending IP is authorized for the envelope sender domain. DKIM verifies a cryptographic signature and ties it to the d= signing domain. DMARC checks whether at least one passing identity has alignment with the visible From domain. The DMARC record also publishes the domain owner's reporting and handling preferences for failures. Alignment is the bridge between the technical check and the domain the client is trying to protect.
- SPF (Sender Policy Framework): Checks whether the sending IP is allowed by the domain in the SMTP MAIL FROM identity, commonly shown as Return-Path after delivery.
- DKIM (DomainKeys Identified Mail): Checks whether a signature is valid for the d= signing domain and whether the signed content remained intact.
- DMARC (Domain-based Message Authentication, Reporting, and Conformance): Passes when SPF or DKIM passes with an identity that has alignment with the visible From domain.
- Alignment: Connects the authenticated domain to the visible From domain. It compares domains, not the full email address or Reply-To.
Client-safe wording
The simplest client explanation is: "Your email needs to pass an ID check, and the company name on that ID needs to match the company name customers see." That avoids DNS jargon while still preparing the client for why vendor records, marketing platforms, and billing systems need review before enforcement.
Use the client version first
Clients do not need to memorize every DNS term before they approve a DMARC project. They need to understand why some legitimate services fail, why the MSP has to inventory senders, and why moving straight to enforcement without monitoring creates avoidable mail disruption.
Explain SPF, DKIM, and DMARC alignment in two layers. The first layer is a business version for the owner or another business stakeholder. The second layer is a technical version for whoever controls the client's email and DNS systems.
Business explanation
- Identity: The visible From domain is the name customers trust.
- Proof: SPF authorizes a sending path, while DKIM validates a domain signature.
- Decision: DMARC checks whether either proof matches the brand domain.
- Outcome: The client can request quarantine or rejection of failing mail after legitimate senders are fixed.
Technical explanation
- SPF: The connecting IP must be authorized by the RFC5321.MailFrom domain.
- DKIM: The DKIM signature must verify for the d= signing domain.
- DMARC: SPF or DKIM must pass with a domain that has alignment with the RFC5322.From domain.
- Policy: The MSP can stage the domain through monitoring, quarantine, then reject when reports support it.
That split matters in MSP service delivery. The client sponsor approves the risk reduction work. The technical contact helps fix DNS and vendor settings. If both groups hear the same level of detail, one group gets too little context and the other gets buried in terms they do not need.
Use alignment findings to define the work in an MSP DMARC service: identify the sending system, show the domain mismatch, and assign the fix.
Show how a message passes DMARC
A useful client diagram starts with the visible From address, then shows SPF and DKIM as two separate paths. DMARC does not require both to pass. It requires at least one passing result with an authenticated domain that has alignment with the visible From domain. That detail prevents a common client misunderstanding: a message can fail SPF and still pass DMARC if DKIM passes with alignment.
The easiest way to explain this in a QBR or onboarding call is to use one sample message, then walk through the headers with the client-facing language first. Start with the sender the recipient sees, ask which system sent the email, then check whether that system authenticated as the client's domain or another domain.
DMARC alignment flowchart for MSP clients, tracing the visible From domain through SPF or DKIM to policy handling.
|
|
|
|
|---|---|---|---|
SPF | Allowed sending path | MAIL FROM domain | Vendor Return-Path |
DKIM | Valid domain signature | DKIM d= domain | Vendor signing domain |
DMARC | Alignment decision | Visible From domain | No pass with alignment |
Compact MSP explanation of the three checks
A DMARC pass validates authorized use of the visible From domain. It does not prove the message is safe, and it does not guarantee inbox placement. Receivers still apply their own reputation and filtering decisions. Enforcement reduces direct spoofing of the protected domain; display name impersonation and lookalike domains need separate controls.
Show records only after the client understands the concept. These examples are illustrative: use the sending service's actual SPF include and complete DKIM public key. The abbreviated DKIM key below is not usable.
Illustrative authentication recordstext
example.com TXT "v=spf1 include:_spf.mailservice.example -all" selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIB..." _dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
A domain check belongs near this point in the workflow. It helps confirm whether the current SPF, DKIM, and DMARC records exist before you open the client task list. Suped's domain health checker keeps the first conversation focused on observable DNS facts.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The result should not become the whole project plan. It tells you what exists in DNS. DMARC aggregate reports show the sources observed by reporting receivers. Their authentication results identify the sources that need remediation.
Use domain examples to prove the pass rule
Use billing@example.com as the visible From address, then compare the MAIL FROM domain and DKIM d= domain. Authentication and alignment are separate decisions: a vendor domain can pass SPF or DKIM for itself while contributing nothing to the DMARC result for example.com. The table assumes both SPF and DKIM pass and example.com is the Organizational Domain.
|
|
|
|
|---|---|---|---|
example.com | example.com | Pass | Both identities pass with alignment |
bounce.vendor.example | example.com | Pass | DKIM passes with alignment; SPF uses a vendor domain |
mail.example.com | signer.vendor.example | Pass with aspf=r; fail with aspf=s | SPF passes and shares the Organizational Domain |
bounce.vendor.example | signer.vendor.example | Fail | Neither passing identity has alignment with example.com |
Worked DMARC alignment examples for client calls
When one message behaves unexpectedly, inspect the recipient provider's trusted Authentication-Results header and each DKIM-Signature. Confirm the SPF result and smtp.mailfrom identity, find each passing DKIM header.d identity, then compare those domains with the visible From domain. One passing DKIM signature with domain alignment is sufficient even if another signature fails.
A pass for another domain is not enough
If a vendor authenticates only as vendor.example, the vendor has proved control of its own domain. The client still needs MAIL FROM alignment or DKIM alignment with example.com to pass DMARC.
Show how to fix third-party sender alignment
When a vendor authenticates only as vendor.example, explain the fix as configuring it to authenticate with a client-controlled domain. DNS records and the vendor's sending settings must agree.
- Enable custom DKIM signing with d=example.com. Publish the exact selector TXT or CNAME records supplied by the vendor, then enable signing in its settings. Publishing a key alone does not sign outgoing mail.
- Configure a custom Return-Path, also called custom MAIL FROM or bounce domain, such as bounces.example.com. Follow the vendor's DNS instructions and verify SPF passes. This subdomain meets relaxed SPF alignment for example.com, but not strict SPF alignment.
- Adding a vendor include to example.com's SPF record does not fix SPF alignment while that service still uses bounce.vendor.example. If custom MAIL FROM is unavailable, client-domain DKIM can provide the DMARC pass.
- Send a fresh message through that service and verify a passing SPF or DKIM result with domain alignment in trusted recipient headers. Use the DKIM signature's s= selector and d= domain to locate its public key at <selector>._domainkey.<signing-domain>, then confirm the fix in subsequent aggregate reports.
Explain relaxed and strict alignment without losing the room
Clients often hear "alignment" and assume every domain string must be identical. DMARC has relaxed and strict modes for SPF and DKIM. Relaxed alignment accepts domains with the same Organizational Domain. Strict alignment requires an exact domain match.
RFC 9989 specifies a DNS Tree Walk to discover the Organizational Domain. Older implementations use a Public Suffix List, so check receiver results when delegated subdomains behave differently. Relaxed alignment is the default: aspf controls SPF and adkim controls DKIM. Each accepts r for relaxed or s for strict. Strict alignment requires an exact domain match for that authentication path.
Relaxed alignment
- SPF: The MAIL FROM domain and From domain can share an Organizational Domain.
- DKIM: The d= signing domain and From domain can share an Organizational Domain.
- Use case: The practical default for client environments with several senders.
Strict alignment
- SPF: The MAIL FROM domain must exactly match the From domain.
- DKIM: The d= signing domain must exactly match the From domain.
- Use case: An option after sender inventory is complete and vendor support is clear.
Strict alignment DMARC optionstext
_dmarc.example.com TXT "v=DMARC1; p=quarantine; adkim=s; aspf=s; rua=mailto:dmarc@example.com"
Avoid making strict alignment the first milestone
An unrelated vendor bounce domain fails SPF alignment in both modes. A custom bounce subdomain such as bounces.example.com matches example.com only under relaxed SPF alignment. Strict DKIM alignment requires the client's exact From domain as d=. Inventory legitimate senders before changing these settings. Review strict alignment when third parties control subdomain SPF or DKIM records, because relaxed alignment can let those subdomains authenticate mail for a parent domain.
Handle the failures clients actually have
In MSP environments, alignment issues usually come from operational sprawl, not one bad DNS record. The client has a primary mail platform plus several business systems that send email. Some of those systems were added without a central authentication review.
Publishing a DMARC record with a working rua destination requests aggregate reports; p=none alone does not request them. Reports cover participating receivers, so confirm the sender inventory with the client. The service work covers sender identification, authentication fixes, enforcement readiness, and ongoing verification.
- Unapproved SaaS: A department sends as the client domain through a platform IT never configured.
- Shared mailers: A vendor authenticates with its own domain, so SPF or DKIM can pass while DMARC fails for the client domain.
- SPF limits: SPF allows at most 10 evaluated DNS-querying terms, including nested includes. Exceeding that limit produces permerror.
- Forwarding: Forwarding often breaks SPF. DKIM can preserve a DMARC pass if signed content remains intact, but mailing list footers or subject changes can also break DKIM.
- Subdomains: Campaign systems use subdomains that need planned policy and reporting coverage.
SPF problems deserve special handling because they are common and easy to make worse. Adding another include looks harmless until the record crosses the lookup limit. For MSPs managing many clients, Suped's Hosted SPF can reduce DNS access friction and keep approved sender changes controlled. It does not give a vendor Return-Path domain alignment or authorize an unknown sender.
Policy stages clients can understand
Use these stages to explain why enforcement follows sender fixes.
Monitoring
p=none
Collect reports and identify legitimate sending sources.
Quarantine enforcement
p=quarantine
Ask receivers to treat DMARC-failing mail as suspicious, often by placing it in spam.
Reject enforcement
p=reject
Ask receivers to reject DMARC-failing mail after legitimate senders are fixed.
The pct tag is historic under RFC 9989, so do not rely on percentage-based enforcement. Receivers retain final control over message handling. Stage rollout by fixing senders and observing report data before changing the published policy.
This framing helps the client see DMARC as a managed control rather than a one-time switch. It also gives the MSP a clean way to define scope across inventory, remediation, reporting, policy staging, and post-enforcement monitoring.
Turn the explanation into an MSP workflow
A good client explanation should end in clear next actions. The client does not need a lecture on every authentication header. They need to know which senders are authorized, which ones need DNS work, and when the domain can move to a stronger DMARC policy.
Suped's product supports this MSP workflow by bringing DMARC analysis, SPF and DKIM checks, blocklist (blacklist) monitoring, and deliverability signals into one place. For day-to-day delivery, DMARC monitoring is the working layer: it turns aggregate reports into sender lists, authentication results, and issues your team can resolve.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Use the dashboard to show each vendor's sending source and authenticated domain alongside its DMARC pass rate. Record the fix and who owns it so the client has a concrete next action.
- Baseline: Add the domain, verify the DMARC record and report delivery, and observe a normal business cycle. Confirm infrequent senders such as monthly invoices with the client.
- Classify: Separate approved platforms, unknown sources, forwarding traffic, and obvious abuse.
- Remediate: Fix SPF, enable DKIM with domain alignment, change vendor sender settings, or stop unauthorized systems.
- Stage: Move policy through monitoring, quarantine, then reject when report data supports the change.
- Report: Report DMARC pass rates for approved senders separately from unauthorized traffic, alongside policy status and open client tasks.
When DNS access is slow or clients have many domains, Suped's Hosted DMARC lets the MSP manage policy after the initial DNS delegation. Receivers pick up policy changes as cached DNS answers expire.
Client reporting language
A client status report can say: "We found 12 services sending for your domain. Nine now pass DMARC, two need vendor changes, and one source was confirmed unauthorized. We will hold at monitoring until the vendor fixes are confirmed."
That style also makes client progress reports more useful. The client sees what changed, what risk remains, and what approval or vendor access the MSP needs next.
Answer the hard client questions plainly
The client questions that slow projects are usually about disruption. Clients want to know whether legitimate mail will be blocked, why the MSP cannot enable reject immediately, and why a vendor that reports an SPF or DKIM pass still fails DMARC.
Answer with operational facts. If a service signs with the vendor's domain, explain that the signature can pass DKIM but lack alignment with the client's From domain. If forwarding breaks SPF, explain that a surviving DKIM signature with domain alignment is the more reliable pass path for that flow.
|
|
|
|---|---|---|
Why not reject now? | Wanted mail still needs an authentication pass with domain alignment. | Finish inventory |
Why did SPF pass but DMARC fail? | SPF passed for a domain without alignment, and DKIM supplied no pass with alignment. | Configure custom MAIL FROM or client-domain DKIM |
Why is DKIM missing or failing? | Signing is absent or the signature cannot be verified. | Check signing, selector, DNS key, and message changes |
Who owns the fix? | Ownership depends on the sending system. | Assign vendor or client task |
Plain answers for common stakeholder questions
For less technical stakeholders, keep the detail even tighter. The companion nontechnical DMARC explanation works well when the audience cares about risk and ownership more than headers.
Do not promise zero disruption
The honest promise is controlled rollout, not zero risk. DMARC enforcement changes the handling preference receivers see for failing mail. A disciplined MSP process reduces disruption by collecting reports, fixing legitimate senders, staging policy, and keeping rollback steps clear.
Use a simple script during client calls
A short script keeps the first call consistent across account managers and engineers. It also stops the conversation from drifting into DNS syntax before the client understands the business reason for the work.
MSP call scripttext
Your domain is the identity customers see in the From address. SPF checks whether the sending path is allowed for the envelope domain. DKIM checks whether the message has a valid domain signature. DMARC passes when SPF or DKIM passes and the authenticated domain meets your visible From domain's alignment rules. We will monitor first, identify every legitimate sender, fix the gaps, then move the policy toward rejecting messages that fail DMARC.
The script works because it names the checks, ties them to the visible domain, and sets expectations about the rollout. It also makes the MSP's value clear: the client is not buying a TXT record. The service covers sender discovery, authentication repair, policy management, and ongoing monitoring.
Frequently asked questions
DMARC alignment means the domain that passes SPF or DKIM must match the visible From domain under the selected relaxed or strict alignment mode.
No. SPF or DKIM must pass with domain alignment. Configure both for resilience. Gmail requires bulk senders sending more than 5,000 messages daily to personal Gmail accounts to set up both, even though only one needs domain alignment.
SPF authenticates the MAIL FROM domain, which can differ from the visible From domain. If those domains lack alignment, SPF cannot provide the DMARC pass. DMARC fails only if DKIM also supplies no passing signature with domain alignment.
Start with monitoring, confirm legitimate senders, and fix authentication gaps before publishing quarantine or reject. The right point to enforce depends on report evidence, not a fixed waiting period.
Say DKIM is a digital signature added to email. A receiver verifies it with the public key in DNS to check the signing domain and confirm that signed content was not changed after signing. DKIM does not encrypt the email or identify the individual who wrote it.
No. A DMARC pass validates authorized use of the visible From domain. Receivers still use reputation, content checks, and local policy when deciding where to place the message.
