Outlook 550 5.7.515 error: fix "sending domain does not meet the required authentication level"
Microsoft bounced your message to an Outlook or Hotmail address with 550 5.7.515 Access denied, sending domain does not meet the required authentication level. Here is what it means and exactly how to fix it — in plain English.
1. What the bounce actually means
In 2025 Microsoft introduced authentication requirements for high-volume senders to its consumer mailboxes (outlook.com, hotmail.com, live.com), following the rules Google and Yahoo rolled out in 2024. Domains sending more than about 5,000 messages a day to Outlook addresses must have:
- SPF passing for the sending domain,
- DKIM signing the mail, and
- DMARC published with at least
p=none, aligned with the visibleFrom:domain.
Mail that misses the bar is rejected with the 550 5.7.515 code naming your domain. Even below the volume threshold, failing these checks lands you in the junk folder, so the fix is the same for everyone.
2. Step-by-step fix
Check (or add) your SPF record. One TXT record on your root domain listing every provider that sends for you:
Type: TXT
Host: @ (yourdomain.com)
Value: v=spf1 include:spf.protection.outlook.com ~all
Replace or add the include: for each provider you actually use (Microsoft 365, your marketing platform, your invoicing tool). You may have only one SPF record, and it must stay under 10 DNS lookups.
Enable DKIM with your own domain. For Microsoft 365, go to the Defender portal > Email authentication settings > DKIM, select your domain, and enable signing; Microsoft gives you two CNAME records to publish first. For other providers, turn on "custom DKIM domain" or "domain authentication" in their settings. The key point: the signature must use your domain, not the provider's shared one, or it won't align.
Add a DMARC record. A TXT record at _dmarc:
Type: TXT
Host: _dmarc (_dmarc.yourdomain.com)
Value: v=DMARC1; p=none; rua=mailto:reports@yourdomain.com
p=none satisfies Microsoft's minimum while you monitor; the rua address receives the aggregate reports that show which sources pass and fail. You can build this record with our free DMARC generator.
3. Verify before you resend
dig +short TXT yourdomain.com
dig +short TXT _dmarc.yourdomain.com
You should see one v=spf1 value and one v=DMARC1 value. Then send a test to an address you control at Outlook and open the message headers: Authentication-Results should show spf=pass, dkim=pass, and dmarc=pass. If DMARC still fails with SPF and DKIM configured, it is almost always an alignment problem — see why DMARC fails and how to fix it.
4. Common mistakes to avoid
- DKIM signed with the provider's domain. A pass that isn't aligned with your
From:domain does not count for DMARC. Enable the custom-domain option. - Two SPF records. More than one
v=spf1record makes SPF fail outright. Merge them. - Fixing only the root domain. If you send from
mail.yourdomain.com, that subdomain needs its own SPF and DKIM alignment too. - Stopping at p=none forever.
p=nonegets you delivered, but it doesn't stop anyone spoofing your domain. Once your reports show clean traffic, tighten top=quarantine, thenp=reject.
Google's requirements are close cousins of Microsoft's — if you also see Gmail bounces, see our Gmail 550-5.7.26 fix and the full bulk-sender requirements guide.
Not sure your records are right? PlainDMARC reads your DMARC aggregate reports and sends you a plain-English weekly verdict — what passed, what failed, and what to change — so you catch problems before Microsoft bounces your mail.
Get a plain-English weekly DMARC verdict — create a free account