{"slug": "allowlists-and-blocklists-for-agent-mailboxes", "title": "Allowlists and Blocklists for Agent Mailboxes", "summary": "Nylas introduced typed lists for Agent Mailboxes, allowing support staff to update blocklists and allowlists via a single POST request without redeploying configuration. Lists validate values on write, preventing common errors like pasting email addresses into domain lists, and changes take effect immediately across all referencing rules.", "body_md": "Before: blocking a new spam domain meant editing a rule definition, reviewing the change, and redeploying config. After: it's one POST that appends a string to a list, and every rule referencing that list picks up the new value immediately — no rule edits, no deploy, and a support person can do it from a script.\n\nThat's the design idea behind Lists on Nylas Agent Accounts (currently in beta, along with the Policies and Rules they work with): separate the *values* from the *logic*. Rules describe what to do; lists hold the ever-changing who.\n\nA list is a typed collection, and the `type`\n\nis fixed at creation — immutable afterward:\n\n| Type | Holds | Matches against |\n|---|---|---|\n`domain` |\nDomain names (`example.com` ) |\n`from.domain` , `recipient.domain`\n|\n`tld` |\nTop-level domains (`com` , `xyz` ) |\n`from.tld` , `recipient.tld`\n|\n`address` |\nFull addresses (`user@example.com` ) |\n`from.address` , `recipient.address`\n|\n\nThe typing isn't cosmetic. Values are validated on write — a `domain`\n\nlist rejects a full email address — which catches the classic operational error of pasting `alice@example.com`\n\ninto a domain blocklist and silently matching nothing. Values are also lowercased and trimmed on write, and duplicate additions are silently ignored, so your sync script doesn't need its own normalization or dedupe pass.\n\nCreate the list, fill it, reference it from a rule via the `in_list`\n\noperator:\n\n```\n# 1. Create\ncurl --request POST \\\n  --url \"https://api.us.nylas.com/v3/lists\" \\\n  --header \"Authorization: Bearer <NYLAS_API_KEY>\" \\\n  --header \"Content-Type: application/json\" \\\n  --data '{ \"name\": \"Blocked domains\", \"type\": \"domain\" }'\n\n# 2. Fill (up to 1000 items per request)\ncurl --request POST \\\n  --url \"https://api.us.nylas.com/v3/lists/<LIST_ID>/items\" \\\n  --header \"Authorization: Bearer <NYLAS_API_KEY>\" \\\n  --header \"Content-Type: application/json\" \\\n  --data '{ \"items\": [\"spam-domain.com\", \"another-bad-domain.net\"] }'\n\n# 3. Reference from a rule\ncurl --request POST \\\n  --url \"https://api.us.nylas.com/v3/rules\" \\\n  --header \"Authorization: Bearer <NYLAS_API_KEY>\" \\\n  --header \"Content-Type: application/json\" \\\n  --data '{\n    \"name\": \"Block anything on our blocklist\",\n    \"trigger\": \"inbound\",\n    \"match\": {\n      \"conditions\": [\n        { \"field\": \"from.domain\", \"operator\": \"in_list\", \"value\": [\"<LIST_ID>\"] }\n      ]\n    },\n    \"actions\": [{ \"type\": \"block\" }]\n  }'\n```\n\nThe rule does nothing until a workspace references it in its `rule_ids`\n\narray — that's how rules apply to the Agent Accounts inside the workspace. One `in_list`\n\ncondition can reference up to 10 lists, and from then on, list updates flow through with no further changes.\n\n**The classic blocklist.** An inbound `block`\n\nrule against a domain list, like the one above. Blocked mail is rejected at the SMTP level — never stored, never webhooked, never seen by your LLM.\n\n**The allowlist for sensitive inboxes.** There's no not-in-list operator, so a list can't directly express \"block everyone except members.\" For a small, stable set of trusted senders, build the inversion from `is_not`\n\nconditions combined with the `all`\n\nmatch operator — block fires only when the sender matches *none* of the allowed domains:\n\n```\ncurl --request POST \\\n  --url \"https://api.us.nylas.com/v3/rules\" \\\n  --header \"Authorization: Bearer <NYLAS_API_KEY>\" \\\n  --header \"Content-Type: application/json\" \\\n  --data '{\n    \"name\": \"Allowlist: block all but trusted senders\",\n    \"priority\": 1,\n    \"trigger\": \"inbound\",\n    \"match\": {\n      \"operator\": \"all\",\n      \"conditions\": [\n        { \"field\": \"from.domain\", \"operator\": \"is_not\", \"value\": \"yourcompany.com\" },\n        { \"field\": \"from.domain\", \"operator\": \"is_not\", \"value\": \"stripe.com\" }\n      ]\n    },\n    \"actions\": [{ \"type\": \"block\" }]\n  }'\n```\n\nA rule holds up to 50 conditions, which is plenty for an inbox that should only receive verification mail from a handful of services. Rules run in priority order (0–1000, lower first), so give this one a low number and let routing rules run behind it.\n\n**The TLD sweep.** Junk campaigns cluster on cheap TLDs. A `tld`\n\nlist (`xyz`\n\n, `top`\n\n, and whatever this quarter's offender is) backed by a `mark_as_spam`\n\nrule routes them to junk without maintaining hundreds of domain entries.\n\n**Outbound DLP.** Lists work in both directions. A `recipient.domain`\n\nrule with `trigger: \"outbound\"`\n\nand a `block`\n\naction stops your agent from emailing competitor domains, test domains that leaked into production data, or anywhere else on a do-not-contact list. Outbound `recipient.*`\n\nmatching covers To, CC, BCC, *and* SMTP envelope recipients — so a hidden BCC doesn't slip past the check. Blocked sends return HTTP 403 and no sent copy is stored.\n\n`in_list`\n\nsimply stop matching its values. Rules don't break; they just match less. Audit your rules before deleting a list a `block`\n\ndepends on.`block`\n\nrule, the message is blocked rather than passed — surfaced as a retryable `503`\n\non sends or a `451`\n\ntempfail on inbound SMTP, with `blocked_by_evaluation_error: true`\n\nin the audit record.`GET /v3/grants/{grant_id}/rule-evaluations`\n\nshows every evaluation, what matched, and what action ran — your first stop when someone asks why a message was blocked.`Example.COM`\n\nslipping past a lowercase entry.**Can one list feed multiple rules?** Yes, and it should. A single \"blocked domains\" list can back an inbound `block`\n\nrule for one workspace and a `mark_as_spam`\n\nrule for another. That's the whole point of separating values from logic — update the list once, every referencing rule follows.\n\n**How do different agents get different lists?** Through workspaces. A rule applies only to workspaces that carry its ID in `rule_ids`\n\n, so your sales agents' workspace can reference the do-not-contact rule while the support workspace skips it. Same lists, different rule wiring per agent group.\n\n**What's the practical size ceiling?** Items load at up to 1,000 per request, so a 50,000-entry blocklist is 50 calls. Past that scale, prefer `tld`\n\nlists and DNSBL-based spam detection on the policy to brute-force domain enumeration.\n\nThe [Policies, Rules, and Lists guide](https://developer.nylas.com/docs/v3/agent-accounts/policies-rules-lists/) has the full schemas and the workspace attachment flow.\n\nA worthwhile starting move: export the sender domains from your agent's last month of inbound mail, sort by volume, and you'll usually find your first blocklist (and sometimes your entire allowlist) staring back at you. Which pattern fits your agent — open inbox with a blocklist, or locked-down inbox with an allowlist?", "url": "https://wpnews.pro/news/allowlists-and-blocklists-for-agent-mailboxes", "canonical_source": "https://dev.to/qasim157/allowlists-and-blocklists-for-agent-mailboxes-2me0", "published_at": "2026-06-14 12:08:04+00:00", "updated_at": "2026-06-14 12:10:40.992868+00:00", "lang": "en", "topics": ["developer-tools", "ai-products"], "entities": ["Nylas", "Agent Mailboxes"], "alternates": {"html": "https://wpnews.pro/news/allowlists-and-blocklists-for-agent-mailboxes", "markdown": "https://wpnews.pro/news/allowlists-and-blocklists-for-agent-mailboxes.md", "text": "https://wpnews.pro/news/allowlists-and-blocklists-for-agent-mailboxes.txt", "jsonld": "https://wpnews.pro/news/allowlists-and-blocklists-for-agent-mailboxes.jsonld"}}