Verifying Emails Behind Proofpoint, Mimecast and Barracuda

This guide covers how to recognise a gateway, why it hides the mailbox, 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.

Gateway MX suffixes

A gateway shows up as the domain's mail exchanger. These are the host suffixes the main vendors use in MX records:

Gateway	MX suffix
Proofpoint	pphosted.com
Proofpoint Essentials	ppe-hosted.com
Mimecast	mimecast.com
Barracuda	barracudanetworks.com
Cisco Secure Email	iphmx.com
AppRiver	arsmtp.com
Trend Micro	trendmicro.com
Sophos	sophos.com

Seeing one of these tells you a gateway answers the mailbox check. It does not tell you whether that gateway accepts every recipient: as the vendor documentation above shows, that comes down to configuration, and a domain's configuration can change at any time. The only way to know for one domain is to test it.

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.

Plans for one-off and recurring lists are on the pricing page, which also marks the plans that include the API.

The short version

Gateways hide mailboxes because they often accept every recipient and leave rejection to the server behind them, and whether one does depends on its configuration more than its brand. 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.

Check your own list

Paste one address into the checker above, or upload the whole CSV on the verify page: the first 100 email checks are free with a Google sign-in, no card. Every address comes back valid, risky or invalid with a reason and send advice, and you can download only the safe-to-send rows. Nothing is sent to the people on the list. For bigger or recurring lists, see bulk email verification, list cleaning and pricing.