How is this different from the header based rejection?

This one judges the hidden envelope sender. The header based rule judges the From line people see. A message can trip either one or both.

Who receives this bounce?

The envelope sender, which by definition is an internal address here, so it often lands in an unmonitored mailbox. Check that mailbox when an app’s alerts silently stop.

Mimecast: Anti-Spoofing policy, Inbound not allowed

550 Anti-Spoofing policy - Inbound not allowedMimecast envelope anti-spoofing rejectionPermanent: retrying will not helpFrom Mimecast

Example

550 Anti-Spoofing policy - Inbound not allowed

What it means

This variant of Mimecast’s anti-spoofing protection looks at the envelope sender, the address given in the SMTP MAIL FROM command, which ends up as the Return-Path. If that address uses one of the customer’s internal domains and the connection came from outside, Mimecast treats the message as an inbound spoof and refuses it with this 550.

The envelope sender is invisible to most users, which makes this one confusing. A message can show an external From and still trip the rule because its bounce address uses the company domain. The opposite case, where the visible From is internal, is the header based rejection.

In practice it often catches the organization’s own systems: an on-premises application server, a website, or a backup appliance that sends to colleagues by connecting to the public MX, which is Mimecast, rather than through the internal mail server or Mimecast’s authenticated outbound route.

Likely causes

An internal application delivers to the public MX record with a return path on the company domain.
A web server at a hosting company sends contact form mail with the company domain as the envelope sender.
Mail forwarded back into the organization by an outside system that keeps the internal bounce address.
A third-party sender that was never configured with its own return path domain.

How to fix it

Find the connecting IP in the bounce or in Mimecast’s message tracking, then identify the system behind it.
Reconfigure internal systems to relay through the company mail server or Mimecast’s outbound gateway with authentication, instead of the inbound MX.
For external services, set a return path on their own domain or a dedicated subdomain such as `bounce.example.com` with its own SPF record.
Where a route cannot change, the Mimecast admin adds a narrow anti-spoofing bypass for that source IP or for senders that pass SPF.

Checks that apply

Your domain or sending IP (fills in the checks below)

SPF Check Checks whether the source system’s IP is in the domain’s SPF record before anyone writes a bypass that relies on it.
MX Lookup Shows that the domain’s MX points at Mimecast, which explains why an internal app hitting the MX is seen as external.
SMTP Diagnostics Lets you see the Mimecast banner your internal system would reach, confirming which path the mail took.

FAQ

How is this different from the header based rejection?: This one judges the hidden envelope sender. The header based rule judges the From line people see. A message can trip either one or both.
Who receives this bounce?: The envelope sender, which by definition is an internal address here, so it often lands in an unmonitored mailbox. Check that mailbox when an app’s alerts silently stop.

All 191 bounce codes