Verifying Emails Behind Proofpoint, Mimecast and Barracuda

Addresses at companies that use an email security gateway such as Proofpoint, Mimecast or Barracuda often cannot be verified, because many gateways accept mail for any recipient and sort it out later. A verifier that respects this returns them as risky (catch-all), not valid. You can still email them, but as a separate, measured segment. A gateway that accepts the message and fails to deliver it later still produces a bounce.

This guide covers how to recognise a gateway, why it hides the mailbox, how the numbers look in real data, and a sending plan you can apply today.

What a security gateway does to an SMTP check

A gateway sits between the internet and the company's real mailboxes, and it is the server your verifier talks to.

A normal mailbox check works like this. The verifier looks up the domain's MX record, connects to that server, offers a recipient with RCPT TO, and reads the reply. A 250 means the server accepts that recipient. A 550 means it does not. (See 550 5.1.1 for the common "user unknown" reply.) Nothing is sent.

When the MX record points to a gateway, the verifier is not talking to Microsoft 365 or Google Workspace. It is talking to a filter that may not know which mailboxes exist downstream. The gateway then has two choices:

1. Know the valid recipients (through a directory sync, an LDAP lookup or a live check against the mail server behind it) and reject unknown ones at RCPT TO.
2. Accept every recipient at the edge, scan the message, pass it to the real mail server, and let that server reject it.

The second choice turns the whole domain into a catch-all from the outside. Every address looks accepted, including ones that cannot exist.

The SMTP standard expects this situation. RFC 5321, section 6.1 notes that a server may be unable to validate delivery addresses "because the server is acting as a relay and has no immediate access to the delivering system". A gateway in its default posture is exactly that relay.

What the vendors themselves say

The gateway vendors document recipient verification as something the customer has to configure. That is why behaviour varies so much between companies on the same product.

• Barracuda. Its Email Gateway Defense documentation, Configuring Recipient Verification, says proper configuration "prevents problems like backscatter, but also ensures that only mail for valid recipients is processed". It "highly" recommends Microsoft 365 customers configure it with Entra ID. For the older Email Security Gateway, its LDAP lookup page says: "If LDAP is not configured, the Barracuda Email Security Gateway will do SMTP recipient verification through RCPT TO commands."
• Proofpoint. A Proofpoint security advisory (PFPT-SN-2020-0001) says "properly configured Recipient Verification will ensure that messages to invalid recipients are not delivered to downstream mail servers and will not generate 'bounce' messages". The advisory treats downstream bounces for invalid recipients as what happens without it.
• Microsoft 365. Microsoft's Directory-Based Edge Blocking page says Exchange Online rejects mail for invalid recipients at its perimeter with 550 5.4.1 Recipient address rejected: Access denied. It also notes that in hybrid setups "the MX record for the domain must point to Microsoft 365 or Office 365" for that to work. When the MX points to a third-party gateway, the rejection happens behind the gateway, out of a verifier's sight.

So the same product can be checkable at one company and a black box at the next. It depends on whether the admin wired up recipient verification.

The numbers: how often gateways hide the mailbox

In our own data, domains behind a gateway were the hardest group to verify. These figures come from SimpleVerifier's Email List Health Report 2026, which covers SMTP checks of 165,460 addresses on 54,463 domains between 10 September and 12 October 2026. A domain counts as catch-all when it accepted a randomly generated recipient that cannot exist.

Mail platform (from the MX record)	Domains	Catch-all domains	Catch-all share
Security gateway in front of the mailbox	3,019	1,820	60.3%
Google Workspace	13,925	6,507	46.7%
Microsoft 365	16,132	3,738	23.2%
Other business mail hosts	21,115	2,866	13.6%
All domains checked	54,463	15,000	27.5%

By gateway vendor, matched on the MX host suffix:

Gateway	MX suffix	Domains	Catch-all share
AppRiver	arsmtp.com	177	100%
Barracuda	barracudanetworks.com	568	89.3%
Trend Micro	trendmicro.com	77	87.0%
Cisco Secure Email	iphmx.com	194	74.2%
Proofpoint	pphosted.com	1,204	69.9%
Mimecast	mimecast.com	227	16.7%
Proofpoint Essentials	ppe-hosted.com	467	5.8%
Sophos	sophos.com	59	0%

Two things stand out. First, the spread is enormous: Barracuda and Proofpoint (enterprise) domains were mostly unverifiable, while Mimecast, Proofpoint Essentials and Sophos domains were mostly checkable. Second, two products from the same company behaved very differently, which fits the vendor documentation: the setting matters more than the brand.

Read these as a guide to odds, not a rule for any one domain. The sample is not random. It reflects what passed through one verification service, and 56.9% of its domains are Brazilian (.br). The report's methodology section lists the limits. A domain's configuration can also change at any time.

How to spot a gateway before you send

You do not need the verifier to tell you. The MX record does.

1. Look up the domain's MX record with our MX lookup tool, or run dig MX company.com in a terminal.
2. Compare the highest-priority host against the suffixes in the table above.
3. Tag every address on the list with its mail platform: Google Workspace, Microsoft 365, gateway (by vendor) or other.

On a spreadsheet, a single extra column for "mail platform" turns a pile of "risky" results into segments you can reason about.

If you only want to know whether one domain accepts everything, the catch-all checker tests it with a random address and nothing else.

What happens when you send to a gateway that accepts everything

The bounce is delayed, not avoided. This is the part most senders miss.

When the gateway accepts your message with 250, it takes responsibility for it. If the mailbox behind it does not exist, the downstream server rejects it and a bounce message is generated. RFC 5321 is explicit: "If there is a delivery failure after acceptance of a message, the receiver-SMTP MUST formulate and mail a notification message", addressed to the envelope sender.

In practice that means:

• The failure arrives minutes or hours later as a bounce email (a delivery status notification), not as an instant rejection during the send.
• Sending tools that process bounce emails count it as a bounce, the same as an instant one.
• Your bounce rate for that segment reflects reality once the notices arrive. A verification report that called these addresses valid would have hidden that until after the send.

This is also why a tool that labels gateway addresses "valid" does real damage. You plan around a clean segment, send at full volume, and the bounces arrive after the campaign is out. Our post on how to tell if your verifier is lying shows a 60-second test for this.

A sending plan for gateway segments

Treat gateway catch-all addresses like any other catch-all segment: measure first, then cap. The full framework, including a formula for the maximum safe volume, is in should you email catch-all addresses. Here is how it applies.

Step 1: split the risky results by reason

Not all risky results are equal. Separate:

• Gateway catch-all: the MX is a gateway and the domain accepted a made-up recipient.
• Platform catch-all: Google Workspace or Microsoft 365 domain configured to accept everything.
• Role addresses like info@: a shared inbox, a separate decision.
• Temporary failures: the check never got an answer. These often resolve on a retry.

Step 2: score gateway addresses by source

Where the address came from predicts its quality better than anything the gateway will tell you.

Source	Typical action
Published on the company site with the person's name	Include in the test batch
Pattern confirmed by another published address at the same company	Include in the test batch
Guessed pattern, no confirmation	Hold until the test batch is back
Old export, unknown age	Re-source before sending

Step 3: run a test batch and read the top of the range

Send to 100 to 300 of the best-scored addresses, spread over a few days, and count hard bounces once the delayed notices have had time to arrive. Wait at least a day before judging the result.

Step 4: size the rest from your bounce budget

Worked example

These figures are assumptions for illustration. Substitute your own.

You have a 10,000-address B2B list. After verification:

• 7,200 valid
• 1,100 risky on gateway catch-all domains
• 900 risky on other catch-all domains
• 800 invalid (removed)

Your valid addresses historically bounce at 0.5%. Your target blended bounce rate is 2%. A 200-address test batch from the gateway segment comes back with 12 hard bounces, a 6% observed rate. Use roughly 9% as the planning figure, because a sample of 200 leaves a wide range (the Wilson 95% interval for 12 in 200 runs from about 3.5% to 10.2%).

Using the formula from the catch-all guide, the maximum catch-all volume C alongside V valid addresses is:

C = V × (T − b_v) / (b_c − T)
C = 7,200 × (0.02 − 0.005) / (0.09 − 0.02)
C = 7,200 × 0.015 / 0.07 ≈ 1,540

That is the total for all catch-all segments in the send. With 2,000 catch-all addresses in total, you would send the best-scored 1,540 and hold the rest, or split the send over two campaigns with more valid addresses in each.

Catch-all bounce rate used for planning	Max catch-all addresses with 7,200 valid
5%	3,600
9%	about 1,540
12%	1,080
15%	about 830

Step 5: never resend to a bounced gateway address

A delayed bounce is a hard bounce. Suppress it everywhere: the sending tool, the CRM and the source list. Re-verifying it will come back risky again, because the gateway still accepts everything.

Things that do not work

Tactic	Why it fails
Re-verifying gateway addresses until one says valid	The gateway gives the same answer every time. The result only changes if the company changes its configuration
Trusting a "valid" label on a gateway domain	The gateway accepted a made-up address too, so the label reports the setting, not the mailbox
Sending gateway segments first in a campaign	Early bounces from the riskiest segment distort your sending platform's view of the whole campaign
Deleting every gateway address	You lose a large share of real people at companies that simply filter their mail
Ignoring delayed bounces because the send "went through"	Acceptance at the edge is not delivery. The notice arrives later and counts

How SimpleVerifier handles gateway domains

SimpleVerifier offers a random, made-up recipient before the real address on every domain it checks. If the made-up one is accepted, every address on the domain comes back risky, never valid, whether the server is a gateway, Google Workspace or anything else. Risky results export separately from valid and invalid, so the segment is ready to score and test. Nothing unconfirmed is reported as valid.

For one-off lists, pay-as-you-go packs cost $9 for 2,500 verifications or $19 for 10,000, and the credits never expire. If you clean lists every week, Pro is $29.99 a month for unlimited verification and includes the API. See pricing for the details.

The short version

Gateways hide mailboxes because they often accept every recipient and leave rejection to the server behind them. In our data that made 60.3% of gateway-fronted domains unverifiable, with wide differences between vendors. Find the gateway in the MX record, split those addresses into their own segment, test a batch, and send only what your bounce budget can absorb. Treat a late bounce exactly like an instant one.