Skip to content
Webmaster Tools
EmailEmail Deliverability550 5.7.515

550 5.7.515 access denied by Outlook

What the 550 5.7.515 bounce from Outlook.com and Hotmail means, Microsoft's SPF, DKIM and DMARC rules for high-volume senders, and how to meet them.

What 550 5.7.515 means

A 550 5.7.515 bounce comes from Microsoft's consumer mail service (Outlook.com, Hotmail.com, Live.com) and means your sending domain does not meet its authentication requirements for high-volume senders. The basic code 550 is a permanent failure. In the enhanced status code, class 5 is permanent and subject 7 is security or policy; the detail 515 is Microsoft's own, not one of the codes listed in RFC 3463.

The reply reads approximately:

550 5.7.515 Access denied, sending domain example.com does not meet the
required authentication level.

Where it comes from

In 2025 Microsoft announced rules for domains that send more than about 5,000 messages a day to its consumer addresses, similar to the Gmail and Yahoo requirements from 2024. Rejections with this code started around May 2025. Microsoft has adjusted the details and timing in its announcements, so check its current sender guidance for exact thresholds. The core requirements:

Requirement What passes
SPF spf=pass for the sending domain
DKIM dkim=pass with a valid signature
DMARC A published record with at least p=none, aligned with SPF or DKIM

Microsoft also recommends, without enforcing the same way, a working unsubscribe link, valid From and Reply-To addresses, and keeping lists clean.

Business mailboxes in Microsoft 365 (Exchange Online) are a separate system with their own filtering. This code is about the consumer service.

Common causes

  • No DMARC record on the From domain. This is the most frequent gap for senders who already have SPF and DKIM.
  • DKIM signed with the email service's domain instead of yours, so it does not align.
  • SPF failing because a sending service is missing from the record, or the record has too many DNS lookups.
  • Sending from a subdomain without its own records, while the organizational domain has no DMARC policy that covers it.

How to fix it

  1. Look at the authentication results. Send a test to an Outlook.com address you own and paste the headers into the Email Header Analyzer:
Authentication-Results: spf=pass (sender IP is 203.0.113.25)
 smtp.mailfrom=bounce.example.com; dkim=pass (signature was verified)
 header.d=example.com; dmarc=pass action=none header.from=example.com;
  1. Publish SPF for the envelope sender domain:
example.com.  IN TXT "v=spf1 include:mail.example.net -all"
  1. Sign with DKIM using your own domain in every service that sends as you:
s1._domainkey.example.com.  IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
  1. Publish DMARC. Start with monitoring and a report address:
_dmarc.example.com.  IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
  1. Resend the rejected messages once DNS has updated. A 550 is not retried.

Once reports show all your legitimate mail passing, consider moving from p=none to p=quarantine.

  • 550 5.7.26: Gmail's rejection for unauthenticated mail.
  • DMARC p=none: the minimum policy Microsoft accepts.
  • DKIM none: when a message carries no signature at all.

Check your domain's SPF, DKIM and DMARC together with the Email Checker.