Datahorses

Outlook sender requirements since May 2025 and the 550 5.7.515 rejection

By · · 4 min read

The bounce 550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level means Outlook.com rejected your message because your domain did not pass the SPF, DKIM and DMARC checks Microsoft requires from high-volume senders. The fix is in your DNS and in the configuration of the systems that send your mail, not in the content of the message.

Microsoft announced the rules on its Microsoft Defender for Office 365 blog in April 2025, with enforcement starting on 5 May 2025. They apply to Outlook.com, Microsoft's consumer service, which covers addresses at outlook.com, hotmail.com and live.com.

The requirements closely follow what Gmail and Yahoo introduced in 2024, so a domain set up correctly for one provider is usually most of the way there for the others.

What Microsoft requires

According to the announcement, domains sending more than 5,000 emails per day to Outlook.com must meet 3 conditions:

  • SPF must pass for the sending domain, with the DNS record accurately listing authorized IP addresses and hosts.
  • DKIM must pass, to validate the integrity and authenticity of the message.
  • DMARC must be published with at least p=none, and must align with either SPF or DKIM (Microsoft says preferably both).

Microsoft also lists email hygiene practices for large senders and reserves the right to filter or block senders who ignore them:

  • A valid From or Reply-To address that reflects the real sending domain and can receive replies.
  • A clear, working unsubscribe option for marketing and bulk mail.
  • Regular removal of invalid addresses and handling of bounces.
  • Accurate subject lines, no deceptive headers, and recipients who agreed to receive your messages.

Junk folder or rejection

The original announcement said non-compliant mail would first be routed to the Junk folder. Microsoft updated the post on 29 April 2025: messages that fail the authentication requirements are rejected with the 550 5.7.515 error, taking effect on 5 May 2025 as originally planned (source).

In practice this is useful: a rejection shows up in your sending logs and bounce reports, while a quiet move to Junk can go unnoticed for a long time.

Why a legitimate domain gets 5.7.515

The usual causes are configuration gaps, not anything malicious:

A sending tool without DKIM for your domain. Newsletter platforms, CRMs and invoicing tools often sign with their own domain unless you add their DKIM records to yours.

SPF passing for the vendor, not for you. Many services use their own return path, so SPF passes for bounce.vendor.net. Without aligned DKIM, DMARC fails.

No DMARC record. Microsoft requires at least p=none. A missing _dmarc record is enough to fail.

SPF over its lookup limit. SPF allows at most 10 DNS lookups (RFC 7208, section 4.6.4). Add one service too many and SPF returns an error for every message.

A recent DNS change. A migration to a new DNS provider or mail host that left out a DKIM selector or the SPF include for one service.

How to find the cause

Start with your DNS:

dig +short TXT yourcompany.com | grep spf1
dig +short TXT _dmarc.yourcompany.com
dig +short TXT selector1._domainkey.yourcompany.com

Next, find out which system sent the bounced message. The bounce usually contains the original headers. Then send a test from that same system to an Outlook.com address you control and inspect the Authentication-Results header. Microsoft explains how to read it in its message header documentation. You are looking for:

spf=pass smtp.mailfrom=yourcompany.com
dkim=pass header.d=yourcompany.com
dmarc=pass header.from=yourcompany.com

If smtp.mailfrom or header.d shows the vendor's domain instead of yours, alignment is the problem. If dkim=none, the system is not signing at all.

How to fix it

  1. Publish a DMARC record if you have none: v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com.
  2. In each sending tool, set up DKIM with your own domain (the tool provides CNAME or TXT records to add).
  3. Where the tool supports a custom return path, point it to a subdomain of yours so SPF aligns too.
  4. Merge SPF into one record, remove services you no longer use and stay under 10 lookups.
  5. Resend a test to Outlook.com and confirm all 3 checks pass.
  6. Once DMARC reports show all legitimate mail passing, move toward p=quarantine and later p=reject.

Microsoft points senders to its Outlook sender support portal for further help. Our guide to SPF, DKIM and DMARC explains each record in more detail.

A short checklist

  • SPF passing, one record, under 10 lookups.
  • DKIM signing with your domain in every system that sends mail.
  • DMARC published, at least p=none, aligned with SPF or DKIM.
  • Bounce logs checked for 5.7.515 after any DNS or provider change.
  • A working unsubscribe and clean lists for marketing mail.

Where Datahorses fits

Datahorses watches your mail-related DNS records from the outside every day, so a removed DKIM selector, a broken SPF record or a weakened DMARC policy is noticed before it turns into bounces. A person reviews each change and sends your developer the exact records to fix. See what we guard, how we handle a finding, or the example dashboard.

More articles

All articles