Outlook 550 5.7.515 on a Self-Hosted Mail Server: What to Check Before You Touch DNS

If you run your own mail server, sooner or later a user forwards you a bounce from Outlook.com that ends in 550 5.7.515 Access denied, sending domain [yourdomain] does not meet the required authentication level. Then someone suggests changing the SPF record, someone else wants to add a relay, and within an hour three people are editing DNS for a domain that every mailbox in the company depends on.

Slow down first. This post is what we check, in what order, before we touch a single record. It comes from running our own outbound mail for fanpino.com and for a 10,000-mailbox university deployment, and from one case where the obvious diagnosis turned out to be wrong.

What Microsoft actually asks for

Microsoft published its rules for Outlook.com, Hotmail, Live and MSN in a Defender for Office 365 blog post in April 2025. Domains that send more than 5,000 messages a day to those consumer addresses need SPF to pass, DKIM to pass, and a DMARC record of at least p=none that passes through an aligned SPF or DKIM result. From May 5, 2025 failing mail went to Junk. The hard rejection with 5.7.515 came after that, and it is the bounce people are seeing now.

Two details catch self-hosters out. The 5,000 threshold is counted per From domain, and plenty of admins on Microsoft Q&A report the error while sending a few dozen messages a day, so don't assume you're exempt because you're small. And "alignment" means the domain that passed SPF or DKIM has to match the domain in the visible From header. SPF passing for bounces.some-relay.net does nothing for mail whose From address is on yourdomain.com.

Step 1: get the real header, not the bounce text

The bounce tells you Outlook was unhappy. It doesn't tell you which check failed. So before anything else, send one message from the affected server to a mailbox you control at Gmail or Outlook.com, open the original source ("Show original" in Gmail, "View message source" in Outlook.com) and find the Authentication-Results line. You want to see all three:

spf=pass smtp.mailfrom=yourdomain.com
dkim=pass header.d=yourdomain.com
dmarc=pass (p=REJECT) header.from=yourdomain.com

This one test settled a real argument for us. A reply sent from our domain was reported as rejected by a Microsoft 365 recipient, and the first diagnosis in the thread was confident: SPF was missing a relay include and DKIM wasn't set up. Before changing anything we sent a test to Gmail and read the header. It said spf=pass, dkim=pass, dmarc=pass with our p=reject policy. We also went looking for the bounce and never found one, not in the inbox and not in the mail server's delivery trace. Nothing was broken. If we had "fixed" SPF by adding a relay we don't use, we'd have authorized a third party to send as us and fixed nothing.

Step 2: check SPF against the IP that really sends

If SPF fails, look up the record (dig +short TXT yourdomain.com) and compare it with the public IP your server actually uses for outbound connections. Get that from the server itself, for example curl -4 ifconfig.me, not from the MX record or a dashboard. On a host with several addresses, or behind NAT, those can differ.

Our record is about as short as SPF gets: v=spf1 mx -all. The MX host is the sending host, so mx covers it and -all refuses everything else. If you also send through a newsletter tool or a CRM, each one needs its own include, and you have to stay under SPF's 10 DNS lookup limit. Go over it and SPF returns permerror, which Outlook counts as a fail.

Step 3: DKIM, the one that breaks quietly

Modern servers such as Stalwart generate DKIM keys for you and some rotate them, which is good until the DNS side lags behind. The selector name is in the DKIM-Signature header of any message you send (s=...). Query <selector>._domainkey.yourdomain.com and make sure the public key there is the one the server is signing with right now. A stale key after a rotation gives you dkim=fail (bad signature) on every message, and if SPF is fine you may not notice until Outlook starts bouncing.

Also check that the d= in the signature is your domain and not the server's hostname or a provider's domain. A valid signature from the wrong domain passes DKIM but fails DMARC alignment.

Step 4: DMARC, and why p=none is not the goal

Microsoft's minimum is p=none, and that is enough to stop the 5.7.515 bounce. It isn't enough to stop someone else sending as your domain. We publish v=DMARC1; p=reject; rua=mailto:postmaster@.... If you're starting from nothing, begin with p=none and a working rua address, read the aggregate reports for two or three weeks to find senders you forgot about (the invoicing system, the old web form, the scanner that emails PDFs), then move to quarantine and later reject.

When all three pass and Outlook still refuses

Then it isn't authentication, and changing DNS won't help. Read the code carefully. A 5.7.515 is about authentication. A block on your IP's reputation looks different, with Outlook's own S3150 or "banned sender" wording, and Gmail has its own version (550 5.7.28 ... unusual rate of unsolicited mail, which we did get from Gmail on our mail IP back in June, long after our records were correct). Reputation problems are fixed through Microsoft SNDS and the sender support form, or Google Postmaster Tools, and by sending less unsolicited mail, not by editing SPF.

A short checklist

• Read the Authentication-Results header of a fresh test message before you change anything.
• SPF: covers the real outbound IP, ends in -all or ~all, under 10 lookups.
• DKIM: selector in DNS matches the key the server signs with today, d= is your domain.
• DMARC: at least p=none with reports, heading toward reject.
• Everything passes and mail still bounces: it's reputation or content, look at SNDS and Postmaster Tools.

If you're still choosing a mail server, we compared three self-hosted options at real scale in Mailcow vs Stalwart vs Mailu. The broader question of whether to host mail yourself at all is in why some organizations still self-host email in 2026, and if you're moving off an old Exchange server, the Exchange 2019 end-of-support post covers the migration side.