A Custom Mail Flow Rule Has Blocked Your Message: Complete Fix

Short answer: This is not spam filtering and it is not a blocklist. A named administrator wrote a deliberate rule, and the rule - not a reputation score - decided to reject your message. The fix depends entirely on whose organization wrote the rule: if it is the person you are emailing, only their own IT team can change it. If it is your own company's rule blocking your own outbound mail, your own admin can fix it directly.

• If the tenant named in the rejection is the person you are trying to reach: you cannot edit their rule. Go straight to what a sender can actually do.
• If the tenant named is your own company: your own admin can find and fix this today - see the admin sections below.
• If an attachment triggered this: the file-type and size variants are covered specifically, since they behave a little differently from a content-triggered rejection.
• If you think this might actually be a blocklist or spam-scoring rejection instead: the wording tells you which. A message naming a mail flow rule is never a reputation problem - if you are unsure which you are looking at, compare your exact rejection against Outlook blocking your emails.

This Is a Rule, Not a Spam Filter

Most Microsoft rejections in this guide series come down to reputation, authentication, or a spam-confidence score - probabilistic systems making a judgment call about a message they have never seen before. This one is different, and recognizing the difference saves real time. A rejection naming a custom mail flow rule is deterministic: someone wrote a specific instruction ahead of time, your message matched its conditions exactly as written, and the rejection is that rule doing precisely what it was configured to do. There is no reputation to rebuild and no authentication to fix, because neither of those is what stopped the message.

The wording is distinctive enough to recognize on sight: a message stating plainly that a custom mail flow rule created by an admin at a named organization has blocked your message, followed by a reason - commonly that it violates a security policy. If you are looking at exactly that, you are dealing with a mail flow rule, sometimes called a transport rule, and this guide covers reading it correctly, identifying whose rule it is, and what each side of the conversation can actually do about it.

This is a genuinely different failure mode from anything covered in the hard-block or reputation guides elsewhere in this library, so if authentication and blocklist fixes have not helped with a message carrying this specific wording, that is expected - none of those fixes touch a written rule.

Reading the Exact Rejection Message

When a mail flow rule rejects your message, you receive a non-delivery report back from the recipient's mail system, generally arriving from a postmaster address with a subject along the lines of Undeliverable, followed by your original subject line. Most mail apps show you a friendly summary of this by default and hide the full technical detail underneath, so the first useful step is finding the complete version.

Look for an option along the lines of View message source, Show original, or Show details, depending on your mail client. The full version contains three things worth reading carefully:

• The plain-language explanation, which is the part naming the mail flow rule and stating it was created by an admin at a specific organization - usually shown as that organization's domain, sometimes in the form of an onmicrosoft.com address that reveals the tenant even when their public-facing domain is something else.
• The stated reason, which is whatever text the admin who wrote the rule chose to include. This varies by organization - some name a security policy in general terms, others reference a specific category like attachment restrictions or content matching.
• The status code, covered in detail next, which confirms mechanically that this is a rule rather than a spam or reputation decision.

Save or copy the full text before doing anything else. If you end up asking anyone - your own admin, or the recipient - to investigate, the complete rejection text is what lets them find the specific rule quickly instead of searching blind.

What 5.7.1_ETR Actually Tells You

Mail flow rule rejections carry the enhanced status code 5.7.1 by default, sometimes shown with a distinguishing suffix such as 5.7.1_ETR. That suffix is worth knowing on its own, because it is Microsoft's own internal confirmation of exactly what caused the rejection: ETR stands for Exchange Transport Rule, the same feature this guide calls a mail flow rule. Seeing that suffix is definitive - it tells you, without any ambiguity, that a written rule caused this and not a spam filter, not a blocklist, and not a reputation score.

That single piece of information changes what you should do next. A 5.7.1 code without the ETR marker, or a 5.7.606 code, generally points toward the reputation and authentication territory covered in Outlook blocking your emails - fixing SPF and DKIM, checking blocklists, requesting delisting. None of that applies here. A rule fired exactly as written, and rewriting your DNS records will not change a single character of that rule.

Administrators writing these rules can set the enhanced status code themselves within a defined range, and can write fully custom explanation text alongside it, which is exactly why the wording you see can vary meaningfully between two organizations even though the underlying mechanism - and the 5.7.1 code family - is identical.

Whose Rule Is This? Identifying the Tenant

The organization named in the rejection - the domain following "an admin at" - tells you which company's mail flow rules are in play, and that single fact determines everything about what happens next. There are two possibilities, and they call for opposite responses.

If the domain named is unfamiliar or does not obviously match either party, it is very often the onmicrosoft.com tenant name behind a company's actual public domain - every Microsoft 365 tenant has one of these even if nobody at the company uses it day to day, and it is what mail flow rule rejections frequently surface instead of the domain you would recognize from their website or email address.

What a Mail Flow Rule Actually Is

A mail flow rule, also called a transport rule, is a conditional instruction an administrator configures for their own Exchange Online organization: when a message matches a defined set of conditions, take a defined action. Conditions can match on almost anything about a message - the sender's address or domain, words or patterns in the subject or body, whether an attachment is present, an attachment's file type, or a message's overall size. Actions range from something as mild as adding a disclaimer, through routing changes, all the way to outright rejecting the message and generating exactly the NDR this guide is about.

Organizations write these rules for reasons that have nothing to do with your reputation as a sender and everything to do with their own internal policy: keeping specific file types out entirely, preventing sensitive information from leaving or entering the organization, blocking known-bad domains, or enforcing a security requirement that has nothing to do with how trustworthy your mail server is. A perfectly clean sender with flawless authentication and reputation can still be rejected by a rule like this, because the rule was never evaluating any of that in the first place.

Why Admins Write Rules Like This

Understanding the common categories helps you guess, often correctly, what triggered a specific rejection even before anyone confirms it.

• Data loss prevention. Rules that scan outgoing or incoming content for patterns resembling sensitive data - identification numbers, payment card numbers, specific confidential-sounding phrases - and block the message rather than let it through unexamined.
• Sender or domain blocking. A rule naming a specific address, domain, or even a whole category of domains an organization has decided not to accept mail from, sometimes added after a previous incident.
• Content and keyword matching. Rules that reject messages containing specific words or phrases, often tuned to catch phishing language, impersonation attempts, or terms tied to a known internal problem.
• Attachment restrictions. Covered in full in the next section, and one of the most common single categories of mail flow rule in active use anywhere.
• Message size limits. Also covered in its own section below, and easy to mistake for a platform-wide limit when it is actually an organization's own additional restriction.

None of these categories are visible to you as the sender from the outside. The rejection text is often your only real clue, which is exactly why reading it carefully and completely, as covered earlier, matters more here than in almost any other failure mode in this guide series.

The Attachment-Type Variant

Attachment-based mail flow rules are extremely common, and for good reason - certain file types are a genuine, long-standing vector for malware, so blocking them at the mail flow layer rather than relying on scanning alone is standard practice across most organizations. Typical restricted categories include executable files, script files, and certain compressed or container formats that could hide a restricted file type inside.

Two details commonly surprise people:

• Renaming a file extension does not reliably help, and should not be relied on as a workaround, because content-aware rules can inspect what a file actually is rather than trusting its name. Some simpler rules do trust the extension, but treating this as a dependable bypass is unwise and, more importantly, treats a legitimate security control as an obstacle rather than a real requirement worth respecting.
• Password-protected or encrypted archives are frequently blocked entirely, for a much simpler reason than content matching: a scanning system cannot see inside an archive it cannot open, so many organizations block anything it cannot inspect by default, on the reasonable assumption that mail nobody can verify the safety of is not worth the risk of allowing through.

The reliable path around an attachment-type rejection, when the file is legitimate, is not disguising the file - it is not attaching it directly at all. Share it through a link to a service you both already trust, or ask the recipient's own team what format they can actually receive, since they know their own rule's exact restrictions far better than you can guess from the outside.

The Message-Size Variant

Message and attachment size limits exist at more than one layer simultaneously, and a mail flow rule can add a further, organization-specific ceiling on top of whatever general platform limit already applies. This means two different senders emailing the same recipient's organization can hit two different effective limits depending entirely on what that organization's own admin decided to layer on - one general platform ceiling, and potentially one narrower rule-based ceiling underneath it.

Because the actual number varies by organization and by plan, and because Microsoft's own general limits have changed over time, do not plan around a specific figure quoted anywhere, including this page. If a rejection specifically cites size as the reason, the practical fix is the same regardless of the exact number involved: do not keep resending the same file expecting a different outcome, since a size-based rule is exactly as deterministic as any other mail flow rule. Compress if that genuinely helps, but more reliably, move to a shared link instead of an attachment - it sidesteps the size question for both the platform default and any organization-specific rule sitting on top of it.

When It's the Recipient's Own Tenant Rule

This is the more common of the two scenarios from the earlier table, and it is worth being direct about the limit: if the organization named in the rejection is the person or company you are trying to reach, nothing you can do reaches into their tenant and edits their rule. That configuration lives entirely inside their own Microsoft 365 organization, under their own administrator's control, and no amount of fixing your own authentication, reputation, or sending pattern touches it, because none of those were ever what the rule was evaluating.

What is genuinely available to you is covered in full in the next section - modifying what you send so it no longer matches the rule's conditions, or asking the recipient's own organization to make an exception for you specifically. Both are real, workable paths. Neither involves anything on your own sending infrastructure.

What a Sender Can Actually Do

Work through these in order. The first two are things you control directly; the third depends on the recipient's cooperation.

1. Modify the message to remove whatever triggered the match, if you can identify it from the rejection text. Remove or replace an attachment, rephrase content that might match a keyword-based rule, or restructure the message entirely if the trigger is unclear.
2. Switch delivery method for anything attachment or size related. A shared link instead of a direct attachment avoids both the file-type and size categories of rule at once, and is often the fastest fix available to you unilaterally.
3. Contact the recipient through a different channel - a phone call, a message on another platform, or a colleague's email address - and explain what happened, including the full rejection text. Ask them to raise it with their own IT team as a request to allow your specific address or domain through the rule.
4. Do not simply resend the same message repeatedly. A mail flow rule rejection is not a transient failure the way a temporary 4xx deferral is - the rule will match again every time under the same conditions, and retrying accomplishes nothing except generating more identical rejections.

Giving the recipient the complete, exact rejection text - not a paraphrase - is the single most useful thing you can hand them. It is what lets their IT team find the specific rule quickly instead of searching through every mail flow rule the organization has configured.

What the Admin Can Do: Message Trace

If you are the administrator on either side - your own organization's outbound rule blocked your user, or a partner is asking you to investigate an inbound rejection - message trace is the direct path to an answer instead of guessing from the rejection text alone.

In the Exchange admin center, message trace lets you search for a specific message by sender, recipient, and date range, and view exactly what happened to it as it moved through your organization's mail flow, including which specific rule evaluated and acted on it. This removes the guesswork entirely: rather than inferring which rule fired from a generic reason string, you can see the actual rule by name, along with the specific condition that matched.

This is meaningfully faster than reading rule definitions one at a time trying to guess which one applies, especially in an organization with more than a handful of mail flow rules configured, which is the normal case for anything beyond a very small company.

What the Admin Can Do: Fixing the Rule Itself

Once message trace has identified the specific rule, an administrator has several ways to adjust it, and which one is appropriate depends on why the rule exists in the first place.

• Narrow the conditions. If a rule is catching more than intended - a keyword match firing on legitimate business language, or a domain rule written more broadly than needed - tightening the condition is often the cleanest fix.
• Add a specific exception for the sender or domain in question, covered in more depth in the next section, rather than loosening the rule's general conditions for everyone.
• Change the action instead of the conditions. A rule set to reject outright can sometimes be changed to a softer action for borderline cases - adding a warning, notifying an administrator for review, or applying a disclaimer rather than blocking outright - if outright rejection turns out to be stricter than the situation actually calls for.
• Test before deploying a change. Exchange mail flow rules generally support a test mode that evaluates matches and logs what would have happened without actually rejecting anything, which is the safer way to confirm a change behaves as intended before it affects real mail.

Whatever the fix, confirm the change actually reaches production and is not left in a test-only state, since a rule that only logs and never enforces provides no actual security benefit if that was not the intention.

Building Exceptions Instead of Disabling the Rule

When a legitimate sender keeps getting caught by a rule that is otherwise doing its job correctly, the right response is almost never to disable or loosen the rule generally - that gives up whatever protection it was providing for every other message, not just the one you are trying to fix. The better approach is a narrow, explicit exception.

• Add a specific sender or domain exception to the rule's conditions, scoped as tightly as the situation allows - a full email address rather than a whole domain where possible, and a whole domain rather than a broad pattern where an address is not practical.
• Document why the exception exists. A rule with an unexplained exception added months ago is exactly the kind of thing that gets removed accidentally during a later cleanup, or left in place long after the reason for it stopped applying.
• Review exceptions periodically rather than letting them accumulate indefinitely. An exception list that only ever grows eventually undermines the rule it is attached to as thoroughly as disabling the rule outright would have.
• Keep the exception scoped to the specific problem. An attachment-type exception for one trusted sender should not also quietly exempt them from a separate content-matching rule unless that is genuinely intended.

Preventing This With WarmySender

Be direct about what this guide covers: a deliberate, written decision by an administrator at the recipient's own organization, evaluated against rules WarmySender cannot see, has no relationship with, and has no way to negotiate on your behalf. No sending tool reaches into another company's mail flow configuration, and treating this as a reputation or deliverability problem that warmup or pacing could solve would be dishonest - it is neither of those things.

What WarmySender does control is everything on your own side of the relationship: cold email campaigns with per-mailbox daily sending caps and paced sending, peer-to-peer email warmup for new mailboxes and domains, inbox rotation, mailbox health monitoring, and list verification before you send. Keeping that side clean matters for every other failure mode in this guide series - reputation, junk placement, hard blocks - even though none of it touches a specific, deliberately written mail flow rule at someone else's company.

When you hit a rejection with this exact wording, the productive next step is the sender playbook earlier in this guide: modify what triggered it, switch delivery method, or ask the recipient to raise an exception with their own team. See how WarmySender works.