Why are emails bouncing with Mimecast Anti-Spoofing policy and how to fix?
Matthew Whittaker
Co-founder & CTO, Suped
Published 16 Jun 2025
Updated 15 Aug 2025
6 min read
I've often seen situations where emails bounce with a specific Mimecast anti-spoofing policy error, typically presenting as "550 Rejected by header based Anti-Spoofing policy." This is particularly frustrating because it often means the email isn't even reaching the recipient's internal queue for further processing, being rejected outright by Mimecast's initial security layers.
Mimecast's anti-spoofing mechanism is designed to protect your domain from unauthorized senders pretending to be you or a trusted contact. While crucial for security, it can sometimes block legitimate emails sent via third-party services, leading to unexpected delivery failures.
Understanding why these bounces occur and how to configure your email setup and Mimecast policies correctly is essential for maintaining strong email deliverability and ensuring your important messages reach their intended recipients.
Mimecast anti-spoofing is a robust security feature that acts as a gatekeeper, preventing fraudulent emails from entering your organization's network. It scrutinizes incoming messages to ensure they genuinely originate from the domains they claim to represent.
The core principle is to prevent "spoofing," where malicious actors forge email headers, particularly the "From" address, to impersonate legitimate senders. Mimecast achieves this by comparing the sender's actual origin, such as an IP address or sending domain, against its internal records and configured policies for your domain.
When Mimecast detects an email that appears to be from your internal domain but originates from an unapproved external source, it triggers an anti-spoofing policy. This often happens when you use third-party email service providers (ESPs) or other systems to send transactional or marketing emails on behalf of your domain.
Common reasons for the 550 bounce
The "550 Rejected by header based Anti-Spoofing policy" error typically points to a conflict between Mimecast's security settings and how your emails are being sent. One of the most frequent culprits is sending emails that appear to be from your own domain but are actually sent through a third-party service, like a CRM or an email marketing platform.
Mimecast's anti-spoofing measures often check the EHLO domain and require robust email authentication protocols to pass. If your SPF, DKIM, or DMARC records are not correctly configured or aligned for these external sending services, Mimecast may interpret the email as a spoofing attempt and block (or blacklist) it. For more details, you can learn about Salesforce's recommendations for SPF, DKIM, and DMARC.
External sending
Using third-party platforms: When you send emails from a CRM, marketing automation tool, or other external systems that use your domain's "From" address, Mimecast may see this as an unexpected origin for your domain's email.
Incorrect SPF configuration: Your SPF record might not include the IP addresses or domains of all legitimate third-party senders, causing Mimecast to flag messages as spoofed.
Mimecast's perspective
Strict default policies: Mimecast's default anti-spoofing policy is designed to be highly secure, meaning it will block (or blacklist) any email it deems suspicious, even if it's technically legitimate but not explicitly authorized.
Lack of alignment: If the domain in your email's From header doesn't align with the domains verified by SPF or DKIM for the sending server, Mimecast's anti-spoofing will likely trigger a rejection.
Another scenario involves internal-to-internal emails that are routed externally. If an email originates from an internal user and is intended for another internal user but passes through an external email gateway or service before hitting Mimecast, it can be flagged. Mimecast expects internal email to come directly from internal sources. This highlights how complex email routing can sometimes interact negatively with security policies.
Diagnosing the issue
When you encounter the 550 anti-spoofing bounce, the first step is to carefully examine the bounce message itself. It will often contain specific details, like the recipient's domain and sometimes a unique Mimecast reference ID, which can be useful for their support team.
Next, I always recommend verifying your email authentication records, specifically SPF, DKIM, and DMARC. Even if you don't have a strict DMARC policy, Mimecast relies heavily on these for its anti-spoofing checks. An SPF record that doesn't include all your sending sources is a common reason for these bounces. You can check your DMARC records with our free DMARC record generator tool to ensure they are set up correctly.
Also, consider the network setup for your test environments. If a test server or MTA is on the same network and coming in with a network address translation (NAT) IP instead of its expected public IP, Mimecast might view this as an anomaly. Checking the public IP in the email headers can confirm this.
Lastly, review your Mimecast administration console. The key is to check the message logs to see how Mimecast processed the email and why it triggered the anti-spoofing policy. This provides the most direct insight into Mimecast's decision. For general troubleshooting, you can also consult our guide on how to troubleshoot email bounce messages.
Resolving Mimecast anti-spoofing bounces
The most direct way to resolve Mimecast anti-spoofing bounces for legitimate emails is by configuring specific exceptions or overrides within your Mimecast account. This typically involves creating a new Anti-Spoofing policy or modifying an existing one to "take no action" for specific senders, IP addresses, or sending domains.
This means explicitly telling Mimecast that certain external sources sending email on your behalf are trustworthy. The general steps for configuring anti-spoofing policies are usually found in the Mimecast administration console documentation. It's crucial that this is done correctly, as a misconfigured policy might still lead to bounces or, conversely, compromise security.
Best practice for Mimecast configuration
I've found that creating a dedicated Mimecast policy that specifies the exact external IP addresses or domains used by your third-party email providers is the most effective method. This ensures that Mimecast recognizes these legitimate sending sources and prevents them from being flagged as spoofing attempts. Remember to test thoroughly after any policy changes.
Beyond Mimecast's internal settings, ensuring your email authentication records (SPF, DKIM, DMARC) are perfectly configured for all your sending services is paramount. This strengthens your domain's overall email security posture and significantly reduces the likelihood of legitimate emails being caught by anti-spoofing filters, whether from Mimecast or other providers.
Views from the trenches
Best practices
Always ensure your SPF record explicitly includes all third-party email service providers authorized to send on your behalf.
Implement DMARC with a p=none policy initially to monitor reports and identify legitimate sending sources before moving to a stricter policy.
Regularly check your Mimecast logs for detailed insights into why specific emails are being rejected or bounced, as these logs provide actionable data.
Common pitfalls
Overlooking the EHLO domain in SPF checks; some systems, including Mimecast, may check this rather than the Return-Path.
Not creating specific Mimecast anti-spoofing exception policies for legitimate third-party senders.
Assuming that a non-strict DMARC policy will prevent all anti-spoofing issues without proper SPF and DKIM alignment.
Expert tips
If possible, verify if the mail transfer agent (MTA) sending test emails is using a NAT IP address instead of a public IP, which can trigger Mimecast's policies.
For internal-to-internal emails routed externally, configure Mimecast to recognize these as legitimate by setting appropriate bypass policies.
Proactively communicate with your Mimecast administrator or IT team to ensure correct policy implementation and understanding of external sending.
Expert view
Expert from Email Geeks says: I've encountered cases where Mimecast's SPF check targets the EHLO domain rather than the return-path domain, which can cause legitimate emails to be rejected if not properly configured.
2020-11-24 - Email Geeks
Marketer view
Marketer from Email Geeks says: When Mimecast doesn't recognize a subdomain as externally handled, its anti-spoofing features will often block the mail because it appears to be a spoofing attempt against your own domain.
2020-11-25 - Email Geeks
Ensuring smooth email flow through Mimecast
Navigating Mimecast's anti-spoofing policies requires a careful balance between robust security and ensuring legitimate email delivery. The "550 Rejected by header based Anti-Spoofing policy" error, while frustrating, is a clear signal that your email authentication and Mimecast configurations need attention.
By meticulously checking your SPF, DKIM, and DMARC records, and by implementing precise anti-spoofing exception policies within Mimecast, you can prevent your valid emails from being mistakenly flagged as spoofing attempts. This proactive approach is vital for maintaining high email deliverability.
Remember, a well-configured Mimecast setup, coupled with strong email authentication, not only enhances your organization's security against phishing and spoofing but also guarantees that your critical communications reach their intended recipients without unnecessary bounces or blacklists (or blocklists).
