Spam Detection for Inbound Agent Mail

Spam aimed at a human wastes attention; spam aimed at an autonomous agent becomes input — so filter it before the model ever sees it: curl --request POST \ --url "https://api.us.nylas.com/v3/policies" \ --header "Authorization: Bearer $NYLAS_API_KEY " \ --header "Content-Type: application/json" \ --data '{ "name": "Agent inbound hygiene", "spam_detection": { "use_list_dnsbl": true, "use_header_anomaly_detection": true, "spam_sensitivity": 1.0 } }' That's a policy for Agent Accounts — the Nylas-hosted mailboxes (currently in beta) built for AI agents and system identities. Attach it to a workspace and every account in that workspace inherits the spam settings. Here's what each knob does and how to tune it for a reader that never gets suspicious on its own. What the policy actually checks An LLM agent will earnestly process whatever lands in its inbox: phishing, junk, auto-replies, and messages whose entire purpose is to manipulate the model. The threat isn't annoyance, it's contaminated context. Policy-level spam detection gives you two independent signals, evaluated when mail arrives over SMTP: use_list_dnsbl checks the sending server against DNS blocklists — the classic reputation lookup that catches known-bad infrastructure regardless of what the message says. use_header_anomaly_detection looks for structural weirdness in the message headers, the kind of malformation that legitimate mail servers don't produce. Both run before your application sees anything, which is the right place for this work. Filtering at the mailbox layer is cheaper than teaching every downstream prompt to be skeptical, and per the mailboxes guide , inbound filtering also keeps the agent from reacting to loops and mailer-daemon noise. Where flagged mail goes A message that trips spam detection routes to the junk folder — one of the six system folders every account ships with — instead of inbox . The agent's normal read path (listing inbox messages, reacting to inbound webhooks for new mail) simply doesn't encounter it, but nothing is destroyed: you can inspect junk when you're tuning, and false positives are recoverable. Retention is part of the same policy. You can set limit_spam_retention_period and limit_inbox_retention_period independently, with one constraint worth knowing up front: the spam window must be shorter than the inbox window, so junk clears out ahead of real mail. For an agent that handles transient workflows, aggressive spam retention is free hygiene — there's no reason to store a month of junk for a mailbox whose job resolves in hours. When to block instead of flag Spam detection is probabilistic; sometimes you know the answer in advance. For senders you've already judged, a rule with a block action rejects the message at the SMTP layer — it's never stored, never delivered, never an event your application has to ignore: curl --request POST \ --url "https://api.us.nylas.com/v3/rules" \ --header "Authorization: Bearer $NYLAS_API_KEY " \ --header "Content-Type: application/json" \ --data '{ "name": "Block spam-domain.com", "priority": 1, "trigger": "inbound", "match": { "conditions": [ { "field": "from.domain", "operator": "is", "value": "spam-domain.com" } ] }, "actions": [{ "type": "block" }] }' There's a softer middle ground too: a rule with a mark_as_spam action routes matching mail to junk deterministically, without the terminal finality of block . Use it for gray-area senders — newsletters, notification floods — that you want out of the agent's way but available for review. Rules run in priority order from 0 to 1000, lower numbers first, so put your specific known-bad rules ahead of broad pattern matches. One scoping note: inbound rules match only sender fields — from.address , from.domain , and from.tld — with the operators is , is_not , contains , and in_list . String matching is case-insensitive, so you don't need variants for SPAM-Domain.com . Let the blocklist grow without redeploys Hardcoding domains into rule conditions works