Emails bounce with a Mimecast Anti-Spoofing policy error because Mimecast thinks the message is claiming to be from a protected domain, subdomain, or similar domain, but the route, sender IP, SPF result, DKIM signature, or header pattern does not match what Mimecast has been told to trust. The bounce often happens at Mimecast's SMTP edge, so the recipient's mail server never sees the message and there is no mailbox-side queue entry to inspect.
The practical fix is to do two things in parallel: authenticate the sender properly and add a precise Mimecast Anti-Spoofing exception for the legitimate sender, IP, or sending platform. I treat this as an inbound security policy problem first, then verify SPF, DKIM, and DMARC so the exception is not hiding a real authentication gap.
- Fast answer: Create or correct the Mimecast Anti-Spoofing policy so it takes no action for the legitimate sender address, envelope sender, domain, or source IP.
- Root cause: The sender looks like it belongs to the recipient's organization, but it is entering through an external source Mimecast does not trust.
- Do not skip DNS: Check SPF on the EHLO or HELO domain, DKIM on the visible sending domain, and DMARC on the Header From domain.
Why Mimecast rejects before the mailbox
The most confusing part of this bounce is that the recipient often says the email never reached their system. That is usually correct. Mimecast can reject the SMTP transaction before delivery to the downstream mail server. The rejection message then travels back to the sending platform as a 550 permanent failure.
Common bounce texttext
550 Rejected by header based Anti-Spoofing policy The message has triggered an Anti-Spoofing policy. Create an Anti-Spoofing policy to take no action for the sender or IP.
Header based anti-spoofing is not the same thing as a blocklist or blacklist rejection. A blocklist bounce points to reputation or listing data. This bounce points to a policy decision: Mimecast sees a protected identity in the message headers and does not trust the path the message used to arrive.
The important clue
When the sending system uses the customer's own domain or subdomain in the visible From address, Mimecast treats that as a high-risk pattern unless the sender has been explicitly authorized. This is common with CRMs, marketing platforms, ticketing tools, billing systems, and test environments that send on behalf of a customer domain.
Mimecast's own Mimecast article points toward an anti-spoofing policy path for this class of issue. The exact admin screen and policy wording varies by Mimecast tenant, but the operational idea is consistent: create a specific exception for legitimate traffic instead of weakening anti-spoofing globally.
Mimecast Anti-Spoofing policy screen with sender and action fields.
The causes I check first
I start with the exact identity Mimecast is protecting. If the visible From domain, a subdomain, or a lookalike domain belongs to the recipient's organization, Mimecast can treat the message as an external attempt to impersonate that organization. That is true even when the sender is a legitimate application.
|
|
|
|---|---|---|
External subdomain | From domain | Allow sender or IP |
SPF mismatch | EHLO domain | Fix SPF |
DKIM missing | DKIM result | Enable signing |
NAT routing | Source IP | Allow public IP |
Wrong scope | Policy order | Move policy |
High-signal causes behind the Mimecast 550 anti-spoofing bounce.
One detail is easy to miss: some Mimecast handling depends on the EHLO or HELO identity used during the SMTP session, rather than only the Return-Path domain that DMARC tooling tends to emphasize. If SPF passes for the bounce domain but fails for the EHLO domain, the message still looks wrong to the inbound filter.
Looks legitimate to the sender
- Sender view: The platform has permission to send using the customer's domain.
- DNS view: SPF and DKIM look acceptable in the platform's setup screen.
- Test view: The message works when sent to personal inboxes or non-Mimecast recipients.
Looks suspicious to Mimecast
- Inbound view: The message claims a protected internal identity from the internet.
- Policy view: No Anti-Spoofing exception matches the sender, IP, or recipient scope.
- Routing view: The source IP or EHLO name differs from the approved route.
Evidence quality before changing policy
Use the strongest evidence available before adding a Mimecast exception.
Ready to allow
Low risk
Known sender, known IP, matching domain, and passing authentication.
Fix DNS first
Medium risk
Sender is known, but SPF, DKIM, or DMARC has a clear defect.
Escalate
High risk
Unknown route, unknown IP, or no clean message sample.
How to prove the exact failure
Before changing Mimecast, collect the evidence that tells you whether this is only a policy exception problem or also an authentication setup problem. The key is to compare the identity in the visible From header with the envelope sender, DKIM signing domain, EHLO domain, source IP, and recipient route.
Flowchart for investigating a Mimecast anti-spoofing bounce.
- Capture the bounce: Save the 550 text, timestamp, sender, recipient, and Mimecast reference ID if one appears.
- Send outside Mimecast: Send the same test to a mailbox that does not use Mimecast and inspect the full headers.
- Check authentication: Confirm SPF, DKIM, and DMARC pass for the domains that appear in the real message.
- Compare IPs: Compare the observed public source IP with the IP range the Mimecast tenant has allowed.
- Review policy scope: Check whether the exception applies to the right internal recipients and is above stricter rules.
For the DNS side, I use a domain-level check before I touch the security policy. Suped's domain health tool is useful here because it checks DMARC, SPF, and DKIM together instead of forcing you to inspect each record in isolation.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
If you need a focused DMARC record check, use the DMARC checker after you identify which Header From domain is being evaluated. A clean DMARC result does not automatically bypass Mimecast Anti-Spoofing, but a broken DMARC result makes the case for an allow policy weaker.
Authentication data to collecttext
Header From: alerts.example.com Envelope From: bounce.mailer.example.net DKIM d=: alerts.example.com EHLO: mta01.mailer.example.net Source IP: 203.0.113.25 Mimecast result: 550 Anti-Spoofing policy
How to fix the Mimecast policy
The safe fix is narrow. Do not turn off Anti-Spoofing for the whole organization. Add a policy that matches the legitimate sender and route, then set the action to take no action or otherwise allow only that expected traffic.
Policy settings that usually matter
- Sender scope: Use the exact sender address first, then widen to a domain only when the sending pattern is stable.
- IP scope: Use the sending platform's documented outbound IPs or the observed public source IP.
- Recipient scope: Limit the rule to the affected internal domain, group, or mailbox set when possible.
- Action: Set the policy to take no action for this legitimate sender instead of disabling protection.
- Order: Place the exception where it runs before the broader rejection rule that caught the message.
If a policy override did not help, I check three things: whether the rule used the wrong sender identity, whether the source IP was different because of NAT or a shared sending pool, and whether the rule order meant a stricter policy still matched first. The right exception often fails the first time because the administrator allowed the friendly From address while Mimecast matched another identity or IP.
Example SPF recorddns
example.com TXT "v=spf1 include:esp.example.net -all"
Example DMARC monitoring recorddns
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:reports@example.com"
Keep DMARC at p=none while you are proving the sender set, then move toward enforcement once legitimate sources are passing. Suped's Hosted DMARC workflow helps teams stage policy changes without repeated DNS edits.
How Suped fits into the fix
Suped does not replace the need to configure Mimecast. Mimecast is the system rejecting the SMTP transaction, so the allow policy has to be fixed there. Suped helps with the part that usually slows this down: proving which sources are legitimate, finding SPF or DKIM defects, and showing which domains are ready for stronger DMARC.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For most teams, Suped is the best overall DMARC platform for this workflow because it combines DMARC monitoring, SPF and DKIM checks, hosted SPF, hosted MTA-STS, blocklist and blacklist monitoring, real-time alerts, and issue-specific fix steps in one place. That matters when the same bounce can involve Mimecast policy, sender DNS, and routing at the same time.
Manual investigation
- Evidence: Headers, DNS lookups, admin screenshots, and bounce logs sit in separate places.
- Risk: A broad allow rule can hide an authentication problem that still affects other recipients.
- Pace: Each new sender requires another round of DNS and header checks.
Suped workflow
- Evidence: Authenticated and failing sources are grouped by domain and sender.
- Risk: Issue detection shows whether DNS should be fixed before Mimecast is changed.
- Pace: Hosted DMARC and hosted SPF reduce repeated DNS handoffs.
When to contact Mimecast
Contact Mimecast support when the tenant administrator cannot identify which policy fired, the expected allow policy does not match, or the rejection references header lockout behavior that is not visible in the normal policy list. Before opening the case, collect enough detail that support can reproduce the lookup path.
Case packet to send
- Bounce data: Include the full 550 text, Mimecast reference ID, sender, recipient, and timestamp.
- Routing data: Include the public source IP, EHLO name, sending platform, and expected route.
- Policy data: Include the Anti-Spoofing exception, its scope, action, and policy order.
- DNS data: Include SPF, DKIM, and DMARC results for the domains in the failed message.
I also ask the recipient's mail administrator to confirm whether the test message is entering Mimecast from the expected public internet route. If the MTA is on the same network, a NAT path or internal relay can produce a source IP the policy never anticipated. When headers show the expected public IP, that route becomes less likely and the investigation should return to sender identity and policy scope.
Views from the trenches
Best practices
Verify the visible From domain and source IP before adding any Mimecast exception.
Test the same message outside Mimecast so headers reveal SPF, DKIM, and EHLO results.
Scope allow policies tightly, then retest with the exact sender and recipient pair.
Common pitfalls
Allowing the From address alone misses cases where Mimecast matches the source IP.
Ignoring EHLO SPF can leave a real authentication gap after Return-Path SPF passes.
Treating the bounce as mailbox delivery hides that Mimecast rejected at SMTP edge.
Expert tips
Ask support for the matching policy name when the admin console does not show it.
Document every approved third-party sender before moving DMARC toward enforcement.
Use DMARC reports to separate legitimate senders from spoofing before allowlisting.
Marketer from Email Geeks says an Anti-Spoofing policy can reject a test before it reaches the recipient queue, so the absence of mailbox logs does not prove the sender never connected.
2020-11-24 - Email Geeks
Marketer from Email Geeks says creating an Anti-Spoofing policy that takes no action for the correct sender or IP is the normal fix, but scope and policy order have to be checked.
2020-11-24 - Email Geeks
The practical fix
A Mimecast Anti-Spoofing bounce is not solved by proving that the email platform is legitimate in general. It is solved by proving that this exact sender, domain, IP, and route are legitimate for this recipient, then making Mimecast recognize that fact with a narrow policy exception.
The order of work matters: capture the bounce, verify DNS, inspect the EHLO and source IP, fix SPF or DKIM defects, add the Mimecast exception, then retest. If Mimecast still rejects the message, send support the reference ID and policy details instead of guessing which hidden rule fired.
