Bounce and error codes

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

Last updated 2026-08-14

Microsoft turned its bulk-sender rules into hard rejections, and this is the bounce you get. It is not a blocklisting and not a content filter. Your domain is missing authentication Microsoft now insists on.

The exact bounce

The domain in the brackets is the one to fix. Read it carefully: it is the domain in the From: header, which for mail sent through a marketing platform is often not the domain you were expecting. Microsoft uses related codes for adjacent problems, and they mean different things. 550 5.7.509 means your DMARC record exists and told Microsoft to reject (separate page), and 550 5.7.23 is a plain SPF failure (also separate).

Causes, in the order I find them

1. No DMARC record at all. By far the most common. The domain has SPF, usually has DKIM, and has never had anything at _dmarc.
2. A DMARC record that receivers ignore. Two TXT records at _dmarc, or a record that does not begin with v=DMARC1, or one pasted into a DNS panel that appended the domain again and produced _dmarc.example.com.example.com.
3. Neither SPF nor DKIM aligns. The platform sends with its own return-path and signs with its own d=, so both checks pass for the platform's domain and neither passes for yours. This is the failure that survives a correct DMARC record and keeps the bounce coming.
4. SPF is in permerror. Over ten DNS lookups and SPF stops returning a pass, whatever the record looks like to a human. See SPF PermError.
5. DKIM is published but not switched on. The key is in DNS, the provider was never told to start signing, and nothing in the interface says so.

Diagnose it in four commands

Substitute the domain from the bounce for example.com throughout.

The first must return exactly one string starting v=DMARC1. The second must return exactly one string starting v=spf1. The last two are guesses at your DKIM selector: Microsoft 365 uses selector1 and selector2, Google Workspace uses google. If neither is yours, open a message you sent, view the source, and read s= out of the DKIM-Signature: header.

Then run the domain through the DMARC checker and the SPF checker. The SPF one follows every include and counts the lookups, which is the check people skip and the one that most often explains a record that looks fine.

The definitive test is a message. Send one from the failing system to a mailbox you control at outlook.com, then open the raw source and read Authentication-Results:. You want dmarc=pass. If you see spf=pass next to dmarc=fail, the problem is alignment and not SPF, which is a different fix entirely.

Fixing each cause

No DMARC record

Publish this TXT record at _dmarc.example.com and nothing else:

p=none changes nothing about delivery. It satisfies the requirement and it starts the flow of aggregate reports, which is the only way you will find the fourth system that sends as you. If you would rather not run a mailbox that receives XML, point rua= at our weekly digest. Free for one domain.

Alignment

Alignment is the whole game and it is where people lose a day. SPF aligns when the envelope sender domain matches your From domain, which for most platforms means setting a custom return-path or MAIL FROM subdomain in their interface. DKIM aligns when the d= in the signature matches your From domain, which means completing the platform's domain authentication rather than sending from their shared keys. The per-provider pages have the exact records for each.

SPF over ten lookups

Drop includes for services you stopped using, move a heavy platform onto its own subdomain, and replace your own mail servers with ip4: literals. The ten-lookup guide has the full set of moves.

Propagation and when to retry

Publish the records, then wait for the old TTL to expire before you test. If the name had no record at all there is nothing cached and it is live in a minute or two. If you edited an existing record with a 3600 second TTL, give it the hour. Microsoft does its own caching on top of that, so a single test message is worth more than a resolver check.

Send one test to an Outlook mailbox first. Not the campaign. A 550 is permanent, so resending a large batch into the same rejection burns reputation you will want later, and it makes the next attempt slower rather than faster.