How do I set up allowlists and blocklists?
Allowlists and blocklists let you control who your AI agent can communicate with. This is a critical safety feature for autonomous agents running in production with minimal human oversight.
How Lists work
AgentMail provides six list types based on two dimensions, direction (send, receive, or reply) and type (allow or block):
Each entry can be either a full email address (e.g., partner@example.com) or an entire domain (e.g., example.com). An allow list takes effect as soon as it has an entry: from then on, any address that does not match an allow entry is treated as blocked for that direction.
What happens when a list blocks a message
Inbound mail (receive and reply lists). A blocked message is not dropped. AgentMail still stores it in the inbox, but:
- It gets the
blockedlabel. - It fires the
message.received.blockedevent instead ofmessage.received. A message that also failed sender authentication firesmessage.received.unauthenticatedinstead. - It is left out of message and thread lists unless you pass
include_blocked=Truewith an API key that has thelabel_blocked_readpermission. The same permission is required to subscribe tomessage.received.blocked.
Because blocked mail never fires message.received, an agent that reacts to that event never sees it.
Outbound mail (send lists). The send is refused with a 403 and error code message_rejected, and no email goes out. This applies to every send path, including replies, forwards, and drafts.send.
Setting up lists via the SDK
Add an entry
List entries
Remove an entry
Inbox-scoped lists
Lists can be applied at the inbox level for per-inbox filtering. For example, one inbox might only accept emails from meta.com, while another inbox in the same pod accepts from partner.com.
Inbox-level lists override pod-level and org-level lists. If the inbox-level list has a match, pod and org lists are not checked.
Reply lists
Reply lists control filtering for inbound emails that are replies to previous outbound messages. When an inbound email arrives, AgentMail checks the In-Reply-To header:
- If the email is a reply to a previous outbound message, only the reply lists are checked. Receive lists are skipped.
- If the email is not a reply, only the receive lists are checked. Reply lists are skipped.
By default, when reply lists are empty, all replies are allowed. This is useful for agents that initiate outbound emails (such as making reservations or sending inquiries) and need to receive the responses.
Common patterns for agents
Customer-facing agent: Use a send allowlist to restrict your agent to only email your existing customers. This prevents the agent from accidentally emailing the wrong people.
Personal Agent (Openclaw, Manus, etc.): Use a receive allowlist to restrict your agent to only respond to emails from specific people or domains.
Anti-spam: Use a receive blocklist to filter out known spam senders or unwanted automated emails.
Task-oriented agent (making reservations, bookings, etc.): Use a receive allowlist to restrict inbound to your organization’s domain, but leave reply lists open (default) so replies to agent-initiated outbound emails come through.
Why this matters for agents
Without guardrails, an autonomous agent could email the wrong people, respond to phishing attempts, or get caught in infinite email loops with another bot. Lists are your safety rails. They are especially important for:
- Production agents operating with minimal human oversight
- Customer-facing agents that should only contact approved recipients
- Support agents that should only respond to known customers
- Task-oriented agents that send outbound emails and need replies to come through
- Any agent that needs protection from spam, phishing, or abuse
For more details on the Lists API, see the Lists core concept documentation.
