Cold email to Mimecast, Proofpoint and Barracuda companies

If a prospect's MX records point to Mimecast, Proofpoint or Barracuda, your email is judged by a security gateway before it reaches their mailbox. You cannot see that from the company website, but you can see it in DNS in seconds, and then measure whether those companies behave differently.

I do not have a clean dataset on gateway rejection rates, so this post is a method, not a result.

How do I detect a gateway from MX records?

Look up the MX records for the recipient's domain. On Windows: nslookup -type=mx example.com. On Mac or Linux: dig mx example.com +short. Then read the hostnames:

Two cautions. Mimecast and Proofpoint hostnames vary by region, and vendors change them, so use the table as a pattern to search, not an exhaustive list. And Mimecast's own advice is that a domain should have only its two Mimecast MX records, so a mixed set of MX records is a hint that the setup is unusual.

Why bother?

Filtering is not symmetrical. In Google Workspace vs Outlook for cold email I made the point that the recipient's hosting changes the road your mail takes. A gateway is a third kind of road. The company bought it to stop exactly the thing you are sending: unsolicited mail from an unknown domain.

That does not mean it blocks you. It means a result you get from a Google-heavy list tells you little about a gateway-heavy one.

How do I add it to my list build?

Treat the gateway as one more enrichment column, like the MX lookup I already suggested for routing between Google and Microsoft inboxes.

1. Pull the MX hostnames for every domain on the list. Most enrichment tools, or a short script, can do this in bulk.
2. Map them to a value: google, microsoft, mimecast, proofpoint, barracuda, other gateway, unknown.
3. Store it as a field on the contact so it can be filtered and reported on.

How do I test whether it matters for my campaigns?

Do not guess. Here is the test I would run, with nothing assumed about the outcome.

1. Segment by gateway value within one campaign, holding the offer and copy constant.
2. Send a small, equal-sized slice to each segment, big enough that a few bounces do not swing the percentage. Why a single campaign's number is not a benchmark applies here.
3. Measure per segment: bounce rate, hard bounce codes, positive replies per hundred sends. Do not use opens; they are unreliable.
4. Seed test: if you have a contact who sits behind a gateway, ask them whether the message arrived and where. One real answer beats a dashboard.
5. Change one variable at a time: link count, plain text against HTML, sending domain, send volume per inbox.

Decide in advance what a difference means. If a gateway segment bounces above your normal 2% line, that is a list or authentication problem to fix. If it bounces normally but replies lag, you are probably being filtered quietly, and that is where seed testing helps.

How do I read the results?

Build a small table before you launch, and fill it in after each batch. Every cell is yours to measure; I have not filled it with numbers because I do not have a clean dataset to cite.

Compare bounces first, because a bounce is a direct signal. Then compare positive replies per hundred sends. A segment with normal bounces and far fewer replies is the case where seed testing earns its keep, because quiet filtering looks like silence.

What changes can I try for a gateway segment?

Change one thing at a time, roughly cheapest first:

1. Remove links and images from the first email.
2. Turn off tracking, as in the open tracking post.
3. Lower daily volume per inbox for that segment.
4. Use a different, older sending domain with clean authentication.
5. Replace the first email with a shorter plain one that asks a single question.

Stop when one change moves the numbers, and keep that change. If five changes do nothing, move to another channel.

What if a gateway segment never works?

Then email may not be the right channel for that segment. Reaching the same people on LinkedIn or by phone is slower and takes more effort per contact, but it is worth it for a small, high-value list, as I argued in why your TAM is smaller than your inbox count. Do not keep pushing volume into a filter that is not letting you through; that damages the domain you also use for everyone else.

A decision rule for gateway segments

Here is the rule I would use once the first batch is back:

• Bounces above 2% in one gateway segment only: the problem is that segment's data or a filter rejecting you. Verify the addresses again, check the bounce text, and pause that segment.
• Bounces normal, replies far below the baseline: suspect quiet filtering. Seed test, then try the changes above one by one.
• Everything similar to the baseline: the gateway is not your problem. Merge the segments and move on, which is the best outcome because it means less to maintain.
• Small segment, high value: do not optimise email at all. Run it as a multichannel list from the start.

Whatever the result, write down the date and the sample size next to it. A number without those is how a single batch turns into a rule nobody can check.

Where this advice stops working

MX detection only sees what is public. A company can run a gateway behind Microsoft 365 or Google with no trace in the MX, and some filter outbound only. Also, the first thing to rule out is your own setup: if SPF, DKIM and alignment are not clean, a stricter filter just finds it faster. Work through the order to check things in and the deliverability audit before blaming the gateway. Inbox counts and domain spread are in how many inboxes you need.

If you want to see how I structure a campaign by segment, the outbound numbers nobody shows you is the place to start.