Why does my email header show DKIM and SPF as none, and how do I fix Outlook deliverability issues?
Matthew Whittaker
Co-founder & CTO, Suped
Published 19 Apr 2025
Updated 5 Jun 2026
8 min read
Summarize with
If a header shows dkim=none or spf=none, the receiving system either did not evaluate that method at that point in the route, did not see a DKIM signature, could not check the envelope sender for SPF, or added an internal header before the final authentication verdict. It is normal only when the final receiver header later shows SPF, DKIM, or DMARC passing for the visible From domain.
The fastest fix is to test a real message, inspect the final Authentication-Results header, then repair the sending system that actually produced the failing or unsigned message. I start with a live email tester because DNS checks alone can say pass while the real message path still fails.
- Direct answer: A none result is a clue, not a final verdict. Read the final receiver verdict before changing DNS.
- Normal case: Microsoft 365 and Outlook can add internal headers while mail moves between systems.
- Broken case: A final result of none or fail means the message was unsigned, unmatched, relayed, or altered.
- Outlook fix: Fix custom-domain DKIM, SPF, DMARC, sender reputation, complaint rate, and blocklist or blacklist status.
What none means in a mail header
Authentication headers are added by different systems as a message moves. The line that matters most is the one added by the server that accepted the message for the mailbox you are testing. In Outlook.com, Hotmail, and Microsoft consumer inboxes, that header can sit near the top of the raw message, while older internal results sit below it.
A DNS checker only proves that a TXT or CNAME record exists and has valid syntax. It does not prove that your outbound system signed the actual message, preserved the body after signing, used the same domain as the visible From address, or sent through the IPs listed in SPF.
|
|
|
|---|---|---|
dkim=none | No DKIM signature was evaluated. | Find the signing system. |
spf=none | No SPF record or envelope identity was checked. | Check return-path. |
dkim=pass | The DKIM signature verified. | Check domain match. |
spf=pass | The sending IP was allowed. | Check From match. |
dmarc=pass | SPF or DKIM passed with the From domain. | Move to placement. |
Common header outcomes and what they mean.
A Microsoft 365 message can contain several Authentication-Results lines. Do not treat the first none result you find as the final answer.
- Auth server: Prefer the result added by the receiving mailbox provider.
- Header order: Newer hops are normally added above older hops in the raw message.
- Final verdict: DMARC pass for the From domain matters more than an internal none line.
Why tests pass while Outlook shows none
Four-part view of DNS checks, signed mail, internal hops, and final authentication verdict.
The mismatch usually comes down to scope. A DKIM checker tests a selector record. An SPF checker tests whether a record can authorize an IP. A mailbox header records what happened to one specific message after it left the sender. Those are related checks, but they are not the same check.
I see this most often with Microsoft 365 tenants that enabled DKIM for the default tenant domain but not for the custom From domain, with mail sent by a CRM or billing app that never signed with the brand domain, or with a security gateway adding a footer after DKIM signing. A Microsoft Answers case describes the same pattern: online tests looked correct, while real headers still showed DKIM as none or unsigned.
A passing DNS test
- Selector exists: The DKIM public key is visible in DNS.
- SPF parses: The SPF syntax is valid and returns a result.
- DMARC exists: The policy record can receive reports.
A real Outlook message
- Signer missing: The outbound app did not add a DKIM signature.
- Route changed: A relay or gateway changed the envelope or body.
- Provider verdict: Outlook judges the message it received, not the DNS record alone.
Example of mixed authentication headerstext
Authentication-Results: internal.example.net; dkim=none (message not signed); spf=none smtp.mailfrom=example.com Authentication-Results: outlook.com; dkim=pass header.d=example.com; spf=pass smtp.mailfrom=bounce.example.com; dmarc=pass header.from=example.com
How to check the right header
Open the raw message source, not the short header preview. Search for Authentication-Results and identify the result added by the mailbox provider you are testing. If you are checking Outlook, the final Microsoft result matters. If you are checking Gmail, the final Google result matters.
Then test the same sending path the recipient sees. Do not send from a personal mailbox if the problem message comes from a ticketing system. Do not test Microsoft 365 if the real campaign goes through a marketing platform. The signature and SPF path have to match the real source.
- Send real mail: Use the same app, From address, template, attachments, and relay path.
- Open source: Copy the full raw headers, not only the visible Outlook summary.
- Find verdict: Read the provider-owned authentication result nearest the final delivery hop.
- Compare domains: Check whether DKIM d= or SPF return-path matches the visible From domain.
- Check DNS: Run a domain health check after you know which system sent the message.
- Monitor reports: Use DMARC monitoring to find repeat failures by source.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
A good test result should show either DKIM pass with the same organizational domain as the From address, SPF pass with a matching return-path domain, or both. DMARC passes when at least one of those authenticated identities matches the visible sender domain.
Basic DNS records to verifytext
Host: selector1._domainkey Type: CNAME Value: selector1-example-com._domainkey.example.onmicrosoft.com Host: selector2._domainkey Type: CNAME Value: selector2-example-com._domainkey.example.onmicrosoft.com example.com. TXT "v=spf1 include:spf.protection.outlook.com -all" _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
Fixes for Microsoft 365 and Outlook delivery
Microsoft Defender portal DKIM settings for a custom domain.
For Microsoft 365, the usual fix is not only publishing DKIM CNAMEs. You also need DKIM enabled for the custom domain in the Defender portal. If the custom domain is example.com, Outlook should see a DKIM signature with d=example.com or another domain that passes DMARC for that From domain.
If another system sends mail using your domain, configure DKIM in that system too. This includes support desks, CRMs, billing platforms, product notifications, calendar systems, and marketing senders. Microsoft 365 cannot sign a message that never passes through it.
- Custom DKIM: Enable signing for the real From domain, not only the tenant domain.
- Two selectors: Publish both selector CNAMEs exactly as Microsoft provides them.
- SPF source: Include every legitimate outbound service and keep under the 10 lookup limit.
- DMARC policy: Start at p=none, review reports, then move toward enforcement.
- Body changes: Stop gateways and disclaimers from modifying signed content after DKIM.
- Real source: Fix the app that sent the failing mail, not the app that passed a test.
For high-volume senders, Microsoft says Outlook.com requires SPF, DKIM, and DMARC for domains sending more than 5,000 messages per day. Microsoft also states that enforcement began on May 5, 2025, with non-compliant messages rejected using 550 5.7.515. Read the Microsoft guidance if you send at that scale.
For a Microsoft 365-specific walkthrough, use Office 365 troubleshooting after you confirm whether the failing mail actually came through Microsoft 365.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped's product is useful at this point because it groups DMARC, SPF, DKIM, hosted SPF, hosted DMARC, blocklist monitoring, and deliverability signals into one workflow. The practical value is not another pass or fail badge. It is knowing which source broke, what DNS change is needed, and when the fix has actually changed live mail.
Outlook issues after authentication passes
SPF, DKIM, and DMARC passing does not guarantee inbox placement. Outlook also filters using sender reputation, complaint history, engagement patterns, message consistency, URL reputation, IP reputation, and blocklist or blacklist data. Authentication gets you eligible for trust. It does not earn that trust by itself.
When a test says Outlook is failing while headers pass, separate the problem into two buckets: authentication failure and placement failure. Mixing those buckets causes wasted DNS changes and hides the real delivery issue.
Authentication failure
- Header result: Final DKIM, SPF, or DMARC says none or fail.
- Main fix: Repair signing, SPF includes, return-path, or custom-domain setup.
- Proof: New live messages show pass for the From domain.
Placement failure
- Header result: Authentication passes, but Outlook junking or rejection continues.
- Main fix: Reduce complaints, clean lists, improve cadence, and check reputation.
- Proof: Inbox tests improve without changing the authentication result.
Blocklist checker
Check your domain or IP against 144 blocklists.
Spamhaus
0Spam
Cisco
NoSolicitado
URIBL
abuse.ro
ALPHANET
Anonmails
Ascams
BLOCKEDSERVERS
Calivent Networks
EFnet
JustSpam
Kempt.net
NordSpam
RV-SOFT Technology
Scientific Spam
Spamikaze
SpamRATS
SPFBL
Suomispam
System 5 Hosting
Team Cymru
Validity
www.blocklist.de Fail2Ban-Reporting Service
ZapBL
2stepback.dk
Fayntic Services
ORB UK
technoirc.org
TechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftBlocklist and blacklist checks matter when Outlook placement is poor across otherwise authenticated mail. A listed IP or domain is not always the full cause, but it is a signal to investigate sending history, shared infrastructure, complaint sources, and compromised accounts.
|
|
|
|---|---|---|
Complaints | Recent complaint spikes | Tighten consent |
Reputation | IP and domain history | Stabilize volume |
List quality | Old or scraped contacts | Suppress risk |
Content | URLs and redirects | Clean templates |
Outlook troubleshooting order after authentication passes.
What not to do
Do not use warming traffic to fix a header that says none. It does not sign mail, repair SPF, publish DKIM keys, improve DMARC results, or explain why Outlook is filtering a real message. It can also add artificial engagement patterns that create more deliverability risk.
- Do not guess: Headers tell you which authentication check was run and by which system.
- Do not over-edit: Changing SPF, DKIM, and DMARC at once makes root cause analysis harder.
- Do not warm: Fix consent, list quality, sending identity, and message authentication first.
For most teams, Suped is the strongest practical DMARC platform for this workflow because it connects issue detection, real-time alerts, hosted SPF, SPF flattening, hosted DMARC, hosted MTA-STS, blocklist monitoring, and multi-domain reporting. That makes the work less about reading raw XML and more about resolving the exact source that is failing.
Views from the trenches
Best practices
Check the final receiver header before changing DNS or rotating keys in production mail.
Enable DKIM on the custom From domain, then verify same-domain DMARC matching properly.
Use real inbox tests with raw headers, not summaries that hide intermediate hops fully.
Common pitfalls
Reading the first Authentication-Results line and missing the final verdict near the top.
Assuming a DNS checker pass means every outbound system signs each real message.
Using warming traffic to mask sender reputation problems instead of fixing causes.
Expert tips
Keep Microsoft 365 DKIM selectors live, and rotate keys only after DNS resolves cleanly.
Separate authentication failures from Outlook placement before changing content or volume.
Track blocklist and blacklist status beside DMARC reports for faster triage each week.
Expert from Email Geeks says DKIM and DMARC should be configured on the sending domain before judging an inbox placement test.
2024-04-11 - Email Geeks
Marketer from Email Geeks says a none result can appear when Microsoft moves mail internally, while later results still show pass.
2024-04-11 - Email Geeks
The practical fix
Treat DKIM and SPF none as a routing and evidence problem first. Read the final authentication result, confirm which system sent the real message, and fix that source. If the final result passes, stop changing DNS and move to Outlook placement signals such as reputation, complaints, content, cadence, and blocklist or blacklist status.
The durable fix is simple in order: sign every legitimate source with DKIM, authorize every legitimate SPF source without exceeding lookup limits, publish DMARC, monitor reports, and keep Outlook-specific delivery tests separate from authentication tests. Suped's product helps operationalize that order across one domain or many client domains without relying on guesswork.
