Error 550 5.7.515 in Outlook: Why Microsoft Rejects Your Mail and How to Fix It
It starts with one bounce, then a flood: 550 5.7.515 Access denied, sending domain does not meet the required authentication level. Within minutes the help desk fills up. Invoices to Outlook.com customers bounce, a newsletter is half delivered, a sales rep cannot reach a prospect on hotmail.com. Nothing on your side changed, yet since 5 May 2025 Microsoft returns this code to domains that delivered fine the day before.
This guide explains what 550 5.7.515 means, why Microsoft started enforcing it, and how to clear the rejection in three concrete steps. It complements our DMARC email authentication overview by focusing on the acute bounce.
What the code actually means
TL;DR:
550 5.7.515is a hard rejection from Microsoft consumer servers like Outlook.com, Hotmail and Live. Your domain failed the authentication check because valid SPF, DKIM and DMARC are missing or do not align with the From address. Publish a valid SPF record, enable DKIM signing and publish a DMARC record at_dmarc.your-domain, then verify that SPF or DKIM aligns with the From domain. Start DMARC atp=noneto monitor before tightening.
The code has a clear structure. The leading 550 is a permanent SMTP rejection, which is why the message bounces back instead of landing in a spam folder. The enhanced status 5.7.515 is Microsoft specific and points at policy enforcement, not a server outage or a full mailbox.
In plain terms, the receiving server checked your sending domain for SPF, DKIM and DMARC and found no passing, aligned result. Microsoft rolled this enforcement out for high volume senders to its consumer domains in May 2025. For years unauthenticated mail was tolerated; once enforcement went live, the same mail began bouncing. This is not a reputation penalty and not an IP block. It is a missing prerequisite, and the cure is to supply the authentication Microsoft now requires.
Diagnosis in three steps
Work through the authentication stack in order. Each layer builds on the one before it, so fix them top to bottom rather than guessing.
Step 1: Check your SPF record
SPF tells receivers which servers may send for your domain. Look up the TXT record at the root of your domain and confirm it exists, starts with v=spf1, lists every sending system you use, and ends in a hard -all or soft ~all qualifier. Two failures are common: no record at all, and a record that omits a platform you forgot, such as a newsletter tool or a CRM. SPF also has a limit of ten DNS lookups; exceeding it makes SPF fail even when every entry looks correct.
Step 2: Enable and verify DKIM
DKIM adds a cryptographic signature to each message and survives forwarding, which SPF does not. Enable DKIM signing on every platform that sends for your domain, then publish the matching public key as the CNAME or TXT record your provider gives you. Send a test message to an account you control and inspect the headers for dkim=pass. A frequent mistake is signing on one system, for example Microsoft 365, while a second sender like a billing tool still sends unsigned. Every source needs its own valid DKIM key.
Step 3: Publish a DMARC record
DMARC is the layer Microsoft specifically wants to see, and the one most domains lack. Publish a TXT record at _dmarc.your-domain with at least a monitoring policy and a reporting address, for example v=DMARC1; p=none; rua=mailto:dmarc@your-domain. Starting at p=none is deliberate: it satisfies the presence requirement without risking your own mail while the aggregate reports roll in. DMARC also enforces alignment, meaning the From domain a recipient sees must match the domain that passed SPF or DKIM. Generate a correct record quickly with our DMARC record builder.
Quick reference: symptom, cause, fix
Map the bounce you are seeing to its root cause and the corrective action.
| Symptom | Cause | Fix |
|---|---|---|
550 5.7.515 on every message to Outlook.com | No DMARC record for the From domain | Publish a DMARC TXT record at _dmarc starting with p=none |
| SPF passes but mail still bounces | DMARC alignment fails, From and envelope domains differ | Add a DKIM signature aligned to the From domain |
| One platform delivers, another bounces | Second sender missing from SPF and has no DKIM key | Add it to SPF and enable its DKIM signing |
| Intermittent bounces only on forwarded mail | SPF breaks across forwarders, no surviving DKIM | Enable DKIM so authentication survives forwarding |
How Conbool DMARC exposes the root cause and prevents a repeat
The hardest part of 550 5.7.515 is rarely publishing one record. It is knowing which of your sending systems is unauthenticated, and proving the fix held without breaking legitimate mail. A single domain often sends through a mail platform, a CRM, a billing system, a marketing tool and a contact form, and any one of them can trigger the rejection.
Conbool DMARC turns the raw aggregate reports that receivers send back into a readable picture of every source mailing as your domain. You see which systems pass SPF and DKIM, which fail alignment, and which unknown senders use your name. Instead of toggling DNS records and hoping, you watch the reports confirm that each legitimate source authenticates before you tighten the policy: from p=none to observe, to p=quarantine once your real senders align, then to p=reject to lock out spoofing. Pairing DMARC with a gateway such as Conbool MailGuard on the inbound side closes the loop, because the same signals that satisfy Outlook.com also harden you against inbound phishing and spoofing.
Frequently asked questions
What does the error 550 5.7.515 mean?
The bounce 550 5.7.515 is a hard rejection from Microsoft consumer mail servers such as Outlook.com, Hotmail and Live. The accompanying text usually reads Access denied, sending domain does not meet the required authentication level. The receiving server checked your sending domain for SPF, DKIM and DMARC and found no passing alignment. Because the code starts with 550, the message is refused and bounced back rather than placed in spam.
Why has Microsoft been rejecting my mail since May 2025?
From 5 May 2025 Microsoft began enforcing sender authentication requirements for high volume senders to its consumer domains. Senders that previously delivered without SPF, DKIM or DMARC were tolerated for years, so many domains never noticed the gap. With enforcement live, a domain that lacks valid authentication now receives 550 5.7.515 instead of silent delivery. The change closes a long standing loophole, which is why the bounces appeared suddenly even though nothing on your side changed.
How do I fix 550 5.7.515 step by step?
Fix the authentication stack in order. First publish a valid SPF TXT record that lists every system allowed to send for your domain and ends in -all or ~all. Second enable DKIM signing and publish the matching public key, then confirm the signature validates. Third publish a DMARC record at _dmarc.your-domain with at least p=none and a rua address. Once SPF or DKIM aligns with the From domain and DMARC is present, Microsoft stops returning the code.
Does this also affect small senders?
Microsoft framed the enforcement around high volume senders, but in practice any domain can be caught. A small business that sends invoices, a newsletter, a CRM, a ticket system or a contact form can quickly cross internal thresholds, and a misconfigured shared platform can trigger the rejection even at low volume. The safe assumption is that every domain sending to Outlook.com needs valid SPF, DKIM and DMARC, regardless of size.
Will a single SPF record alone fix the rejection?
Usually not on its own. Microsoft expects the full trio: SPF, DKIM and DMARC. SPF can pass while still failing DMARC alignment if the visible From domain does not match the envelope sender, which is common with forwarders or marketing tools. DKIM provides a signature that survives forwarding, and DMARC ties the result to the From domain recipients actually see. Publish all three and verify that at least one of SPF or DKIM aligns with the From domain.
Conclusion
The 550 5.7.515 bounce looks alarming, but it carries a precise message: your domain lacks the SPF, DKIM and DMARC authentication that Microsoft now requires from anyone mailing its consumer addresses. Fix the three layers in order, start DMARC in monitoring mode, and confirm alignment with reports rather than guesswork. The bounces stop and your domain becomes far harder to spoof.
The next step is yours: run a free domain check to see your current SPF, DKIM and DMARC status, then let Conbool DMARC turn the reports into a clear path from p=none to full protection.
Further reading:
