Why are emails intermittently failing SPF and DKIM authentication with new Microsoft standards?
Updated on 21 Oct 2026: We clarified Microsoft's sender requirements and added checks for alternate sending paths, IPv6, and authentication error types.
SPF and DKIM failures can look intermittent under Microsoft's high-volume sender enforcement. DNS lookup timing, nested SPF includes, forwarding, alternate outbound servers, and changes to signed content can differ between two messages that appear identical at the sender side.
A correct SPF include or a passing DKIM test does not prove that every Microsoft delivery attempt will pass. It proves that one path passed at one point in time. A bounce showing SPF=Fail or Dkim=Fail means Microsoft reported that result for that delivery attempt. For a high-volume sender, both SPF and DKIM must pass, even when DMARC passes through the other method whose authenticated domain matches 5322.From under DMARC rules. Trace the message path, DNS resolution tree, and affected recipients before changing records.
The short answer
When Microsoft rejects a message with 550 5.7.515 and still shows DMARC as passing, inspect the separate SPF and DKIM results. DMARC pass does not override the requirement for both checks to pass.
- SPF: An unauthorized outbound IP or forwarding hop can cause fail. DNS timeouts cause temperror, while exceeding lookup limits causes permerror.
- DKIM: A changed signed body or header can invalidate a signature. A missing selector or key-query timeout requires a different DNS investigation.
- DMARC: A pass means at least one method passed authentication and its domain met DMARC's matching rules for 5322.From. It does not mean both SPF and DKIM passed.
What the Microsoft 5.7.515 bounce means
Microsoft's authentication guidance explains SPF, DKIM, DMARC, ARC, and composite authentication. Error 550 5.7.515 has a narrower scope: it is an Outlook.com rejection for high-volume senders to Microsoft consumer email services. Composite authentication in Microsoft 365 tenant filtering is related receiver logic, but it is not the definition of this bounce.
The pattern has also appeared in a Microsoft Q&A thread where senders reported intermittent SPF or DKIM errors, including temperror and key-query timeout results. These reports do not establish a universal Microsoft defect. Use the full NDR to identify the 5322.From domain and the individual authentication result reported for the rejected attempt.
Microsoft's high-volume rule changes receiver enforcement; it does not introduce new SPF or DKIM record syntax. Its sender requirements announcement set May 5, 2025 as the start of 5.7.515 rejection enforcement. High-volume senders must make both SPF and DKIM pass and pass DMARC through at least one method whose domain meets DMARC's matching rules for 5322.From.
Illustrative Microsoft bounce pattern
550 5.7.515 Access denied sending domain example.com does not meet the required authentication level Spf= Fail , Dkim= Pass , DMARC= Pass
The confusing combination is SPF=Fail, Dkim=Pass, and DMARC=Pass, or the inverse with DKIM failing and SPF passing. Microsoft's 5.7.515 troubleshooting guidance confirms that both authentication checks must pass for covered senders, even when the other method already satisfies DMARC.
|
|
|
|---|---|---|
SPF fail | Connecting IP was not authorized for the evaluated identity | Sending IP and envelope sender domain |
SPF temperror / permerror | Temporary DNS problem / permanent SPF evaluation error | DNS availability, record syntax, and lookup limits |
DKIM fail / timeout | Signature verification failed / key lookup timed out | Exact diagnostic, selector, DNS, and body hash |
DMARC pass | At least one passing method met DMARC's domain rules | Which separate check still failed |
5.7.515 | Consumer high-volume requirements were not met | Full NDR and 5322.From |
Common Microsoft authentication bounce results and the evidence to check.
Which senders the 5.7.515 rule covers
Microsoft's high-volume threshold is 5,000 or more messages per day to Microsoft consumer email services using the same domain in the 5322.From address. The affected destinations include Outlook.com, Hotmail, Live.com, MSN, and related Microsoft consumer mailboxes.
- SPF: Publish one valid SPF record for the 5321.MailFrom domain and make the check pass.
- DKIM: Publish the selector record, sign each message, and make signature verification pass.
- DMARC: Publish a valid policy, with p=none sufficient for this requirement, and pass through SPF or DKIM using a domain that meets DMARC's matching rules.
- Domain match: Compare 5322.From with the SPF-authenticated domain, the DKIM d= domain, or both. Relaxed mode permits the same organizational domain; strict mode requires an exact domain match.
The DMARC specification defines relaxed matching as the default for both methods; aspf=s or adkim=s requires strict matching for the respective method. The visible From address, also called 5322.From or the P2 sender, is distinct from the envelope sender, also called 5321.MailFrom, MAIL FROM, or the P1 sender.
Do not confuse this inbound threshold with Outlook.com's separate sending limits for users. Also do not assume the rule applies only to marketing campaigns. Microsoft evaluates the shared 5322.From domain, so transactional and person-to-person streams using that domain need the same reliable authentication once the domain reaches high-volume status.
Why the same sender passes once and fails later
Start by comparing the conditions at receipt. The visible From address and sending IP can be the same, but DNS responses, forwarding, and DKIM-verifiable content can change. Different Microsoft receiving nodes are a clue to compare, not proof that Microsoft caused the failure.
Sender-side causes
- DNS: An authoritative server can time out while Microsoft resolves an SPF include or DKIM key.
- Limit: One SPF evaluation path can exceed the ten DNS-querying-term limit.
- Sending pool: One outbound server can use an unauthorized IP or omit DKIM signing while the rest pass.
- DKIM: A footer, encoding change, or rewrite of a signed header can invalidate one signed message.
Delivery-path differences
- Ingress path: Record the Microsoft server handling each failed attempt so support can correlate samples.
- Forwarding: A relay before Microsoft changes the connecting IP; mailbox rules after initial receipt do not explain an earlier SMTP rejection.
- Timing: A short DNS outage can affect a small number of messages inside a large send.
- Result: Microsoft reports the authentication outcome it used for each delivery attempt.
If a known forwarding service or gateway changes a message, inspect its ARC chain and the original authentication results it preserved. ARC can help a receiver evaluate legitimate forwarded mail, but receiver trust decisions still apply. ARC does not repair a failing SPF record or DKIM signature.
One or two Microsoft bounces out of thousands, followed by successful delivery to the same contact, is a symptom rather than a diagnosis. Determine whether failures cluster by recipient domain, selector, Return-Path, result type, or time window.
Flowchart showing where SPF or DKIM can fail before Microsoft accepts or rejects a message.
How to prove which cause applies
Do not start by editing DNS. First collect evidence from a failed message and a successful message sent through the same production stream. Send a controlled production-path sample to Suped's email tester to inspect its authentication results and message structure. That test checks delivery to the tester; it does not reproduce Microsoft's receiving decision.
A screenshot that says SPF passed is not enough. Capture the non-delivery report, SMTP code, Microsoft server name, UTC timestamp, sending IP, 5321.MailFrom or Return-Path domain, 5322.From domain, DKIM selector and d= domain, and full headers where available. SMTP-rejected mail has no delivered Microsoft copy to inspect, so keep the sending server's SMTP logs and the original signed message. Use Microsoft's Authentication-Results headers from delivered samples rather than a result added by an unrelated earlier hop.
- Capture the full bounce text, message identifier, and SMTP transaction details, not just the final SPF or DKIM result.
- Compare one failed message with one successful message from the same sending pool, including the actual outbound IP and signing server.
- Classify fail, softfail, neutral, temperror, permerror, none, and timeout results before diagnosing. A temporary authentication error inside a 550 response is still a permanent SMTP rejection.
- Trace SPF through the terms actually evaluated, including nested includes and redirects, and verify the sending IP match and lookup count.
- Check DKIM using the failed message's selector, public key, body hash, signed headers, and d= domain. Header text alone cannot verify the body hash; preserve the complete raw message where available.
- Group failures by recipient domain, result type, sending source, and time of send.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
If every failed message shares one consumer recipient domain or forwarding path, investigate that route and preserve samples for Microsoft support. If failures hit unrelated Microsoft consumer domains at the same time, investigate authoritative DNS reliability, SPF lookup depth, and DKIM selector availability first. If these checks are consistent, escalate with the full NDR and timestamps. A sender's Microsoft 365 message trace does not expose Outlook.com's internal receiving logs; the illustration below shows authentication fields rather than evidence from the affected consumer mailbox.
Illustration of Microsoft Defender for Office 365 authentication results and delivery status.
Check every outbound server and sending subdomain
An incomplete sender inventory can make a stable DNS record produce intermittent failures. A backup relay, application server, or regional sending pool can use a different IP address or DKIM selector. Record an owner for each sending stream and compare the infrastructure used by failed and successful attempts.
- Outbound pools: Test each active and failover server. Confirm every server signs mail and uses a source IP authorized for its envelope sender domain.
- IPv6: Check whether failing attempts use IPv6 while successful attempts use IPv4. An ip4 mechanism does not authorize IPv6; authorize the intended IPv6 source with the appropriate ip6 mechanism or maintained sender configuration.
- SPF mx mechanism: Verify that the sending IP matches an address of an MX host for the evaluated domain. An inbound MX service does not automatically authorize a separate outbound relay.
- Sending subdomains: Query SPF at the actual MAIL FROM domain, such as bounce.example.com. A parent's SPF record is not inherited by a subdomain; configure the subdomain's own SPF record or an explicit delegation using supported SPF mechanisms.
Microsoft's SPF setup guidance covers separate subdomain records and IPv4/IPv6 source authorization. Reproduce the failing route after each correction, then compare bounces across the affected sending pool. Do not add every observed relay to SPF without confirming that it is an authorized sender.
Check SPF beyond the visible include
SPF troubleshooting has to follow the evaluated resolution path. Seeing the sending IP inside one include is only a starting point. Microsoft checks the connecting IP against the envelope sender's SPF policy; terms are processed in order until a match or error ends evaluation. SPF authorizes the sending infrastructure, not the visible From address by itself.
Suped's SPF checker helps inspect record syntax and lookup depth. Pay special attention to third-party includes because their DNS availability and record structure can change outside your control. An ip4 or ip6 match early in evaluation avoids later includes; another sending IP can traverse those includes and encounter an error.
Short SPF example
example.com TXT "v=spf1 ip4:203.0.113.10 include:_spf.example -all"
A correct include is not enough
Microsoft's authentication troubleshooting guidance distinguishes SPF temperror from permerror. An authoritative DNS timeout can produce temperror; exceeding ten evaluated DNS-querying terms or publishing multiple SPF records at the same name produces permerror. Static SPF flattening requires ongoing maintenance because copied IP addresses become stale when a sender changes its infrastructure.
- Lookup: Count evaluated include, a, mx, ptr, exists, and redirect terms, including nested evaluations. The ten-term budget is not a count of every DNS packet.
- Record: Publish one SPF TXT record at the domain used in the 5321.MailFrom address.
- DNS: Check every authoritative nameserver and SPF dependency for consistent answers and availability. Microsoft recommends an SPF TXT TTL of at least 3,600 seconds; increasing the TTL does not repair an unavailable nameserver.
- Vendor: Monitor included senders because their DNS changes can affect your domain.
SPF lookup limits
Protocol limits apply to evaluated terms, including nested includes. A record within the term limit can still fail for other reasons.
Within the term budget
0-10 terms
At most ten DNS-querying terms are permitted per evaluation; ten is valid but leaves no headroom.
Over the term budget
11+ terms
Exceeding ten evaluated DNS-querying terms requires permerror.
Void lookup guidance
2 by default
RFC 7208 recommends a default limit of two empty or nonexistent DNS answers; exceeding the implemented limit produces permerror.
Literal IP mechanisms
0 terms per ip4/ip6
ip4 and ip6 do not consume the DNS-querying-term budget.
The SPF specification defines these evaluation limits and recommends the default void-lookup limit. Count the path used for the failed source, including nested terms, rather than only the includes visible in the top-level record.
Check DKIM when Microsoft says DKIM failed
For DKIM failures, first determine whether Microsoft reports signature failure, body-hash failure, no signature, or a key-query timeout. A production message can fail because a footer, tracking layer, gateway, charset conversion, or header rewrite changed a signed part. A timeout instead points to DNS retrieval of the selector record.
Suped's DKIM checker checks the published selector and public key. It cannot prove that a particular message's signature verifies. Use the failed message's s= selector and d= signing domain to query s._domainkey.d, following any CNAME to the public key TXT record, then verify the complete raw message and compare the signing domain with 5322.From.
DKIM and DMARC DNS examples
s1._domainkey.example.com CNAME s1.example.dkim.example _dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:d@example.com"
- Selector: Make sure the selector in the failed header exists on every authoritative nameserver, including any CNAME target.
- Key: Confirm the public key matches the active signer. Multiple quoted strings within one TXT record are valid; together they must contain one complete key value.
- Body: Look for appended content or tracking rewrites after signing. Sign at the final outbound stage after planned content changes.
- Rotation: Publish the new key before using it and allow cached DNS answers to expire. Keep the old selector available until queued mail signed with it has cleared expected delivery delays.
- Double signing: Where supported, overlapping signatures can help during key rotation. Both signatures can still fail if the same signed content changes after signing.
The DKIM specification evaluates signatures individually. Inspect every signature's result when a message has more than one; a failing secondary signature does not establish that all DKIM verification failed.
Use DMARC reports alongside Microsoft bounce logs
One clean test does not give enough coverage. DMARC monitoring helps identify recurring failures by sending source and reporting receiver. Aggregate reports summarize reporting periods and do not provide a recipient-level or real-time record of every rejected message; keep SMTP bounce logs alongside them.
When reading the XML, compare auth_results with policy_evaluated. The former contains raw SPF and DKIM results; the latter contains the results after DMARC domain matching. A raw SPF pass with a DMARC SPF fail can therefore indicate a domain mismatch, rather than an unauthorized IP. These fields are defined in the aggregate reporting specification.
Suped is our DMARC reporting and email authentication platform. Use Suped to group the aggregate reports you receive by reporting receiver and sending source, then inspect authentication results and domain matches. Compare recurring Microsoft-reported failures with the sending server's NDRs to decide which production route needs investigation.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
Use the issue view to separate verified sources from unverified sources, then compare Microsoft-reported results with other receivers. For teams managing multiple domains, investigate whether the same outbound server or DNS dependency is involved across affected domains. A lower reported failure rate alone does not prove that every rejected message is fixed.
What to fix first
If the bounce rate is tiny, avoid emergency DNS edits until the evidence identifies a fault. Document the failure, prove the resolution path, remove confirmed SPF or DKIM fragility, then monitor whether Microsoft failures continue. Each 5.7.515 rejection still needs investigation because the affected message did not meet the required authentication level.
If the bounce rate is visible to users or concentrated in one Microsoft consumer domain, treat it as a delivery incident. Preserve samples, escalate with complete headers where available and NDR identifiers, and temporarily route critical mail through a production path with known passing SPF and DKIM if your infrastructure allows it. A 550 response is a permanent SMTP rejection; retry affected recipients after correcting the cause instead of repeatedly resending unchanged mail.
|
|
|
|---|---|---|
First | Save samples | Preserves proof |
Second | Classify results | Separates policy and DNS faults |
Third | Trace SPF and DKIM | Finds the failed check |
Fourth | Compare DMARC reports with bounces | Checks the pattern and delivery outcome |
Fix order for intermittent Microsoft SPF and DKIM failures.
A practical fix sequence
- Merge duplicate SPF records into one valid policy that preserves authorized senders, and repair missing DKIM selector records.
- Reduce SPF lookup pressure and keep selectors available during key rotation.
- Use DMARC reports and bounces together, because either source alone is incomplete.
- Keep DMARC policy stable while diagnosing SPF or DKIM. Lowering p=reject or p=quarantine to p=none does not repair either authentication check.
