Why is Microsoft 365 rejecting my email with a 550 5.7.x error?

What does 550 5.7.1 mean on Microsoft 365?

550 5.7.1 is Microsoft's broadest "access denied" verdict: the receiving system accepted the connection but a policy stopped delivery. Per Microsoft's guidance for error 5.7.1 (which also covers everything from 5.7.0 to 5.7.999) it "typically indicates a security setting in your organization or the recipient's organization is preventing your message from reaching the recipient."

In practice it lands in one of a few buckets:

• A recipient or group restriction. The mailbox or distribution group only accepts mail from authenticated or internal senders, so an external message is refused. Only the recipient's admin can loosen that.
• A transport (mail flow) rule. A rule on either side matched your message and rejected it.
• Your IP is on Microsoft's blocklist. The diagnostics read Client host [x.x.x.x] blocked using Blocklist 1; To request removal from this list please forward this message to delist@microsoft.com. That is a reputation problem, not a rule problem, so start with a public blocklist check on the domain and see the delisting steps below.
• A broken SPF or MX record on your domain, which Microsoft explicitly lists as a cause on the 5.7.1 page.

Because the trigger varies, the diagnostics text is the deciding clue. A blocklist line means fix reputation; a RESOLVER.RST.AuthRequired line means the recipient requires authentication you cannot provide as an outsider.

Why does Microsoft return 5.7.23 or 5.7.509 for authentication failures?

Because Microsoft maps each authentication protocol to its own code, and knowing which one fired tells you exactly which record to fix. 5.7.23 and 5.7.509 are the two you will meet most.

550 5.7.23 The message was rejected because of Sender Policy Framework violation means the recipient checked SPF and your sending server was not on your domain's authorized list. Microsoft's NDR reference describes it as "the destination email system uses SPF to validate inbound mail, and an issue affects your SPF configuration." The usual cause is a new sending service (a CRM, ticketing tool, or marketing platform) that you never added to your SPF TXT record.

550 5.7.509 Access denied, sending domain does not pass DMARC verification and has a DMARC policy of reject is a DMARC rejection. Your 5322.From domain failed DMARC and, because your own published policy is p=reject, Microsoft honors that instruction and refuses the message. It is your policy doing exactly what you told it to. The problem is that a legitimate stream is not authenticating. This is the Microsoft counterpart to the code Gmail returns (550 5.7.26), and the same failure mode we cover for Gmail's 550 rejections.

The order of operations is the same for both: confirm which protocol is failing, fix the record, then confirm the passing domain aligns with your From domain. If you are new to how the three protocols interlock, our overview of email authentication sets the foundation before you touch DNS.

How do you fix a 550 5.7.x authentication rejection?

Work through the three protocols in order, then verify alignment. This sequence resolves the large majority of 5.7.23 and 5.7.509 bounces. For 5.7.515, use the exact Outlook.com high-volume procedure, which separately requires both SPF and DKIM to pass.

1. Publish a complete SPF record. Put every service that sends as your domain into a single SPF TXT record. One record only, since Microsoft rejects domains with multiple SPF records. Confirm it resolves and stays under the 10-lookup limit with Palisade's SPF checker. If you send through Google Workspace as well, our Google Workspace SPF guide shows how to merge senders into one record.
2. Enable DKIM signing. Turn on DKIM in each sending platform and publish the public key it gives you. Validate the signature with the DKIM checker. DKIM is the more resilient of the two because, unlike SPF, it survives most forwarding.
3. Publish a DMARC policy. Add a record at _dmarc.yourdomain.com, starting at v=DMARC1; p=none; rua=mailto:reports@yourdomain.com so you can watch reports before enforcing. Check syntax with the DMARC checker.
4. Confirm alignment. Make sure the domain that passes SPF or DKIM matches your visible From domain. This is where "everything is configured but Microsoft still bounces me" almost always resolves. See the next section.
5. Re-send and read the headers. Send a test to an Outlook.com or Microsoft 365 recipient, open the message source, and confirm spf=pass, dkim=pass, and dmarc=pass for your own domain.

Use the DNS lookup tool to confirm each record is actually published and propagated, and the MX record checker to rule out a routing problem masquerading as a policy one.

When should you use the exact 550 5.7.515 guide?

Use the exact guide when the NDR says 550 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level and the recipient is on Outlook.com, Hotmail, Live.com, MSN, or another Microsoft consumer service. This is not a generic Microsoft 365 tenant error.

Microsoft requires SPF and DKIM to both pass, a valid DMARC policy (p=none, p=quarantine, or p=reject) to exist, and DMARC to pass because SPF or DKIM aligns with the visible 5322.From domain. The 550 5.7.515 guide contains the message-header evidence template, alignment examples, and same-stream retest procedure; keep this page for classifying other 5.7.x codes.

Why does alignment decide whether your fix works?

Alignment is the rule that a passing SPF or DKIM check must belong to the same domain that appears in your From header. Without it, a spammer could pass SPF for a throwaway domain while forging your name, technically authenticated, completely fraudulent, so DMARC refuses to count an unaligned pass.

Two failure modes cause almost every "authenticated but still rejected" case:

• SPF authenticates the wrong domain. SPF validates the hidden Return-Path, which many platforms set to their domain, not yours. SPF passes for the platform but does not align with your From domain, so DMARC sees no aligned pass.
• DKIM signs with a mismatched domain. If the d= tag in the signature is your provider's domain rather than yours, the signature is valid but unaligned, the exact trap covered in why your DKIM signature fails alignment.

The durable fix is to authenticate on a subdomain you control, which keeps SPF and DKIM aligned under DMARC's default relaxed matching. A DMARC pass can clear 5.7.509; 5.7.515 additionally requires separate SPF and DKIM passes, so follow the exact-code test rather than assuming the two errors clear together.

Common issues with Microsoft 365 550 5.7.x rejections

The bounce says my IP is banned (5.7.511 or a blocklist line)

550 5.7.511 Access denied, banned sender (and the Blocklist 1 variant of 5.7.1) mean Microsoft has banned your sending IP, usually after spam complaints or a compromised account. Authentication alone will not clear it. Email delist@microsoft.com with the full NDR and IP address to request removal, as Microsoft's NDR reference directs. Then fix the underlying cause, because a delisting will not hold if the behavior repeats. Enrolling the IP in Microsoft's Smart Network Data Services shows you the complaint and trap data driving the reputation, and our guide to checking and improving domain reputation covers the recovery work.

Only mail through one service bounces

If your main platform delivers but one stream throws 5.7.23, that service is missing from your SPF record or is not DKIM-signing as your domain. Your DMARC aggregate reports name every source sending as you. Read them, then add the legitimate senders. This is the single most common reason a fix "works" for most mail but leaves one system bouncing.

550 5.7.520 blocks a forwarded message

550 5.7.520 Access denied, Your organization does not allow external forwarding is not an authentication problem at all. Microsoft's outbound anti-spam policy blocks automatic external forwarding by default as an exfiltration safeguard. Either stop the auto-forward rule, or have an admin enable external forwarding in the outbound spam policy, knowing that turning it on organization-wide weakens a real security control. Prefer a scoped policy over a blanket allow.

Everything authenticates but delivery is still slow

Passing authentication clears the block, not your reputation. If Microsoft throttled you during the outage or your complaint rate climbed, expect deferrals to ease over days of clean sending rather than instantly. If mail is queuing rather than bouncing outright, our guide to why email gets queued explains the difference.

For a provider-specific implementation of these authentication checks, see How do you enable DMARC for Microsoft 365?.

Related reading

• Why is Gmail rejecting my emails with a 550 error?
• Why is Yahoo blocking my emails as unauthenticated?
• Why is my email queued and how do I fix it?