What Each Authentication Mechanism Actually Checks
SPF, DKIM and DMARC work together, but they answer different questions. Troubleshooting becomes much easier once those identities are separated.
Was this server authorised?
The receiving system checks whether the connecting server is authorised by the envelope sender domain's SPF policy. It does not authenticate the visible From address by itself.
Key identity: MAIL FROM / return pathDoes this signature verify?
The receiver retrieves a public key using the selector and signing domain, then verifies the signed headers and body. A valid signature identifies the signing domain, not automatically the visible author.
Key identity: d= signing domainDoes a passing identity align?
DMARC compares a successful SPF or DKIM domain with the visible From domain. At least one path must both pass and align for the message to pass DMARC.
Key identity: visible From domainSPF, DKIM and DMARC Result Matrix
Use the receiving system's results from an affected message. Public DNS checks can confirm records, but only a delivered or rejected message shows which identities were actually evaluated.
| SPF result | DKIM result | DMARC result | What it usually means |
|---|---|---|---|
| Pass + aligned | Fail | Pass | Aligned SPF is enough for DMARC. Repair DKIM for resilience, but do not misreport this as a DMARC failure. |
| Fail | Pass + aligned | Pass | Aligned DKIM is enough for DMARC. This pattern is common after forwarding when the signature survives. |
| Pass, unaligned | Fail | Fail | SPF authorised the return path, but that domain does not align with the visible From domain. |
| Fail | Pass, unaligned | Fail | The signature verifies, but its d= domain does not align with the visible From domain. |
| Pass + aligned | Pass + aligned | Pass | Authentication is healthy. If the mail still reaches spam, investigate reputation, audience, volume, content and provider-specific evidence. |
| Permerror | Any | Depends | The SPF policy cannot be evaluated correctly, often because of record structure, multiple policies, syntax or excessive DNS-dependent terms. Aligned DKIM may still let DMARC pass. |
Authentication passes but reputation remains weak? Follow the recovery plan →
Read the Authentication-Results Header
Open the original message or raw source and find the authentication results added by the receiving system. The exact format varies, but you are looking for the result and the domain attached to each mechanism.
In this simplified example, the SPF domain differs from the visible From domain, but DKIM signs with an aligned domain. DMARC can therefore pass through DKIM. If `header.d` were unrelated and SPF remained unaligned, both underlying mechanisms could produce technically valid results without satisfying DMARC.
10 Common Authentication Failures
Multiple SPF policies
Publishing more than one matching `v=spf1` policy can make SPF evaluation invalid. Merge authorised sources into one carefully reviewed record.
Too many DNS-dependent terms
Long include chains can exceed SPF's processing limits. Count the mechanisms and redirects that trigger DNS work rather than counting text length alone.
A sender was added but not authorised
A CRM, form tool, ticketing system or transactional service may use a return path not covered by the domain's current policy.
The wrong selector is checked
Selectors are platform-specific and can rotate. Read the `s=` value on the failing message before looking up a key in DNS.
The public key is missing or stale
The platform signs with a selector whose DNS key was never published, was removed early or no longer matches the active private key.
The message changes after signing
Gateways, footers, mailing lists or security systems can alter signed content. Whether verification survives depends on what was signed and how it changed.
SPF passes for an unaligned return path
The platform's bounce domain is authorised, but its organisational domain does not match the visible From domain under the selected alignment mode.
DKIM signs with the provider's domain
The signature can verify while its d= domain belongs to the platform. Configure custom DKIM signing when the service supports it.
Forwarding breaks the SPF path
The forwarder becomes the connecting server but is not authorised by the original envelope domain. Surviving aligned DKIM can preserve DMARC.
Records were changed without a sender map
Removing a legacy include or selector may look tidy while silently breaking an invoicing, support or automation system that still sends.
Troubleshooting Multiple Email Platforms on One Domain
Most business domains have more senders than their owners expect: Google Workspace or Microsoft 365, a CRM, website forms, invoicing, helpdesk, newsletters, transactional applications and automation tools. Each can use different envelope and DKIM identities.
- Inventory every mail stream. Record the visible From domain, return path, DKIM signing domain, selector, platform owner and mail purpose.
- Collect one current sample from each platform. A DNS record alone does not prove the system is using the identity you intended.
- Separate authorisation from alignment. Note whether SPF and DKIM pass, then independently compare their domains with the visible From domain.
- Identify shared dependencies. One SPF include, CNAME selector, tracking domain or gateway change can affect several mail streams.
- Plan the safest correction order. Preserve working mail, add or verify the replacement, test it, then retire stale configuration.
A Safe Authentication Troubleshooting Process
- Preserve evidence. Save the failing message source, bounce response, current DNS answers, TTL values and platform configuration before editing anything.
- Confirm the visible From domain. This is the identity DMARC protects and the reference point for alignment.
- Read the receiver's SPF identity. Record the result and `smtp.mailfrom` or equivalent envelope domain.
- Read every DKIM signature. Record each result, d= signing domain and s= selector. A message can have more than one signature.
- Explain the DMARC result. Identify which aligned path passed—or why neither did—before proposing a DNS change.
- Verify authoritative DNS. Check the exact SPF policy, selector key and DMARC record at the correct hostname, including delegated records and CNAMEs.
- Make one approved correction. Avoid simultaneous provider migrations, policy changes and selector rotations unless the change plan requires them.
- Send a new controlled test. Inspect the new receiver results after DNS caching allows. Previously received messages will not be re-evaluated.
Protect business-critical mail
Before enforcing or tightening policy, confirm that every legitimate stream can authenticate and align. Capture the previous state, agree a rollback point and use least-privilege access for any platform or DNS work.
Authentication Fixes to Avoid
- Adding a second SPF record instead of reviewing the existing policy.
- Copying another domain's SPF includes or DKIM selector names.
- Assuming an online DNS check proves a real message aligns.
- Changing DMARC enforcement before mapping legitimate senders.
- Deleting old selectors before confirming no system still signs with them.
- Expecting authentication changes alone to repair sender reputation.
Standards and Provider References
The protocol references are RFC 7208 for SPF, RFC 6376 for DKIM and RFC 7489 for DMARC. Provider-specific requirements can go beyond the protocol basics.
For Gmail recipients, also review Google's current email sender guidelines. Passing authentication is a prerequisite for trustworthy identity, not a guarantee of placement.
When the Records Are Connected to Several Systems
If you cannot change authentication without risking business mail, or results differ across platforms and recipients, use a scoped diagnosis or full audit rather than guessing at production DNS.
SPF, DKIM and DMARC FAQs
Can SPF, DKIM and DMARC all pass while email still goes to spam?
Yes. Authentication establishes and aligns sending identity; it does not guarantee inbox placement. Mailbox providers can still consider domain or IP reputation, complaints, engagement, list quality, volume, content, links and provider-specific filtering.
Why does SPF pass but DMARC fail?
SPF can pass for the envelope sender or return-path domain while DMARC fails because that authenticated domain is not aligned with the domain in the visible From header. Read the authentication results and compare the SPF-authenticated domain with the From domain instead of relying on the word pass alone.
Can a domain have more than one SPF record?
A domain should not publish multiple SPF records that match the SPF version. RFC 7208 says a domain must not have multiple records that cause more than one record to be selected. Combine authorised sources into one valid policy rather than adding a second v=spf1 record.
What causes a DKIM body-hash or signature failure?
Common causes include using the wrong selector, a missing or stale public key, signing with an unexpected domain, message modification after signing, canonicalisation differences, truncation or a broken signing configuration. Compare the selector and signing domain in the DKIM-Signature header with DNS and inspect the receiver's result.
Does DMARC require both SPF and DKIM to pass?
No. DMARC passes when at least one supported authentication path passes and aligns with the visible From domain: aligned SPF or an aligned, verified DKIM signature. Using both correctly provides resilience because forwarding or message modification can affect them differently.
Why can email forwarding break SPF?
SPF evaluates whether the connecting server is authorised for the envelope sender domain. A forwarding server may not be authorised by the original domain, so SPF can fail after forwarding. An aligned DKIM signature may still support DMARC if the signed content survives unchanged.
How long do SPF, DKIM and DMARC DNS changes take?
Visibility depends on DNS TTL values and resolver caching, so there is no single universal delay. Check the authoritative record, allow for caching, then send a new controlled message and inspect the receiving system's authentication results. Old messages do not change after DNS is corrected.
When should I get specialist authentication help?
Specialist help is useful when several platforms send from the domain, SPF evaluation returns permanent errors, DKIM fails intermittently, DMARC alignment differs by platform, forwarding or gateways are involved, or DNS changes risk disrupting business-critical mail.