출처: Dev.to

Before: 차단할 새 스팸 도메인을 정의에 편집하고, 변경 사항을 검토한 뒤 설정을 재배포해야 했습니다.
After: 리스트에 문자열을 추가하는 한 POST 요청만으로 모든 해당 규칙이 즉시 새 값을 반영합니다. 규칙 편집이나 배포가 필요 없으며, 지원 인력은 스크립트에서 바로 수행할 수 있습니다.

That’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.
규칙은 무엇을 할지 설명하고, 리스트는 언제든지 변할 수 있는 ‘누구’를 담고 있습니다.

A list is a typed collection, and the type is fixed at creation — immutable afterward:

Type
Holds
Matches against
domain
도메인 이름 (example.com)
from.domain, recipient.domain
tld
최상위 도메인 (com, xyz)
from.tld, recipient.tld
address
전체 주소 (user@example.com)
from.address, recipient.address

The typing isn’t cosmetic. Values are validated on write — a domain list rejects a full email address — which catches the classic operational error of pasting alice@example.com into 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.

Create the list, fill it, reference it from a rule via the in_list operator:

1. Create

curl --request POST \
   --url "https://api.us.nylas.com/v3/lists" \
   --header "Authorization: Bearer " \
   --header "Content-Type: application/json" \
   --data '{  "name":  "Blocked domains",  "type":  "domain"}'

2. Fill (up to 1000 items per request)

curl --request POST \
   --url "https://api.us.nylas.com/v3/lists//items" \
   --header "Authorization: Bearer " \
   --header "Content-Type: application/json" \
   --data '{  "items": ["spam-domain.com", "another-bad-domain.net"] }'

3. Reference from a rule

curl --request POST \
   --url "https://api.us.nylas.com/v3/rules" \
   --header "Authorization: Bearer " \
   --header "Content-Type: application/json" \
   --data '{ 
     "name": "Block anything on our blocklist",
     "trigger": "inbound",
     "match": {
       "conditions": [
         { "field": "from.domain", "operator": "in_list", "value": [""] }
       ]
     },
     "actions": [{ "type": "block" }]
   }'

The rule does nothing until a workspace references it in its rule_ids array — that’s how rules apply to the Agent Accounts inside the workspace.

One in_list condition can reference up to 10 lists, and from then on, list updates flow through with no further changes.

The classic blocklist

An inbound block rule 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.

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 conditions combined with the all match operator — block fires only when the sender matches none of the allowed domains:

curl --request POST \
   --url "https://api.us.nylas.com/v3/rules" \
   --header "Authorization: Bearer " \
   --header "Content-Type: application/json" \
   --data '{ 
     "name": "Allowlist: block all but trusted senders",
     "priority": 1,
     "trigger": "inbound",
     "match": {
       "operator": "all",
       "conditions": [
         { "field": "from.domain", "operator": "is_not", "value": "yourcompany.com" },
         { "field": "from.domain", "operator": "is-not", "value": "stripe.com" }
       ]
     },
     "actions": [{ "type": "block" }]
   }'

A 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.

The TLD sweep

Junk campaigns cluster on cheap TLDs. A tld list (xyz, top, and whatever this quarter’s offender is) backed by a mark_as_spam rule routes them to junk without maintaining hundreds of domain entries.

Outbound DLP

Lists work in both directions. A recipient.domain rule with trigger: “outbound” and a block action 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.* matching 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.

Deletion cascades

Deleting a list removes its items, and rules referencing it through in_list simply stop matching its values. Rules don’t break; they just match less.

Audit your rules before deleting a list a block depends on.

Failures fail closed

If a list lookup fails during evaluation of a block rule, the message is blocked rather than passed — surfaced as a retryable 503 on sends or a 451 tempfail on inbound SMTP, with blocked_by_evaluation_error: true in the audit record.

There’s a paper trail

GET /v3/grants/{grant_id}/rule-evaluations shows every evaluation, what matched, and what action ran — your first stop when someone asks why a message was blocked.

Matching is case-insensitive, and condition values cap at 500 characters. Combined with the lowercasing on list writes, you never need to worry about Example.COM slipping past a lowercase entry.

Can one list feed multiple rules?

Yes, and it should. A single “blocked domains” list can back an inbound block rule for one workspace and a mark_as_spam rule for another. That’s the whole point of separating values from logic — update the list once, every referencing rule follows.

How do different agents get different lists?

Through workspaces. A rule applies only to workspaces that carry its ID in rule_ids, 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.

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 lists and DNSBL-based spam detection on the policy to brute-force domain enumeration.

The Policies, Rules, and Lists guide has the full schemas and the workspace attachment flow.

A 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?