Why does my email header show DKIM and SPF as none, and how do I fix Outlook deliverability issues?
Published 19 Apr 2025
Updated 21 Oct 2026
13 min read
Summarize with
Updated on 21 Oct 2026: We clarified SPF and DKIM none results and added Outlook bounce-code diagnostics.
At the receiving server, dkim=none usually means no DKIM signature was found, while spf=none means no SPF record was found for the checked SMTP identity or no usable domain was available. Internal Microsoft 365 headers can also show none. These results differ from fail; confirm the receiver-owned result before changing DNS.
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. Start with Suped's live email tester because DNS checks alone can say pass while the real message path still fails.
- A none result is a clue, not a final verdict. Read the receiver-owned result before changing DNS.
- Microsoft 365 can omit DKIM signatures for messages sent within the same organization; test external mail separately.
- A final none result indicates missing authentication information. A fail result indicates that authentication was attempted and did not pass.
- Configure custom-domain DKIM, SPF and DMARC first, then investigate Outlook filtering if authentication passes.
What SPF and DKIM none mean in headers
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 passing DNS check confirms the published configuration, not what happened to a particular message. It does not prove that your outbound system signed the actual message, preserved the body after signing, used an aligned domain for DMARC, or sent through an IP authorized by the envelope sender's SPF policy. Use Microsoft's authentication troubleshooting reference to distinguish missing authentication from verification and DNS errors.
|
|
|
|---|---|---|
dkim=none | No DKIM signature was found by this verifier. | Find the signing system. |
spf=none | No SPF record was found, or no usable SMTP domain was available. | Identify smtp.mailfrom or the HELO identity before checking DNS. |
dkim=fail | A DKIM signature was present but did not verify. | Check the selector key and changes to signed content. |
spf=fail | The policy explicitly did not authorize the connecting IP. | Compare the actual IP with the envelope domain's SPF policy. |
spf=permerror | SPF has a permanent configuration error. | Check duplicate SPF records, syntax and the lookup limit. |
spf=temperror | A temporary error prevented SPF evaluation. | Investigate DNS availability and retry after recovery. |
dkim=pass | The DKIM signature verified. | Check domain alignment. |
spf=pass | The sending IP was authorized. | Check From alignment. |
dmarc=pass | Aligned SPF or DKIM passed. | Check provider requirements, then investigate filtering. |
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.
- Use the authserv-id to identify the system that wrote each result.
- Pair the result with its Received hop because newer headers are normally added above older ones.
- Check the receiver-owned DMARC result for the From domain, then confirm whether the provider also requires both SPF and DKIM to pass.
Why tests pass while Outlook shows none
Why DNS authentication checks pass while Outlook headers show SPF or DKIM as none.
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.
This happens when Microsoft 365 signs with its default tenant domain instead of the custom From domain, or another sending app does not add DKIM. A gateway changing signed content usually produces dkim=fail rather than none. Microsoft also omits DKIM signatures for mail within the same organization, so test an external recipient before diagnosing broken signing. Microsoft's DKIM documentation describes this internal-mail exception.
A passing DNS test
- The DKIM public key is visible in DNS.
- The SPF syntax is valid and returns a result.
- The DMARC TXT record is published and has valid syntax.
A real Outlook message
- The outbound app did not add a DKIM signature.
- A relay or gateway changed the envelope or signed content.
- Outlook judges the message it received, not the DNS record alone.
Illustrative header order, newest receiver result firsttext
Authentication-Results: outlook.com; dkim=pass header.d=example.com; spf=pass smtp.mailfrom=bounce.example.com; dmarc=pass header.from=example.com Authentication-Results: internal.example.net; dkim=none (message not signed); spf=none smtp.mailfrom=example.com
How to read Outlook authentication headers
Open the raw message source, not the short header preview. Search for Authentication-Results, identify the authserv-id when present, and match the result to trusted Received hops. For an Outlook.com test, use the final Microsoft consumer service result. For a Microsoft 365 tenant, use the result written at the tenant boundary. Header position and a familiar authserv-id alone do not prove trust, because senders can forge these fields. RFC 8601 explains the receiving system's trust boundary.
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.
- Use the same app, From address, template, attachments, and relay path.
- Copy the full raw headers, not only the visible Outlook summary.
- Use authserv-id and Received headers to identify the receiver-owned result.
- Check whether DKIM d= or the SPF return-path domain meets DMARC's alignment rules for the visible From domain.
- Read d= and s= in DKIM-Signature, then check s._domainkey.d using those actual values. Do not assume every sender uses selector1.
- Run a domain health check after you know which system sent the message.
- Use DMARC monitoring to find repeat failures by source.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
A good test result shows DKIM pass with a signing domain aligned to the From address, SPF pass with an aligned return-path domain, or both. DMARC needs at least one aligned pass, while Outlook.com's bulk sender requirements need both SPF and DKIM to pass.
SPF checks the SMTP envelope sender, usually recorded in smtp.mailfrom and Return-Path, rather than the visible From address. With an empty reverse-path, SPF uses the HELO domain. RFC 7208 defines these identity rules.
Illustrative Microsoft 365 DNS recordstext
Host: selector1._domainkey Type: CNAME Value: <Selector1CNAME from Microsoft 365> Host: selector2._domainkey Type: CNAME Value: <Selector2CNAME from Microsoft 365> example.com. TXT "v=spf1 include:spf.protection.outlook.com -all" _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
The SPF example assumes Microsoft 365 is the only sender using that envelope domain. Edit the existing SPF record to include your actual sending sources. Replace the example reporting address with a working mailbox or the destination assigned by Suped. p=none requests monitoring without asking receivers to quarantine or reject DMARC failures.
How forwarding and ARC change the result
Forwarding changes the server that connects to the final receiver, so SPF often fails at the new hop. DKIM can survive forwarding when signed headers and the body stay unchanged. It fails when a mailing list, security gateway, or disclaimer service modifies signed content.
ARC records the authentication result seen before an intermediary changed the message. Microsoft 365 can use that result when an administrator trusts the intermediary's ARC sealing domain. ARC is receiver-side evidence, not a DNS repair the original sender can apply. Microsoft's trusted ARC sealer documentation explains the verification and override fields below.
When the direct message passes but a forwarded copy fails, inspect the latest ARC set before rotating DKIM keys or expanding SPF.
- Check ARC-Seal, ARC-Message-Signature, and ARC-Authentication-Results together.
- In Microsoft 365, arc=pass with oda=1 shows the earlier result came from a trusted sealer.
- compauth=pass reason=130 shows a trusted ARC result overrode a current DMARC failure.
- ARC can preserve authentication context, but it does not bypass Outlook spam filtering.
Fixes for Microsoft 365 and Outlook delivery
Microsoft Defender DKIM settings showing custom-domain signing and both selector CNAME records.
For Microsoft 365, publishing DKIM CNAMEs is only part of the fix. You also need DKIM enabled for the custom domain in the Defender portal. If the custom From domain is example.com, the DKIM d= domain must meet DMARC's alignment rules to authenticate the From domain. Strict alignment requires an exact domain match; relaxed alignment permits domains with the same organizational domain. A tenant onmicrosoft.com signature does not provide DKIM alignment for example.com.
Copy both selector targets exactly as Microsoft 365 displays them. New custom domains can use Microsoft's newer dkim.mail.microsoft target format, while existing domains can retain the older onmicrosoft.com target format. Do not build CNAME targets by copying a generic example. Allow DNS caches to expire, confirm Microsoft detects both CNAMEs, and send a new external test message after enabling signing.
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.
- Enable signing for the real From domain, not only the tenant domain.
- Publish both selector CNAMEs exactly as Microsoft provides them.
- Authorize the actual sending IPs for each envelope-sender domain and stay within SPF's limit of 10 DNS-querying terms, including nested evaluations.
- For a new DMARC setup, start at p=none and review reports before enforcement. Keep an existing enforcement policy when repairing one sending source.
- Stop gateways and disclaimers from modifying signed content after DKIM.
- Fix the app that sent the failing mail, not the app that passed a test.
Publish only one TXT record beginning v=spf1 at each checked hostname. Multiple SPF records produce permerror. SPF's lookup limit counts evaluated DNS-querying terms, including nested include and redirect evaluations, rather than DNS packets. A long SPF record can contain multiple quoted strings inside one TXT record; the 255-octet limit applies per string, not to the whole SPF record. RFC 7208 defines these limits.
For high-volume senders, Outlook.com requires both SPF and DKIM to pass, a valid DMARC policy of at least p=none, and a DMARC pass through at least one aligned method. The threshold is 5,000 or more messages per day to Microsoft consumer email services using the same 5322.From domain. Enforcement began on May 5, 2025, and non-compliant messages can be rejected with 550 5.7.515. Read the Microsoft guidance for Outlook.com, Hotmail and related consumer services. This requirement is separate from a recipient organization's Microsoft 365 tenant policies.
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 DMARC reporting product groups aggregate reports by sending source so you can identify recurring authentication failures. Fix DNS or signing in the responsible system, then compare later reports and test a new message at Outlook to confirm the result.
Use bounce codes and sending logs to diagnose rejection
If Outlook rejects a message before delivery, there is no recipient inbox header to inspect. Save the non-delivery report (NDR), including the rejecting server and complete SMTP response. Check whether the recipient uses Outlook.com consumer mail or a Microsoft 365 tenant. The Outlook desktop or mobile app does not determine the receiving service's policy.
|
|
|
|---|---|---|
550 5.7.515 | Outlook.com rejected the sending domain's authentication level. | Verify both SPF and DKIM pass, with a valid DMARC policy and at least one aligned pass. |
535 5.7.3 | The application failed SMTP submission authentication. | Check the SMTP endpoint, OAuth configuration and permitted submission settings. |
550 5.7.1 | An authorization or policy rejection; the complete text identifies the cause. | Investigate the stated relay permissions, connector configuration or recipient policy. |
4.x.x / 5.x.x | Temporary deferral / permanent failure. | Allow queued retries for temporary failures; correct a permanent failure before resending. |
Match the exact SMTP response to the failing stage.
Microsoft's NDR reference explains status codes, while its 550 5.7.515 guidance covers consumer-domain authentication requirements. SMTP sign-in failures occur before SPF and DKIM checks at the destination.
Search the sending system's logs using the recipient, message ID and send time. For Microsoft 365 mail, an administrator can use Exchange Online message trace to check the delivery events. A Delivered status does not prove inbox placement; inspect the event details, as Microsoft's message trace FAQ explains.
Outlook issues after authentication passes
SPF, DKIM, and DMARC passing does not guarantee inbox placement. Outlook also considers sender reputation and recipient feedback. Recipient organization policies and unsafe URLs can cause filtering even when authentication passes. Authentication makes the identity verifiable; placement still depends on the sending record and message.
When a test reports an Outlook problem while the final headers pass, investigate filtering separately from authentication. Check whether the message was rejected, quarantined or delivered to Junk before changing DNS.
Authentication failure
- The receiver shows DMARC failure, or SPF or DKIM does not meet a provider requirement.
- Repair signing, SPF includes, return-path, or custom-domain setup.
- New messages show the required SPF and DKIM passes, plus DMARC pass.
Filtering after authentication
- Authentication passes, but Outlook junking or rejection continues.
- Reduce complaints, clean lists, improve cadence, and check reputation.
- Inbox tests improve without changing the authentication result.
Blocklist checker
Check your domain or IP against 144 blocklists.
Blocklist (blacklist) checks help investigate poor placement across authenticated mail. A listed IP or domain is a reason to review sending history and shared infrastructure. A clean public blocklist result does not prove Microsoft trusts the sender, because Microsoft also uses its own reputation data.
|
|
|
|---|---|---|
Complaints | Recent complaint spikes | Tighten consent |
Reputation | IP and domain history | Stabilize volume |
List quality | Old or scraped contacts | Remove unconsented contacts and suppress hard bounces. |
Content | URLs and redirects | Clean templates |
Outlook troubleshooting order after authentication passes.
For Microsoft 365 recipients, ask the recipient administrator to inspect the receiver-owned X-Forefront-Antispam-Report header when available. Its SCL and SFV fields describe spam scoring and filtering decisions. Microsoft's anti-spam header documentation explains these fields; also check quarantine and recipient rules.
Avoid changes that hide authentication failures
Do not use artificial 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. Legitimate, gradual increases in opted-in sending volume are a separate reputation practice.
- Headers tell you which authentication check was run and by which system.
- Changing SPF, DKIM, and DMARC at once makes root cause analysis harder.
- Fix consent and list quality alongside sender authentication. Increase legitimate sending volume gradually after the technical checks pass.
