| Mimecast | |
|---|---|
| Domains | us-smtp-inbound-1.mimecast.com, eu-smtp-inbound-1.mimecast.com, de-smtp-inbound-1.mimecast.de, za-smtp-inbound-1.mimecast.co.za, au-smtp-inbound-1.mimecast.com |
| Mail routing | Regional inbound hosts under mimecast.com, with country domains for Germany (mimecast.de) and South Africa (mimecast.co.za). Each region publishes a pair, numbered -1 and -2. A company domain whose MX points at one of them has Mimecast in front of its real server, which is usually Microsoft 365, Google Workspace or on-premises Exchange. |
| How results come back | Many mailboxes; unanswered ones come back unknown, unbilled |
How Mimecast answers a probe
What the server does when we open a connection and ask about one address.
- Your probe never reaches the company's mailbox server. Mimecast takes the connection, runs its own checks and relays the message on later, so every answer you get is Mimecast's policy speaking.
- With recipient validation on, Mimecast checks the address against a directory the admin syncs from Active Directory, Entra ID or Google. An address that isn't in it gets a 550 at RCPT TO, and that answer is as clean as any mailbox server gives.
- With validation off, Mimecast says 250 to every address at the domain. It then hands the mail to the server behind it, and a dead mailbox bounces minutes later, long after the probe has closed.
- Greylisting is part of Mimecast's default inbound policy. A sending IP it hasn't seen before often gets a 451 on first contact, which says the gateway wants a retry, not that the mailbox is gone.
The part that catches people out
What we do about it
The mx_host field on every row names the Mimecast host we spoke to, so you can see the gateway in your results instead of guessing. We send the catch-all probe to a random address at the same domain. When Mimecast accepts both, the row comes back catch_all, billed once like any finding, and never a confident valid. A 550 comes back invalid with the literal code in smtp_code. A 451 gets a retry on a later schedule; if Mimecast still won't answer, the row is unknown with reason greylisted and costs nothing. The result codes reference lists every value.
Sending to Mimecast mailboxes
Verification is one step. These are the things that decide whether the message lands.
- Mimecast scores inbound mail on its own reputation data as well as the recipient's. A new sending domain with no history gets more scrutiny than it would at Microsoft 365 alone.
- URL rewriting is common on Mimecast tenants. Links in your message are wrapped, and your click tracking may record the gateway's scan as a click before the person has read anything.
- Held messages sit in a Mimecast queue the recipient may never check. Your platform shows them as delivered, since the gateway accepted them.
Questions people ask
How do I know if a domain uses Mimecast?
Look up its MX record. A host ending in mimecast.com, mimecast.de or mimecast.co.za means Mimecast answers the mail first. ZapBounce shows the same host in the mx_host field of every result, so a batch tells you which rows sit behind the gateway.
Why did a Mimecast address pass verification and then bounce?
Because Mimecast accepted it at RCPT TO and the server behind it rejected it later. That happens on domains where the admin hasn't turned on recipient validation. The domain behaves as a catch-all, and ZapBounce labels it catch_all rather than valid for that reason.
Does ZapBounce charge for Mimecast addresses it can't confirm?
A row that comes back catch_all costs one credit, because the random-address probe is a real finding about the domain. A row that comes back unknown, such as a 451 that persists after the retry, is never billed.
Should I delete every address behind Mimecast?
No. A 550 from Mimecast is a reliable no, and those rows are safe to remove. Rows marked catch_all are better sent in their own small batch, so the bounces from that group show you how much of it is real.