I am the SaaS vendor. Can I fix this myself?

Only partly. You can make sure your mail passes SPF and DKIM for the customer’s domain, but the customer’s Mimecast admin must create the policy exception.

Does publishing SPF alone stop the rejection?

Not by default. The anti-spoofing policy still applies unless the admin enables a bypass that uses the SPF result.

Mimecast: Rejected by header based Anti-Spoofing policy

550 Rejected by header based Anti-Spoofing policyMimecast header based anti-spoofing rejectionPermanent: retrying will not helpFrom Mimecast

Example

550 Rejected by header based Anti-Spoofing policy

What it means

Mimecast runs an anti-spoofing check on inbound mail: an external server should not be sending messages that claim to come from the customer’s own domain. The header based version looks at the From header that people see in their mail client. If that header shows an internal domain and the message arrived from the internet, Mimecast refuses it with this 550 line.

The rule exists to stop CEO fraud and fake internal notices. The side effect is that legitimate services which send as the company, such as payroll platforms, CRM systems, scanner-to-email devices, and newsletter tools, get caught when they deliver straight to Mimecast instead of through the company’s own outbound path.

The bounce goes back to the sending service, but the fix nearly always sits with the Mimecast customer, because only they can change the policy. The envelope based version, which looks at the SMTP MAIL FROM instead, has its own page.

Likely causes

A SaaS tool sends invoices or alerts with From set to the customer’s domain, from the tool’s own servers.
A multifunction printer or line-of-business app sends through an external relay with an internal From address.
An attacker really did try to spoof the domain, and the policy worked as designed.
A new service was added without updating the domain’s SPF record or the Mimecast exceptions.

How to fix it

Identify which service sent the message from the bounce and its Received headers, and confirm that it is legitimate.
Authorize that service in the domain’s SPF record, for example `v=spf1 include:spf.protection.outlook.com include:_spf.example.net -all`, and set up DKIM signing for it.
In the Mimecast administration console, the customer’s admin adds a bypass to the anti-spoofing policy for that specific source; Mimecast offers an SPF-based bypass option so only senders that pass SPF are exempt.
Prefer routing the service through the organization’s own outbound mail path where possible, so it never looks like external mail.
Never exempt the whole domain from anti-spoofing; keep exceptions narrow to one IP range or one authenticated sender.

Checks that apply

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

SPF Check Shows whether the third-party service’s servers are covered by the domain’s SPF record, the basis for a safe bypass.
DKIM Check Confirms the service signs with a selector published in the company domain, which makes the exception easier to trust.
Email Header Analyzer Reveals the true originating server of a refused message so you can tell a real service from an attacker.

FAQ

I am the SaaS vendor. Can I fix this myself?: Only partly. You can make sure your mail passes SPF and DKIM for the customer’s domain, but the customer’s Mimecast admin must create the policy exception.
Does publishing SPF alone stop the rejection?: Not by default. The anti-spoofing policy still applies unless the admin enables a bypass that uses the SPF result.

All 191 bounce codes