Troubleshooting email deliverability issues with Mimecast

If your marketing emails keep landing in spam or quarantine at companies that use Mimecast, you're not alone. Mimecast is one of the most widely deployed email security gateways, and its aggressive filtering regularly catches legitimate marketing email. In this guide, we'll walk through how to diagnose a Mimecast block, why it happens, and how to fix it, using a real (anonymized) case from an eCommerce brand we worked with.

Why Mimecast blocks legitimate marketing email

Mimecast sits in front of a company's inbox and inspects every inbound message for phishing, spoofing, and malware. One of its most sensitive features is Impersonation Protection: a policy designed to catch external senders pretending to be the company itself or one of its trusted brands.

Here's the catch for marketers. If you send email from an ESP like Mailchimp, Klaviyo, or Braze, your messages originate from an external server, but they carry your brand's display name and often your domain. To Mimecast, that pattern looks exactly like an impersonation attempt: an outside server claiming to be a known brand. The result is that your perfectly legitimate campaigns get flagged as potential phishing and routed to spam or quarantine.

In the case we encountered, an eCommerce brand's campaigns were being blocked at organizations running Mimecast because the display name and sending domain matched a brand Mimecast had been configured to protect. Content made it worse: keywords common in promotional email, like "Off" and "$", matched entries in Mimecast's threat dictionary and added to the suspicion score.

Step 1: Confirm Mimecast is the culprit

Before changing anything, verify that the problem is actually a gateway block and not general deliverability. A few signals to look for:

• Your emails deliver fine to personal inboxes (Gmail, Yahoo, Outlook.com) but fail at specific corporate domains.

• Bounce messages or headers reference Mimecast, or the recipient domain's MX records point to Mimecast (look for mimecast.com in an MX lookup).

• Recipients report finding your emails in quarantine digests rather than their spam folder.

That first signal is worth understanding. Test sends to personal inboxes pass because those mailboxes have no security policy that identifies your company as a protected internal brand. Only recipients behind a gateway configured to guard your brand name will trigger Impersonation Protection. This is why deliverability testing against seed lists of personal addresses can give you a false sense of security: you have to test against the environments your real recipients actually use.

Step 2: Identify what's triggering the policy

Impersonation Protection typically evaluates a combination of signals. Work through each one for your own program:

• Display name: Does your friendly-from name match the recipient organization's protected brand or executive names?

• Sending infrastructure: Are you sending from an external ESP's servers while presenting an internal-looking identity?

• Domain similarity: Does your sending domain closely resemble the protected domain (including subdomains and lookalikes)?

• Content keywords: Do your subject lines and body copy include terms from Mimecast's threat dictionary? Promotional staples like percentage-off language and currency symbols are common offenders.

You usually can't see the recipient's Mimecast configuration directly, so this step often requires a conversation with the recipient organization's IT team. Come prepared with your sending IPs, your authenticated sending domain, and examples of blocked messages with full headers.

Step 3: Request an Impersonation Protection Bypass Policy

The fix lives on the recipient's side, inside their Mimecast console. Ask their IT team to create an Impersonation Protection Bypass Policy that explicitly exempts your mail. The policy should be scoped to one of the following:

• Your ESP's sending IP addresses (for example, Mailchimp's published IP ranges), or

• Your authenticated sender address, such as info@yourbrand.com, validated with passing SPF and DKIM.

One critical detail that trips up even experienced IT teams: a standard "Permitted Senders" or safelist policy usually does not bypass Impersonation Protection. Those policies exempt mail from spam scanning, but Impersonation Protection is evaluated separately. If the IT team safelists you and the blocks continue, this is almost always why. The dedicated Bypass Policy is essential.

Tying the bypass to authentication rather than a blanket exemption keeps everyone safe. With SPF and DKIM required, the policy only opens the door for mail you actually sent, so the organization isn't weakening its defenses against real impersonation attempts.

Step 4: Verify and monitor

Once the bypass policy is in place, send a test campaign to a known contact at the organization and confirm inbox placement. Then keep an eye on a few things going forward:

• Maintain valid SPF, DKIM, and DMARC on your sending domain. If authentication breaks, the bypass may stop applying.

• If you migrate ESPs or your ESP changes its IP ranges, the bypass policy may need updating.

• Watch engagement metrics segmented by recipient domain. A sudden drop at one corporate domain is often a gateway policy change, not a content problem.

Conclusion

Security gateways like Mimecast can be frustrating for email marketers, but the blocks are diagnosable and fixable once you understand the policies behind them. The pattern is consistent: confirm the gateway is the cause, identify the triggering policy, and work with the recipient's IT team on a properly scoped bypass backed by authentication. For more help optimizing your email program, Scalero offers a range of services and resources, including a detailed deliverability series with additional insights and strategies.