Outlook 550 5.7.515: how to audit SPF, DKIM and DMARC before resending

What 5.7.515 tells you

Microsoft publicly associates 550 5.7.515 with required sender-authentication levels for Outlook.com consumer mail. The useful interpretation is that this is an authentication-policy rejection, not a generic “recipient does not exist” bounce. Because it is a 5xx response, treat the individual delivery attempt as permanently rejected rather than creating aggressive retries. The repair belongs in sender configuration: identify the From domain, envelope domain, DKIM signature, and DMARC result that the production message actually used.

Scope the policy to the right Outlook service

Microsoft’s published high-volume sender requirements apply to Outlook.com consumer destinations, including outlook.com, hotmail.com, and live.com addresses. Do not automatically generalize the same code path to every Microsoft 365 tenant with custom policy. Store recipient domain and remote MX in your logs so you know which environment returned the code. The visible error and official source should define the incident scope, not assumptions based only on the Microsoft brand.

Check SPF on the envelope identity

Read the Return-Path or failed transport log to identify the MAIL FROM domain that SPF evaluates. Query that domain for one valid SPF policy, confirm the sending IP is authorized through the intended mechanism, and ensure the policy does not produce PermError from duplicate records or excessive lookups. A root-domain SPF screenshot can be irrelevant if the provider uses a separate bounce subdomain. Always troubleshoot the identity the receiver evaluated.

Check DKIM on the signature that actually arrived

Inspect DKIM-Signature for d= and s=. Query the selector, confirm the key resolves, and verify the receiver result. If DKIM fails because the body was modified, republishing the same key is not enough. If the selector is missing after a migration, publish the provider-required record and wait for external resolution before sending a larger test. Microsoft’s requirement is about working authentication on the message path, not about having nominal records somewhere in the zone.

Check DMARC and alignment

DMARC depends on aligned SPF or aligned DKIM. A message can show spf=pass for a vendor Return-Path while still failing DMARC if that domain is unrelated to the visible From, and a provider-owned DKIM domain can create the same issue. Compare the actual identities side by side. If at least one mechanism passes and aligns, DMARC can pass. The fastest fix is usually enabling the provider’s custom authentication domain correctly rather than changing the visible From to a vendor address.

Retest one controlled message before reopening the queue

After repairing DNS or provider settings, send a single controlled message through the same application and path that previously failed. Check whether 5.7.515 disappears and whether receiver-side authentication passes. Do not test only from a personal mailbox if the campaign uses a different provider or envelope domain. Once the exact production route is clean, increase to a small batch and monitor. This keeps the authentication incident separate from any reputation issue that may remain after the technical failure is fixed.

Log the domains that satisfied each mechanism

Store more than pass/fail. For SPF, keep the evaluated domain; for DKIM, keep d= and selector; for DMARC, keep the policy domain and aligned path. This turns a future migration into a comparison exercise. If a provider changes the Return-Path or signer, you can see the identity drift before recipients begin rejecting mail. For a small team, a few structured fields in the send log are far more actionable than screenshots of setup wizards.

Do not treat a permanent rejection as a reputation warmup problem

Authentication rejection and reputation throttling require different responses. If the server says the sending domain does not meet the authentication level, fix SPF, DKIM, or DMARC before experimenting with lower copy volume or a longer warmup. Slowing a technically unauthenticated message does not make it authenticated. Once identity passes, then evaluate any remaining placement or rate-limit signals separately.

Debug 5.7.515 as an authentication chain, not a content rewrite exercise

A 550 5.7.515 rejection from Outlook.com is a permanent SMTP response telling you the sending domain did not meet the required authentication level. The practical first pass is deterministic: identify the envelope domain and check SPF, identify the DKIM signature that should authenticate your domain and check its selector, then evaluate whether either passing identifier aligns with the visible From domain under DMARC. Rewriting subject lines or reducing link count before that chain is clean mixes content troubleshooting with an explicit authentication failure.

Keep service scope in the incident note. Microsoft’s published high-volume sender requirements apply to consumer Outlook.com-family destinations and use SPF, DKIM, and DMARC as the authentication baseline for high-volume domains. A B2B campaign can still encounter Microsoft-hosted organizations through other services, so the recipient domain and returned server text should be preserved rather than generalized as “Microsoft blocked us.” Once DNS changes are made, wait for the expected TTL path, then send one controlled message to an affected consumer address and inspect the received authentication results or the new SMTP rejection. Resume the queue only after the mechanism and alignment evidence agrees with the fix.

Field checklist

• Save the full 550 5.7.515 diagnostic and recipient domain.
• Inspect the production Return-Path, not only the root SPF record.
• Verify the DKIM selector from the actual signature.
• Confirm DMARC passes through an aligned SPF or DKIM identity.
• Retest the exact production path with one message before reopening volume.
• Store authentication domains in logs for future migrations.