What 550 5.1.0 Means
550 5.1.0 is a sender-class permanent rejection. In the Office 365 / Exchange Online context, it usually means Exchange's anti-spoofing layer rejected the sending address because it failed to authenticate against the claimed domain, or because the recipient tenant has a transport rule blocking your sending domain entirely. The 5.1.0 enhanced code is specifically about the sender's address being unacceptable.
Exchange Online and on-premises Exchange. The 5.1.0 variant with 'Sender denied' or 'Address rejected' text is Microsoft-specific.
Your sending domain is on a tenant-level block list at the recipient organization; the recipient tenant has anti-spoofing rules and your message failed DMARC; the From-header address uses a domain you're not actually authorized to send for; Directory Based Edge Blocking is enabled and your sender address isn't recognized; or a transport rule explicitly rejects mail from your domain.
How to Fix 550 5.1.0
- 1
Confirm DMARC alignment for your sending domain
Most 5.1.0 rejections from Exchange Online stem from anti-spoofing rules. Run the Email Deliverability Test at coldrelay.com/tools/email-deliverability-test to verify SPF, DKIM, and DMARC all pass and align with the From-header domain. Misalignment is the most common cause.
- 2
Check if your sending domain is on a recipient blocklist
If only one recipient organization is rejecting your messages with 5.1.0, they may have explicitly blocked your domain. Microsoft 365 tenants can add domains to a tenant-level allow/block list via the Microsoft 365 Defender portal. There's nothing you can do remotely — the recipient must remove the block. Reach out via an alternate channel (LinkedIn, phone) to ask for unblock.
- 3
Verify the From-header domain matches your sending infrastructure
Cold email setups sometimes mix domains — a marketing tracking domain in headers, a different sending domain in From, an entirely different domain in the signature. Exchange's anti-spoofing rules treat domain mismatches as suspicious. Standardize: From, Return-Path, and DKIM signing domain should all match (or align under DMARC's relaxed mode).
- 4
Test against a freshly-provisioned domain
If you're seeing widespread 5.1.0 rejections across multiple Microsoft 365 tenants, your domain may be on a Microsoft reputation list. Send a test from a freshly-provisioned ColdRelay sending domain (one with no prior history) to a Microsoft 365 inbox. If it delivers, your existing domain has reputation damage; if it doesn't, you have an infrastructure-level issue affecting multiple domains.
- 5
Use the Microsoft sender support form for delisting
If you suspect your IP or domain is on a Microsoft reputation list, submit a delisting request at sender.office.com/snds. Include your authentication setup (SPF, DKIM, DMARC results), recent sending history, and root-cause statement. Microsoft typically responds within 24-72 hours.
References
550 5.1.0 in the Cold Email Context
550 5.1.0 from Microsoft 365 is the most operationally consequential cold email rejection because Microsoft 365 represents 30-40% of B2B inbox share in the US. Tenant-level blocks compound: once a few tenants block your domain, others see the bounce pattern and treat your domain as suspicious. The infrastructure-side defenses are dedicated IPs (so other senders' bad behavior doesn't contaminate yours), strict DMARC alignment (so anti-spoofing rules pass cleanly), and a clean sending-domain history (so Microsoft's reputation database doesn't flag you). ColdRelay's domain provisioning sets all of this up correctly at day one; the Sends log surfaces Microsoft-specific 5.1.0 bounces separately from Gmail rejects so you can act on them with the right remediation.
Frequently Asked Questions
How is 5.1.0 different from 5.7.1 at Microsoft?
Both are policy rejections but at different layers. 5.1.0 is the sender-address layer (your sending domain or address is the problem). 5.7.1 is the broader policy layer (could be content, reputation, or DMARC). Microsoft uses both depending on which check fired.
Can I appeal a tenant-level block?
Not through Microsoft — tenant-level blocks are controlled by the recipient organization's admin. You need to contact the recipient organization directly (via an alternate channel) and ask them to remove the block. Common path: reach the recipient on LinkedIn, ask them to forward to their IT team.
Does Microsoft publish their sender reputation criteria?
Partially. SNDS (Smart Network Data Services) shows your IP's reputation tier (Green/Yellow/Red) and underlying metrics (spam-complaint rate, trap hits, sending volume). Microsoft doesn't publish exact thresholds, but the dashboard signals when you're approaching a problem.
Will a domain change fix 5.1.0?
If the issue is reputation on the current domain, yes — a fresh domain delivers cleanly while the old one is in penalty. But the new domain needs proper warmup and authentication, and if the original issue was infrastructure (shared IPs, bad SPF), the new domain will arrive at the same point in a few weeks.