Key takeaways
- 550 5.7.515 means Microsoft rejected your email because your domain failed its authentication requirements.
- It mainly affects domains sending more than 5,000 emails a day to Outlook.com, Hotmail and Live addresses.
- You need SPF and DKIM passing, and DMARC published (at least p=none) aligned with SPF or DKIM.
- Check every service that sends with your domain, not only your newsletter platform.
- After fixing DNS, test with a real message and watch bounces for a few days.
In this guide
- What the error looks like
- Why you are seeing it now
- Diagnose your case in 5 minutes
- The usual causes and fixes
- Step-by-step fix
- Check your platform's bounce suppression
- Is 550 5.7.515 related to blacklists?
- Other Microsoft 5.7.x errors you may see
- Real example: an invoicing tool causing bounces
- How to read a full Microsoft bounce
- Quick fix table by tool type
- Communicating with affected customers
- What if you send fewer than 5,000 emails per day?
- Preventing the error in the future
- Frequently asked questions
What the error looks like
In your email platform's bounce report, or in a bounce message, you see something like this:
550 5.7.515 Access denied, sending domain [yourbrand.com] does not meet
the required authentication level.The exact wording can vary slightly, but the meaning is always the same: Microsoft rejected the message because the domain in the From address did not pass its authentication requirements. The 550 means permanent failure: the message will not be retried. The 5.7.x family covers security and policy rejections.
Why you are seeing it now
Microsoft announced in 2025 that domains sending more than 5,000 emails per day to its consumer services (Outlook.com, Hotmail.com, Live.com) must meet three requirements:
| Requirement | Condition |
|---|---|
| SPF | Must pass for the sending domain |
| DKIM | Must pass |
| DMARC | Published with at least p=none, and aligned with SPF or DKIM (both preferred) |
Enforcement began in May 2025. Microsoft first planned to send non-compliant messages to Junk, then switched to rejecting them. That is when 550 5.7.515 bounces started to appear in many senders' reports.
Diagnose your case in 5 minutes
- Find which stream bounces. Newsletters? Shop notifications? Invoices from an accounting tool? The bounce report usually shows the campaign or system.
- Send a test from that stream to an Outlook.com or Gmail address and open the full headers (in Gmail, "Show original").
- Read the authentication results: look for
spf=,dkim=anddmarc=. - Check DKIM alignment: in the
DKIM-Signatureheader, doesd=show your domain or the tool's domain? See how to find your DKIM selector. - Check DMARC: look up the TXT record at
_dmarc.yourdomain.com. No record means no DMARC.
The usual causes and fixes
| What you find | Cause | Fix |
|---|---|---|
| No DMARC record | DMARC never published | Publish v=DMARC1; p=none; rua=mailto:... |
| DKIM signed with the tool's domain only | Custom DKIM not set up in the tool | Authenticate your domain in the tool and publish its DKIM records |
| SPF fails or PermError | Tool missing from SPF, or more than 10 lookups | Add the tool or fix the record; see too many DNS lookups |
| SPF passes but for another domain, no DKIM | No aligned method | Enable aligned DKIM; it is the robust fix |
| Everything passes on the test, bounces continue | Another system sends with your domain | Find it in DMARC reports |
Step-by-step fix
- List every service sending with your domain: mailbox provider, marketing platform, shop, CRM, helpdesk, invoicing, website forms.
- Enable DKIM on your domain in each one. Copy the records each service gives you into your DNS, then click "verify" in the service.
- Fix SPF so there is one record including the services that need it, under 10 lookups.
- Publish DMARC with
p=noneand a reporting address if you do not have one. - Wait for DNS propagation, usually minutes to a few hours.
- Retest with a real message to an Outlook.com address and check the headers.
- Resend important bounced messages once authentication passes. Bounced contacts may have been suppressed by your platform; check before resending.
The full background on these three records is in SPF, DKIM and DMARC explained.
Check your platform's bounce suppression
Most email platforms automatically suppress addresses after a hard bounce. A 550 5.7.515 is technically a hard bounce, but the address itself is valid: the problem was your authentication. After fixing it:
- Look for Microsoft addresses suppressed during the incident.
- Check your platform's documentation on how to reactivate contacts suppressed because of a policy bounce.
- Do not reactivate addresses that bounced for other reasons, such as "user unknown".
Is 550 5.7.515 related to blacklists?
No. This error is about authentication, not a blocklist listing. Requesting delisting will not help. If your bounces mention a blocklist, that is a different problem; see how to check blocklists.
Other Microsoft 5.7.x errors you may see
| Error | General meaning | Where to look |
|---|---|---|
| 550 5.7.515 | Domain does not meet authentication requirements | SPF, DKIM, DMARC |
| 550 5.7.1 (various texts) | Blocked for policy or reputation reasons | Bounce text, reputation, blocklists |
| 451 4.7.x (temporary) | Throttled or temporarily deferred | Volume spikes, warm-up, reputation |
Always read the full bounce text: Microsoft usually includes a short explanation. For temporary deferrals during volume increases, see email warm-up.
Real example: an invoicing tool causing bounces
A typical case: a company's newsletters reach Outlook.com without problems, but customers with Hotmail addresses stop receiving invoices. The bounce report of the invoicing tool shows 550 5.7.515.
- The newsletter platform signs DKIM with the company's domain: compliant.
- The invoicing tool sends "from" the company's domain, but signs DKIM with its own domain and is not in the company's SPF record.
- DMARC fails for invoices only, and Microsoft rejects them.
The fix took fifteen minutes: enable custom domain authentication in the invoicing tool, publish its DKIM record, and add its include to SPF. The lesson: when only one type of email bounces, look at the specific tool that sends it, not at your main platform.
How to read a full Microsoft bounce
A complete bounce message usually contains the recipient address, the remote server that refused the message (a Microsoft host name), the status code and a short explanation. Keep three elements: the code (5.7.515), the domain mentioned in brackets, and the date. The domain in brackets is the one Microsoft evaluated; if it is not the one you expected, a tool is sending with a different From domain than you think.
Quick fix table by tool type
| Tool sending with your domain | Usual fix |
|---|---|
| Email marketing platform | Authenticate your domain (DKIM records), verify in the platform |
| Google Workspace / Microsoft 365 mailboxes | Enable DKIM in the admin console; check SPF include |
| E-commerce platform notifications | Enable custom sender domain and DKIM, or use an authenticated email service |
| CRM, helpdesk, invoicing tools | Custom domain authentication in the tool's email settings |
| Website contact forms | Send through an authenticated SMTP service instead of the web server |
Communicating with affected customers
If important emails such as invoices or order confirmations bounced, contact affected customers through another channel once the fix is in place, and resend the documents. Customers rarely know their provider rejected a message, and a short note avoids payment delays and support tickets. Keep a list of affected addresses from the bounce report so nobody is forgotten.
What if you send fewer than 5,000 emails per day?
Microsoft's announcement targets high-volume senders, but the same authentication checks feed its filtering for everyone. Lower-volume senders without DMARC or aligned DKIM are more likely to land in Junk, and policy changes can extend enforcement later. Setting up SPF, DKIM and DMARC costs nothing and removes the risk, whatever your volume.
Preventing the error in the future
- Authenticate every new tool before it sends a single email in your name
- Read DMARC reports monthly to catch unknown or failing sources
- Keep SPF under the lookup limit when adding services
- Re-check headers after DNS or provider changes
- Watch your bounce reports by provider after each campaign
Gmail enforces similar rules with its own error; see the Gmail 550 5.7.26 guide. And for Outlook placement issues that are not bounces, see emails going to junk in Outlook.
Frequently asked questions
What does 550 5.7.515 mean exactly?
It is a permanent rejection from Microsoft. The sending domain does not meet the required authentication level, which means SPF, DKIM or DMARC is missing or failing.
Does 550 5.7.515 affect Microsoft 365 business addresses?
The 2025 requirements target Microsoft consumer services (Outlook.com, Hotmail, Live). Business mailboxes on Microsoft 365 follow their own policies, but authentication helps there too.
I only send a few hundred emails. Can I get this error?
The rule targets high-volume domains, but authentication failures can lead to rejections or junk placement at any volume. Set up all three records anyway.
How long after fixing DNS will the error stop?
Usually as soon as DNS changes propagate, often within a few hours. Resend a test to an Outlook.com address to confirm.
Is this a blacklist problem?
No. 5.7.515 is an authentication rejection, not a blocklist listing. Fix the DNS records rather than requesting a delisting.
