Outlook 550 5.7.515 access denied: what it means and how to fix it

What the error says

Microsoft's support article for this bounce gives the full text as:

• 550 5.7.515 Access denied, sending domain <domain> does not meet the required authentication level.
• "The sender's domain in the 5322.From address doesn't meet the authentication requirements defined for the sender."

550 is a permanent rejection, so the message was not delivered and retrying it unchanged will not help. The domain named in the error is the one in your visible From address, which Microsoft calls the 5322.From address.

Who it applies to

The error comes from Microsoft's consumer email services: Outlook.com and related services such as Hotmail, Live.com and MSN. Microsoft announced stricter authentication requirements for high-volume senders to these services, with enforcement starting May 5, 2025. Its support article describes a high-volume sender as a domain that sends 5,000 or more messages to Microsoft consumer email services, all using the same domain in the From address. Its postmaster policies describe the threshold as more than 5,000 emails per day.

Microsoft's postmaster site says messages that do not meet the requirements may first go to the junk folder, and can then be rejected with 5.7.515. So rising junk placement at Outlook.com addresses can be an early sign of the same problem.

Microsoft's announcement and this error are about its consumer services. Company mailboxes on Microsoft 365 are filtered according to each organization's own setup, but a broken SPF, DKIM or DMARC setup can still hurt you there, so fix it either way.

What Microsoft requires

Once a domain is over the threshold, Microsoft expects every message from it to meet all of these:

1. SPF passes. Your SPF record must authorize the server that actually sent the message, for the domain in the return-path (the 5321.MailFrom or envelope sender).
2. DKIM passes. The message must carry a valid DKIM signature.
3. A DMARC record is published at _dmarc.yourdomain.com with a valid policy. Microsoft's own example is v=DMARC1; p=none, and p=quarantine or p=reject are also valid.
4. DMARC passes. At least one of SPF or DKIM must pass for a domain that aligns with your From domain.

Note the difference from DMARC on its own: DMARC only needs one aligned pass, but Microsoft's high-volume requirement asks for both SPF and DKIM to pass as well.

Step 1: check what your domain publishes

Run the domain from the error through the free checker. It looks up SPF, DKIM, DMARC and MX in one go. Look for:

• One SPF record, starting v=spf1, that includes every service sending as the domain and stays within 10 DNS lookups. See SPF record too many lookups.
• A DKIM key published for the selector your mail provider or sending tool uses. See DKIM selector not found in Google Workspace.
• A DMARC record with a p= tag. See DMARC policy for cold email.

Step 2: read the headers of a real message

DNS can look right while real messages still fail. Send a message from the same mailbox and tool you use for outreach to an Outlook.com address you own, then view the message headers (in Outlook, open the message and view its source or message details). Find the Authentication-Results header and check the SPF, DKIM and DMARC results.

Then check the domains, because this is where most setups break:

• The return-path domain should match your From domain if you want SPF to count toward DMARC. Many sending tools use their own return-path domain by default.
• The DKIM signing domain (d=) should be your domain, not your sending tool's, if you want DKIM to count toward DMARC.
• Because Microsoft wants both SPF and DKIM to pass, a message that passes DMARC through DKIM alone can still fall short if SPF fails for the return-path domain.

Step 3: fix the common causes

1. A sending tool or mailbox provider sends as your domain but is not in your SPF record. Add its include to your existing SPF record rather than publishing a second one.
2. DKIM is not set up, or is set up on the tool's domain instead of yours. Turn on custom DKIM for your domain in each tool that sends as it, and publish the keys it gives you.
3. There is no DMARC record. Publish at least v=DMARC1; p=none; with a reporting address you read, then review the reports to find senders that fail.
4. Your SPF record breaks the 10-lookup limit or you have two SPF records, so SPF returns an error instead of a pass. Merge and trim it.
5. Your tool uses its own return-path domain. If it offers a custom return-path or bounce domain on your domain, set it up so SPF aligns.

Step 4: wait for DNS, then test again

DNS changes take effect as resolvers pick them up, depending on the old record's TTL. Re-run the checker until it shows the new values, send a fresh test to an Outlook.com address you own, and confirm SPF, DKIM and DMARC all pass before resuming a campaign. Microsoft's postmaster policies say a sender must not retransmit a message after a 5xx rejection, and must stop sending to a recipient after repeated rejections. So do not re-queue the bounced messages; once your tests pass, contact only people you still intend to reach, and remove anyone who has asked you to stop.

Keep it from coming back

These failures usually start with a quiet change: a DNS edit, a new tool connected without DKIM, or a provider changing its setup. A daily check of your records catches that before Outlook.com starts sending your mail to junk or bouncing it. OutboxWatch's paid plans re-check SPF, DKIM, DMARC, MX and blacklists every day and flag changes, and the free checker is there for a quick look at any time. For the Gmail version of this problem, see Gmail 550 5.7.26.