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
Frequently asked questions
Is an email ingest address secret?
Not in any strong sense. It is unguessable, but it travels in mail headers, ends up in forwarding rules, and lands in whatever address book the sender uses. Until you add allowlist entries the channel accepts mail from anyone who knows the address, which is deliberate — it makes the channel work immediately — but it is not a security boundary.
What patterns can a sender allowlist match?
Three forms: an exact address such as vendor@stripe.com, a domain wildcard such as *@example.com, and a local-part wildcard such as alerts@* that matches that local part at any domain. Duplicate patterns are rejected with a 409. Domain wildcards are the usual starting point, because most real workflows are mail from this vendor rather than mail from this one person.
What happens to mail from a sender that is not on the allowlist?
It is silently dropped — no bounce, no delivery record, no notification. Bouncing would be worse: to a forged sender it attacks a third party, and to a real one behind a misconfigured allowlist it creates a loop. The operational consequence is that a mis-scoped allowlist is invisible, so if a workflow stops receiving mail, check the allowlist before assuming the sender stopped writing.
What is Hooksbase?
Hooksbase is event infrastructure for AI agents. It ingests events over four channels — HTTP, email, HTML form, and scheduled cron — verifies them, routes them by rule, runs versioned Automations in the event path, and delivers them to HTTP and cloud destinations (AWS SQS, AWS EventBridge, GCP Pub/Sub, and S3-compatible storage) with retries, strict ordering, Standard Webhooks-compatible signing, deterministic replay, and a dead-letter path. It is a hosted service, runs on Cloudflare Workers, is operated at hooksbase.com, and is not affiliated with — and shares no code or ownership with — other similarly named webhook, hook, or tunnelling tools.