# A catch-all behind a security gateway is the gateway's design, not a squat

Proofpoint, Mimecast and Barracuda typically accept every recipient at the edge. What mx_provider_type says, why the weight drops to 15, how to send.

Date: 2026-09-13

A security gateway is a mail filtering service that a company puts in front of its real mail system: every inbound message goes to the gateway's servers first, is scanned, and is then passed on to the mailbox platform behind it. Proofpoint, Mimecast and Barracuda are the three Spaw recognises from a domain's MX records. A domain behind one of them typically answers `250 OK` to every recipient at the gateway, because the gateway does not always hold the company's directory, and that makes the domain a catch-all in the eyes of any handshake. Spaw reports it as such, but with a lighter weight, because the accept-everything behaviour here is the product working as designed rather than a sign that nobody runs the domain.

## What a gateway changes about the handshake

A mailbox handshake asks the receiving server, at the `RCPT TO` step, whether it will take mail for one recipient. A server that knows its users answers `550 5.1.1` for an unknown one, and that answer is what lets a verifier report `mailbox_not_found`.

A gateway sits between the world and that server. Some gateways verify recipients against a directory the customer synchronises to them, and those answer like an ordinary server. Many do not, or are configured not to: they accept the message, pass it inward, and let the real mail system reject unknown users afterwards, generating a bounce message back to the sender rather than a rejection during the handshake. From the outside, every recipient at the domain is accepted, which is the definition of a catch-all.

The difference from a squat is the domain's reason for being catch-all. A parked domain or a harvesting domain accepts everything because collecting mail is the point. A domain behind Proofpoint accepts everything because a filtering company is answering on its behalf. The mailbox question is equally unanswerable in both cases, but the two domains are not equally suspicious, and a score that treats them the same is wrong about one of them.

## What Spaw answers

The domain's mail provider is classified from its MX hostnames into `mx_provider` and, since September 2026, into `mx_provider_type`, which for these three providers is `security_gateway`. When a catch-all answer arrives for a domain whose provider type is a gateway, the score carries `catch_all_gateway` at 15 instead of `catch_all` at 30. The reason stays `catch_all`, because that is still what the handshake found.

```json
{
  "email": "mia.kowalski@acme.com",
  "deliverable": "risky",
  "reason": "catch_all",
  "risk_score": 15,
  "risk_level": "low",
  "mx_provider": "proofpoint",
  "mx_provider_type": "security_gateway",
  "catch_all": true,
  "mailbox_exists": null,
  "mailbox_confidence": 90,
  "risk_signals": [{ "signal": "catch_all_gateway", "weight": 15, "dataset": "mailbox-smtp" }]
}
```

The two catch-all rows are exclusive: an answer carries one or the other, never both. Fifteen points leaves the address in the low band on its own, which matches how such addresses behave in practice: a name-shaped address at a company that pays for mail security is usually a real employee.

`mailbox_confidence` moves the same way. The estimate starts at 50 and, among other things, adds 10 for a domain whose mail is hosted at an established provider, and the three gateways count as established alongside Google, Microsoft, Zoho and Fastmail. A gateway domain with DMARC at reject, SPF published, a registration older than two years and a `first.last` username lands in the high 80s or 90s. The confidence score is the number to branch on when the reason says `catch_all`.

## How to tell which case you are in

The domain endpoint answers the question for a whole domain in one call, for one credit when the domain accepts mail.

```bash
curl https://spaw.co/api/v1/email/domain/acme.com \
  -H "Authorization: Bearer sk_live_…"
```

Read three fields together. `mx_provider_type` says `security_gateway`, `mailbox_provider`, `transactional`, `hosting`, `self_hosted` or `other`. `catch_all` is `true` once any address at the domain has answered catch-all in the last week, and `null` when that is not known. And `mx_provider` names the provider, which links to Spaw's provider page for it: [Proofpoint](/email-providers/proofpoint), [Mimecast](/email-providers/mimecast) and [Barracuda](/email-providers/barracuda) each describe how the provider typically answers a handshake.

A catch-all whose provider type is `other` or `self_hosted` is the case to look at more carefully. It may be an anti-harvesting policy at a well-run company, which the confidence score will reflect through DMARC, SPF and registration age, or it may be a domain that collects whatever arrives. `parked` and `mx_blocklisted` settle the worst of those on their own, with their own reasons and weights.

## How to send to a gateway catch-all

The advice is the same as for any catch-all, with the threshold moved.

Send to gateway domains at a normal confidence threshold rather than a cautious one. A common policy holds catch-all addresses below 60 and sends above it; behind a gateway, the same address typically scores higher for the reasons above, so more of the list goes through, which is the intended effect.

Report the outcomes. A delivery reported through the feedback endpoint turns later lookups of the address into a confirmed mailbox for your account, and a bounce moves the domain's bounce share, which feeds every other address's confidence at that domain. Both are counts per domain, never addresses shared between accounts.

Expect the bounce to arrive later than usual. Because the gateway accepted the message, a wrong address bounces after delivery rather than during it, sometimes hours later, so the report from your sending provider is the only way to learn about it. Point the provider's bounce webhook at Spaw and the address lands on your suppression list without a credit spent.

Do not use the lighter weight as proof of existence. Fifteen points is a statement that the domain is a real, filtered company, not that `mia.kowalski` works there. `mailbox_exists` stays `null` behind a gateway for exactly that reason.

## What the sending policy does with it

The default policy blocks nothing on a catch-all: it blocks the five signals that are almost certainly wrong (disposable, typo-squat, parked, blocklisted, no-reply) and any score over 60, and a gateway catch-all sits well under that. If your list needs a firmer rule, `min_mailbox_confidence` in the policy holds back any unconfirmed mailbox whose estimate is below the floor you set, and `blocked_by` then reads `mailbox_confidence`. Adding `catch_all_gateway` to `block_signals` blocks the lighter case by name, and `catch_all` blocks the heavier one, so the two can be treated differently without reading the provider fields at all.

## What to do next

- Read the [catch-all guide](/guides/catch-all-email-addresses) for the confidence table and the sending advice in full.
- Look up a domain's provider type and catch-all memory with the [domain intelligence endpoint](/docs/api/domain-intelligence).
- Set a confidence floor or a per-signal rule in your [sending policy](/docs/api/update-email-policy).
- Read the provider pages for [Proofpoint](/email-providers/proofpoint), [Mimecast](/email-providers/mimecast) and [Barracuda](/email-providers/barracuda).

Reference: https://spaw.co/guides/catch-all-behind-a-security-gateway