Error 550 5.7.515 “Access denied, sending domain does not meet the required authentication level” — what it means and how to fix it

What this error means

Your message was rejected by Microsoft(Outlook.com, Hotmail, Live, MSN) before reaching the recipient. The full bounce text reads:

550; 5.7.515 Access denied, sending domain [yourdomain.com]
does not meet the required authentication level.

This is a permanent failure: the mail was not delivered and will not be retried. Since May 2025, Microsoft enforces authentication requirements for senders to its consumer domains — messages from domains without correctly configured SPF, DKIM and DMARC are rejected outright rather than filtered to junk.

Why you’re seeing it

One or more of the following is true for your domain:

1. No DMARC record exists. Microsoft requires at minimum a published DMARC policy (p=none or stricter) at _dmarc.yourdomain.com.
2. SPF fails or doesn’t align. The server that sent the message isn’t listed in your SPF record — common when a newsletter tool, CRM, invoicing system or web shop sends on your behalf and was never authorised.
3. DKIM fails or doesn’t align. The message wasn’t signed, the signature is broken, or it was signed with a different domain than your From address.
4. Your SPF record is invalid. More than 10 DNS lookups, syntax errors, or multiple SPF records make the whole record fail (permerror) for every sender.

The “5,000 messages per day” threshold in Microsoft’s announcement misleads many small businesses. Domain reputation is scored on the same signals at every volume, and the volume of allservices sending as your domain counts together.

How to fix it

1. Check your current state. Run your domain through a checker that validates SPF, DKIM and DMARC together — a free Merula account covers one domain and runs its first checks within minutes.
2. Publish a DMARC record if missing:v=DMARC1; p=none; rua=mailto:reports@yourdomain.comis the minimum that satisfies the requirement — and therua address starts giving you visibility into who sends as your domain.
3. Identify the failing sender. The bounce tells you which message was rejected; trace it to the sending service. Add that service to SPF, or enable DKIM signing in the service’s settings (every major platform — Microsoft 365, Google Workspace, Mailchimp, HubSpot, Brevo — documents this).
4. Validate alignment. The domain in your From address must match the domain that passes SPF or DKIM. Mail sent “via” a provider’s own domain fails alignment even when SPF technically passes.
5. Re-test, then monitor. The fix takes minutes; staying fixed is the hard part. DMARC aggregate reports surface the next failure, so you can catch it early.

EU context

This is not only a Microsoft rule. Google and Yahoo enforce equivalent requirements since 2024, and European authorities point the same direction: the EU’s CSIRTs network — including CERT-EU’s guidance adopted by national teams across member states — recommends DMARC as a baseline control against sender forgery, and email authentication is a recognised component of NIS2 risk-management measures. Fixing this error brings you in line with where EU baseline expectations are heading anyway.