Why email gateways return hard bounces for valid addresses

When a traditional email verification tool probes a mailbox and receives a hard bounce, it marks the address as undeliverable. That interpretation is usually correct — but not always.

Some of the most widely deployed email security gateways intentionally return hard bounces for addresses that actually belong to real people. The bounce is not a signal that the mailbox is dead. It is a defense strategy.

How email gateways work

Email security gateways sit in front of the mail server. They filter spam, block phishing, enforce policies, and protect users from reconnaissance. Tools like Mimecast, Barracuda, Proofpoint, and Microsoft Defender operate as a shield between the outside world and the internal mail infrastructure.

When an external tool sends an SMTP probe to verify whether an address exists, the gateway intercepts that probe. The probe never reaches the actual mail server. The gateway responds instead.

That is the fundamental problem with SMTP-based email verification behind a gateway. You are not testing the mailbox. You are testing the gateway's policy.

Why gateways return hard bounces

Gateways return hard bounces for valid addresses because they are designed to prevent email enumeration. Email enumeration is the technique of probing a mail server to determine which addresses exist, typically for the purpose of building targeted phishing lists or spam campaigns.

If a gateway returned a different response for valid and invalid addresses, an attacker could probe thousands of addresses and learn which ones are real. By returning the same hard bounce for both valid and invalid addresses, the gateway eliminates that signal.

Mimecast is particularly aggressive about this. Its default behavior is to reject unrecognized senders with a hard bounce, regardless of whether the recipient address is valid. Barracuda and Proofpoint follow similar strategies, though their exact behavior depends on configuration.

The result is that a hard bounce from a gateway-protected domain does not necessarily mean the address is undeliverable. It may mean the gateway does not recognize the sender, the probe triggered a policy, or the gateway is deliberately hiding the address.

How traditional email verification misinterprets this

Traditional email verification tools interpret SMTP responses at face value. A hard bounce means undeliverable. A soft bounce means temporary failure. Accept-all means the domain accepts everything.

When a gateway returns a hard bounce for a valid address, the verification tool has no way to distinguish that from a genuine undeliverable address. The tool reports the address as invalid. The user suppresses it from their outreach list.

That is a false negative. The address is real. The person exists. But the verification tool could not confirm it because the gateway blocked the probe.

For precision use cases — targeted sales outreach, account onboarding, fraud review, recruiting — false negatives are costly. You lose a real contact because the verification method could not see through the gateway.

How identity verification solves this

Identity verification approaches the problem from a different angle. Instead of probing the mail server and interpreting the gateway's response, it verifies the identity directly.

Relentless Identity combines multiple signals to determine whether a work identity exists:

• Identity-provider discovery. When a company uses Microsoft Entra ID, Okta, Onelogin, Auth0, or another provider, Relentless Identity can detect the provider and confirm the identity exists within it. This works regardless of what the gateway returns to SMTP probes.
• Multi-domain discovery. The Finder workflow discovers related email domains and verifies the identity across them. Even if the primary domain is gateway-protected, related domains may provide the verification signal.
• Alias resolution. Gateways often protect primary mailboxes but not aliases or forwarded addresses. Relentless Identity detects and resolves aliases to the underlying work identity.
• MX-host context. The verification response includes MX-host information, which helps distinguish between "the gateway blocked the probe" and "the address genuinely does not exist."

When Relentless Identity returns deliverable for an address behind a gateway-protected domain, that signal is based on identity evidence, not SMTP probing. The identity has been confirmed through provider signals, domain discovery, or mailbox verification that bypasses the gateway's defenses. For more on the distinction between identity-level and mailbox-level checks, see Identity verification vs. email verification.

The distinction between identity and deliverability

There is an important distinction between two statements:

1. "This email address is deliverable" — the mail server will accept a message.
2. "This work identity exists" — a real person appears to be behind this address.

A gateway-protected domain may block delivery for statement 1 while statement 2 is still true. The identity exists. The person is real. But the gateway will not accept your message because it does not recognize you as a trusted sender.

That is a sender reputation issue, not an identity issue. The gateway is doing its job — protecting its users from untrusted senders. But the address is still valid, and the person is still reachable through other channels.

For teams that need to know whether a real professional identity exists behind an address, identity verification provides the answer. Whether the gateway will accept your specific message is a separate question that depends on sender reputation, domain authentication, and gateway policy.

When this matters most

This distinction is most important for:

• Sales teams targeting enterprise accounts behind Mimecast, Proofpoint, or Barracuda. A hard bounce does not mean the contact is dead. Identity verification confirms whether the person exists before you invest time in outreach.
• Account onboarding where a new user signs up with a gateway-protected work email. SMTP verification may return a hard bounce, but the identity is real. Identity verification confirms the person belongs to the organization.
• Fraud review where you need to verify that an applicant's work email corresponds to a real person at the stated company. Gateways obscure SMTP signals, but identity verification confirms the identity.
• Recruiting where candidates use gateway-protected corporate email. The candidate is real, the email is valid, but SMTP probing returns a hard bounce. Identity verification sees through the gateway.
• Data pipelines enriching CRM records with verified work identities. SMTP verification produces false negatives behind gateways. Identity verification produces reliable results.

The practical takeaway

A hard bounce is not always a death sentence for an email address. Sometimes it is a defense strategy.

Traditional email verification cannot distinguish between a genuinely undeliverable address and a valid address behind a gateway. Identity verification can, because it verifies the person, not just the mailbox.

If your workflow depends on knowing whether a real professional identity exists behind an address — especially behind gateway-protected domains — identity verification gives you the signal you need. SMTP probing alone will miss real contacts.

For implementation guidance, see the REST API reference or read about response semantics to understand how to interpret identity verification results in your application.