Fixing Microsoft 550 5.7.515 Rejections in Bulk Traffic: 2026 Field Playbook

Microsoft has been rejecting non-compliant bulk traffic with the response code 550 5.7.515 since May 5, 2025. The wording in the SMTP response is consistent: "Access denied, sending domain [domain] does not meet the required authentication level." The rejection is permanent and the message never reaches the recipient. For operators running production bulk traffic to Outlook, Hotmail, Live, and MSN consumer mailboxes, this code is now the most common cause of large-batch delivery failures we see in field triage.

The playbook below is built from rejection traffic observed across managed PowerMTA infrastructure during Q1 and Q2 2026. Roughly two thirds of 5.7.515 events resolve within the same business day once the operator knows which specific check is failing. The remaining third take longer because the underlying cause is structural (DKIM keys older than 2048 bits, SPF lookups over the 10 DNS limit, PTR records under control of a third party). The playbook covers both cases.

Why 5.7.515 happens and what it really means

Microsoft announced its bulk sender requirements on April 2, 2025. The original announcement framed non-compliance as routing to the Junk folder. Twenty-seven days later, on April 29, Microsoft amended the consequence to permanent SMTP rejection. Six days after the amendment, on May 5, enforcement began. The compressed timeline is itself part of the story: senders who had treated the Gmail and Yahoo 2024 baseline as optional had 33 days to fix the gap.

The code itself is structured. The 550 is a standard SMTP permanent failure. The 5.7.515 is the Enhanced Status Code that narrows the meaning to "delivery not authorised, security or policy reason, message refused." Microsoft uses the suffix specifically for bulk sender authentication failures, distinguishing it from 5.7.1 (general policy block), 5.7.23 (SPF), 5.7.25 (PTR), and 5.7.26 (DMARC alignment). When the response code is exactly 5.7.515, Microsoft is saying the message failed one of the bulk-sender authentication checks. Other codes mean other things.

The rejection is triggered when at least one of three conditions is true. The sending domain has no published SPF record, or the SPF record fails for the connecting IP. The sending domain has no published DKIM signature, or the DKIM signature fails verification. The sending domain has no published DMARC record at p=none or stricter, or DMARC alignment fails (the From domain does not match either the SPF or DKIM signing domain). All three checks are evaluated together; passing two and failing one produces the rejection.

Reading the response line: where Microsoft tells you the cause

Microsoft includes a textual hint in the response line that identifies which check failed. The hint is short and not always specific, but it narrows the diagnostic surface meaningfully. Three typical responses are observed in the field:

550 5.7.515 Access denied, sending domain [example.com] does not pass DMARC verification
550 5.7.515 Access denied, sending domain [example.com] does not meet the required authentication level
550 5.7.515 Access denied, sending domain [example.com] does not have a valid DMARC record

The first variant points specifically at DMARC. Either no DMARC record is published or the record is present but the message fails alignment. The second is the generic version and means at least one of SPF, DKIM, or DMARC failed but Microsoft is not naming which one. The third points at the DMARC record being absent or malformed. The wording matters because it tells you where to look first.

When the cause is authentication

If the response line references DMARC, work in the following order. First, verify the DMARC record is published on the organisational domain. The check is a DNS lookup on _dmarc.example.com. If no TXT record returns, that is the cause and the fix is publishing a record at p=none minimum. Once the record propagates (typically 5 to 30 minutes for most resolvers), retry sending. The 5.7.515 should stop for that specific cause.

If the DMARC record exists, the question is whether the message passed alignment. DMARC alignment requires either the SPF authenticated domain or the DKIM signing domain to match the visible From address. A common failure mode is sending from noreply@subdomain.example.com while DKIM signs as example.com and SPF authenticates the relay's domain. Neither matches; DMARC fails. The fix is either aligning the DKIM signing domain with the From, or publishing a more permissive DMARC alignment mode (aspf=r;adkim=r rather than the default s).

If alignment is configured correctly but DMARC still fails, the cause is usually that the underlying SPF or DKIM check itself failed. Microsoft publishes the SmartScreen filtering hints in the inbound headers of accepted mail, but for rejected mail those headers never exist. The workflow is to send a test message to a personal Outlook.com account from the same sending stream, look at the raw headers Microsoft adds (Authentication-Results: in particular), and read what passed and what failed.

SPF lookups over 10 are the single most common authentication-related cause we see. Each include: statement counts, plus any a, mx, ptr, or exists mechanism, plus any nested includes inside those. A check tool such as the SPF record validator at the BIMI Group's reference implementation will count the lookups and flag the overflow. The remediation is usually consolidation: replacing several specific includes with one flattened record, or using SPF macros where supported.

When the cause is PTR or hostname mismatch

Microsoft's parallel rejection code for PTR issues is 5.7.25, but in some configurations a missing or generic PTR also triggers 5.7.515 when the receiving system rolls multiple authentication checks into a single response. The diagnostic is the same regardless: query the reverse DNS for the sending IP and confirm it resolves to a hostname that forward-confirms (the hostname's A record points back to the same IP).

Three failure patterns recur. The first is no PTR record at all: dig -x returns NXDOMAIN. The fix is asking the upstream provider to publish a PTR, or in dedicated infrastructure setting one through the registrar's reverse DNS control panel. The second is a PTR that resolves to a generic hostname under the hosting provider's domain rather than the sender's domain. This produces filtering but not always outright rejection at Microsoft; iCloud is stricter on this point. The fix is rebranding the PTR to the sending hostname. The third is a PTR that resolves but the forward lookup of that hostname does not return the original IP. This breaks forward-confirmed reverse DNS (FCrDNS) and Microsoft's SmartScreen weights it heavily as a negative trust signal.

For dedicated infrastructure operators, all three failure modes are correctable. For shared infrastructure operators, the PTR is set by the ESP and the sender does not control it. This is one of the structural arguments for dedicated infrastructure that gets more weight under post-enforcement conditions.

When the cause is policy compliance

The generic 5.7.515 response can also surface for non-authentication policy failures. The most common: missing one-click unsubscribe headers on traffic Microsoft classifies as bulk. Microsoft does not require RFC 8058 strictly, but it does require a functional unsubscribe mechanism, and traffic that fails to surface one through the standard headers gets flagged.

The check is whether the outbound message includes both List-Unsubscribe with an HTTPS URI and List-Unsubscribe-Post: List-Unsubscribe=One-Click. The check should be done on the actual message body, not on the ESP's claimed behaviour. Some ESPs add the headers selectively (only on campaigns flagged as marketing), and operators who route transactional and marketing through the same stream sometimes find that some messages have the headers and others do not. A simple test: send a message through the production stream to a personal account, view the raw source, search for "List-Unsubscribe-Post." If absent or malformed, that is the cause.

5.7.515 sub-cause	How to confirm	Typical fix time
No DMARC record published	dig _dmarc.example.com TXT returns nothing	15 minutes (publish + propagate)
DMARC alignment fails	Test message Authentication-Results shows "dmarc=fail"	1-4 hours (alignment investigation)
SPF over 10 lookups	SPF validator flags overflow	2-6 hours (record consolidation)
DKIM signing domain misaligned	Test message shows DKIM signing as relay domain, not From	1-2 hours (re-key signing)
PTR generic or missing	dig -x [IP] returns NXDOMAIN or ISP-generic hostname	30 min - 2 days (depends on provider control)
Missing List-Unsubscribe-Post	Raw message source lacks the header	1-4 hours (ESP config or MTA injection)

Same-day recovery: ordered checklist

When 5.7.515 rejections appear in significant volume (more than 1% of Microsoft traffic over an hour), work the checklist in order. Each step is a distinct cause; the steps are not cumulative. Stop at the first one that resolves the issue.

1. Confirm DMARC is published. Run dig _dmarc.[domain] TXT. If no record returns, publish one immediately at p=none. Allow 30 minutes for propagation and retry a test batch.
2. Confirm DMARC alignment. Send a test message to a personal Outlook.com inbox. View headers. Look for dmarc=pass in Authentication-Results. If dmarc=fail, identify whether the failure is on SPF or DKIM alignment.
3. Confirm SPF passes and is under the 10-lookup ceiling. Use any SPF validator. If lookups exceed 10, consolidate the record. If SPF fails entirely for the sending IP, the IP is not authorised; either authorise it or use a different IP that is.
4. Confirm DKIM signs and aligns. The test message should show dkim=pass for the From domain. If signing is happening but on a relay subdomain, re-key so the signing domain matches the From organisational domain.
5. Confirm PTR exists and FCrDNS works. dig -x [IP] should return a hostname. dig [hostname] should return the original IP. Both must work.
6. Confirm one-click unsubscribe headers are present. Raw message inspection. If absent, configure injection at the MTA or ESP level.
7. If all six pass and rejection continues, contact Microsoft sender support. The escalation path is the Sender Support form for high-volume senders. Response times are typically 24-72 hours.

Preventing the next batch

Recovery is the reactive half. The preventive half is composed of three habits that compound. The first is monthly authentication health checks: verify SPF lookup count, DKIM signature validity, DMARC publication and alignment on a routine schedule rather than reactively. A drift in any of these is the earliest warning of a future rejection event.

The second is per-ISP rejection rate monitoring. Microsoft 5.7.515 rates above 0.5% over a 24-hour window are worth investigation; above 2% is an active incident. The data exists in the PowerMTA accounting log and similar MTA logs; the work is building the alert to surface it. Most operators discover 5.7.515 events through customer complaints rather than monitoring; reversing that order saves hours per incident.

The third is keeping a calibrated test path: a small test list of recipient addresses across each major mailbox provider, including a personal Outlook.com account whose raw headers you can inspect after every significant infrastructure change. The test path catches authentication regressions before they appear in production traffic.

For organisations operating dedicated infrastructure with control over PTR records, authentication chain, and MTA configuration, the prevention work is straightforward. For organisations on shared ESP infrastructure where some of these controls are not available, the gap shows up in the field as longer incident resolution times and a higher 5.7.515 baseline. The structural conclusion many senders reached during the May 2025 enforcement wave was that dedicated infrastructure removes a category of failure modes that no amount of ESP-side configuration can address.