Cold email infrastructure starting at $1/mailbox. Volume discounts down to $0.55.Calculate your cost
ColdRelay
554 5.7.1 overview
SMTP Error at Microsoft 365

554 5.7.1 at Microsoft 365

Tenant policy or gateway permanently rejected the message as spam

How to diagnose and fix 554 5.7.1 permanent spam rejections from Microsoft 365 recipients — distinguishing tenant mail flow rules, Defender policies, and third-party gateways, and what a sender can actually do about each.

Last updated: June 10, 2026


At Microsoft 365

How 554 5.7.1 Shows Up at Microsoft 365

How it appears

At Microsoft 365 the 554 5.7.1 family usually carries policy wording, e.g. "554 5.7.1 Message rejected due to content restrictions" or custom text written by the tenant's admin into a mail flow rule. When a third-party gateway (Mimecast, Proofpoint, Barracuda) fronts the tenant, the rejection comes from the gateway's hostname with its own phrasing — the recipient is on Microsoft 365, but Microsoft never saw the message.

Where you see it

In the permanent-failure NDR back to your sending mailbox. Check the receiving hostname in the bounce: *.protection.outlook.com means Exchange Online Protection or a tenant rule fired; a Mimecast/Proofpoint/Barracuda hostname means a security gateway rejected it before Microsoft's stack ran.

Why Microsoft 365 sends it

554 at Microsoft 365 recipients signals a deliberate, permanent policy decision rather than a borderline spam score: a Defender for Office 365 anti-spam policy set to reject, an entry in the Tenant Allow/Block List, a mail flow (transport) rule matching your message, or an upstream gateway verdict. Enterprise tenants — exactly the companies B2B cold email targets — are the most likely to run these stricter layers.

Resolution

How to Fix 554 5.7.1 at Microsoft 365

  1. 1

    Identify which layer rejected you from the NDR hostname

    Read the receiving server in the bounce. *.protection.outlook.com is Microsoft's stack (EOP/Defender/transport rule). A third-party hostname is a security gateway — in that case the fix path belongs to that gateway's reputation system, not Microsoft's, and Microsoft-side remediation won't help.

  2. 2

    Separate one-tenant blocks from systemic rejections

    Group your bounces by recipient domain. 554 5.7.1 confined to a single company = that tenant's policy (often a Tenant Allow/Block List entry or transport rule naming your domain — effectively a do-not-contact signal). The same 554 across many unrelated tenants = your domain or IP is on a reputation feed those tenants share, and you have a systemic problem worth stopping sends to investigate.

  3. 3

    Fix the signals enterprise filters check first

    Confirm spf=pass, dkim=pass, dmarc=pass with alignment on a test message; check the sending IP and domain against major blocklists; verify reverse DNS resolves cleanly. Enterprise policy layers consume these signals more strictly than consumer filters — a DMARC policy of p=none on your sending domain reads as a risk marker to Defender-tier filtering.

  4. 4

    Respect explicit blocks instead of engineering around them

    A tenant that has written your domain into a block rule has made a decision. Rotating domains to re-reach a company that deliberately blocked you invites complaint-driven escalation that damages the new domain too — and in most jurisdictions sits poorly with anti-spam law. Suppress the domain from your lists and pursue named accounts through another channel.

    Note: This is also the canonical reason to keep cold outreach on dedicated secondary domains: an enterprise block on an outreach domain is absorbable; the same block on your primary company domain is not.

  5. 5

    If Microsoft's own stack blocked the IP, use the delist portal

    When the NDR text indicates Microsoft blocked your sending IP itself (rather than a tenant rule), request removal via Microsoft's sender delist portal after fixing the underlying cause. Delisting without fixing volume, authentication, or list quality gets re-listed quickly.

Diagnostics

Microsoft 365 Tools for This Error

Cold email infrastructure

554 5.7.1 at Microsoft 365 in the Cold Email Context

For cold senders, 554 5.7.1 from Microsoft 365 tenants is the sharpest deliverability signal there is: a permanent, deliberate rejection — and at enterprise tenants it often means your domain has landed on a shared block feed or a tenant's explicit list. The operational playbook is containment: keep outreach on dedicated secondary domains so a hard block never touches the company's primary domain, watch bounce patterns per recipient domain, and suppress deliberate blockers. ColdRelay's infrastructure is built for exactly this containment — isolated Azure tenants with dedicated IPs per customer, pre-configured SPF/DKIM/DMARC, and a 4 sends/day per-mailbox budget (2 outbound + 2 warmup) that keeps sending behavior out of the velocity bands enterprise filters punish.

FAQ

Frequently Asked Questions

What's the difference between 550 5.7.1 and 554 5.7.1 from Microsoft 365?

Both are permanent policy rejections, but in practice 550 5.7.1 at Microsoft 365 usually comes from EOP's scoring (reputation or content verdicts that can shift), while 554 5.7.1 more often reflects a deliberate policy layer — a tenant rule, a Defender reject action, or a security gateway. Treat 554 as 'a decision was made' rather than 'the filter scored you borderline.'

The bounce came from a Mimecast or Proofpoint hostname — is this still a Microsoft 365 problem?

No. The recipient hosts mail on Microsoft 365, but a security gateway in front of the tenant rejected you before Microsoft's stack ran. Your reputation with that gateway vendor is what matters — check the gateway's own sender/IP reputation portal, and note that one gateway verdict often affects every customer of that vendor on your list.

Can I get a tenant to unblock my domain?

Only that tenant's administrator can, via the Tenant Allow/Block List or by editing the mail flow rule that names you. If you have a genuine relationship with someone at the company, ask them to raise it with IT. If you don't, the block is your answer — suppress and move on.

Does ColdRelay help with 554 5.7.1 rejections?

It contains them. Dedicated secondary domains on isolated Azure tenants with dedicated IPs mean a hard enterprise block lands on an outreach identity, never your primary domain, and per-mailbox sending stays at 4/day (2 outbound + 2 warmup) — below the volume patterns that put senders on shared block feeds. What it deliberately doesn't do is help you evade a tenant that chose to block you; that block is feedback about targeting.

Keep reading

Related Guides

Stop Seeing 554 5.7.1 From Microsoft 365

ColdRelay provisions cold email infrastructure on isolated Azure tenants with dedicated IPs — SPF, DKIM, DMARC, and reverse DNS configured automatically, the same fixes that resolve most 554 5.7.1 bounces at Microsoft 365.

Get Started →