A webhook's email ingest address is a publicly reachable endpoint. It is unguessable, but it is not secret in any strong sense — it travels in mail headers, sits in forwarding rules, and ends up in whatever address book the sender uses.
Until you add allowlist entries, the channel is open. Any sender who knows the address is accepted. That is deliberate, because it makes the address usable the moment a webhook exists, but it is not where you want to be in production.
The three pattern forms
A sender allowlist is per-webhook and supports:
| Form | Example | Matches |
|---|---|---|
| Exact address | vendor@stripe.com | That one address |
| Domain wildcard | *@example.com or example.com | Any sender at that domain |
| Local-part wildcard | alerts@* | That local part at any domain |
Duplicate patterns are rejected with a 409.
Domain wildcards are the usual starting point — most real workflows are "mail from this vendor" rather than "mail from this one mailbox". Local-part wildcards are narrower in practice than they look; use them when a system sends from alerts@ across several of its own domains.
Plan gating
Listing allowlist entries works with any project key. Creating or deleting entries requires Starter or above. On the free plan the generated address accepts all senders and there is no way to narrow it, which is worth knowing before pointing a free-tier address at anything sensitive.
Blocked mail is dropped, not bounced
This is the behaviour that surprises people, so it is worth being explicit. Mail from a sender outside the allowlist is silently dropped. No bounce, no delivery record, no notification.
The reason is backscatter: bouncing to a forged sender attacks a third party, and bouncing to a real one on a misconfigured allowlist creates a loop. Dropping is the safe default.
The operational consequence is that a mis-scoped allowlist is invisible. If a workflow stops receiving mail, an allowlist that does not match is the first thing to check, and delivery history is where you check it — there will be nothing there rather than an error.
The other quiet failure modes
Allowlists are one of several deliberately silent behaviours on this channel:
- Archived or missing webhook — rejected at SMTP as an unknown recipient. The sender does get a failure here.
- Paused webhook — accepted at the SMTP layer, then skipped. No delivery is created.
- Disabled project — dropped silently, to avoid bounce loops.
- Blocked sender — dropped silently, as above.
Only the first produces anything the sender can see.
A sensible rollout
- Create the webhook and take the address.
- Leave the allowlist empty while you wire up the producer and confirm mail is arriving as expected in delivery history.
- Add the domain wildcard for the real producer.
- Send one message from an address outside the allowlist and confirm it does not appear in delivery history. This is the step people skip, and it is the only way to know the allowlist is actually applied rather than merely saved.
Rate limiting still applies
The project's ingest rate limit applies to email as it does to every channel, so an open address cannot be used to drive unbounded delivery volume. That is a throughput guard, not an access control — it limits how fast unwanted mail arrives, not whether it arrives.
Where to go next
- Email to webhook for the channel overview
- Sender allowlist for the short definition
- Verify provider webhooks before they reach your agent for signature verification on the HTTP channel