Email triage automation: patterns that work and ones that backfire

A shared inbox gets a few hundred messages a day. Some are customers waiting on an answer, some are invoices, and a lot are newsletters, notifications and other machines talking to you. Someone spends the first hour of every morning sorting it, and the obvious move is to automate that hour.

Email triage is a good candidate for automation, but it's also one of the easier places to cause quiet damage. A rule that files an urgent complaint under "newsletters" doesn't throw an error. An auto-reply that argues with another auto-reply can fill two mailboxes overnight. A forwarding rule can send company mail somewhere it shouldn't go for months. The patterns below are the ones that hold up, followed by the ones that tend to bite.

Decide what triage is for before you build it#

Triage means deciding three things about each message: who should deal with it, how soon, and whether anyone needs to see it at all. It doesn't mean answering it.

Write down the handful of buckets your team actually acts on. For a small services business that might be: customer requests, supplier invoices, internal, automated notifications, and marketing. Five buckets you act on beat fifteen that nobody looks at. If a category doesn't change what a person does next, it's decoration, and every extra category is another place for a message to be misfiled.

Also decide where an unsure message goes. Every triage setup needs a "needs a human" lane, and it should be the default when nothing matches confidently.

Let the headers do the cheap sorting#

A surprising share of inbox noise labels itself, and you can sort it with plain rules before any AI is involved.

Many mailing lists add a List-Id header. RFC 2919 defines it so software can reliably identify messages from a particular list even when the list's host or address changes, which is exactly what you want a filter to key on. Large senders have a reason to label their marketing mail too: Google's email sender guidelines require anyone sending more than 5,000 messages a day to Gmail accounts to support one-click unsubscribe through the List-Unsubscribe and List-Unsubscribe-Post headers, along with SPF, DKIM and DMARC authentication.

Automated mail often says so as well. RFC 3834 recommends an Auto-Submitted header on machine-generated messages, with auto-generated for things like periodic reports and auto-replied for automatic responses.

None of these headers is guaranteed to be present, and a sender can set them however it likes. But as a first pass they're cheap, deterministic and easy to explain. A rule like "has a List-Id, goes to the Lists label" will be right far more often than it's wrong, and when it's wrong you can see exactly why. Sender domains you know (your accounting system, your payment provider, your monitoring tool) are the other easy win.

Patterns that hold up#

Label, don't delete. Gmail filters can label, archive, delete, star or forward incoming mail, and the safest of those are the ones you can undo. Labelling and archiving leave a message findable. Deleting it means a misfire only gets noticed when a customer chases you.

Keep the rules in one place with one owner. Rules spread across five people's mail clients, a shared mailbox and a third-party tool are impossible to reason about. Gmail lets you export filters as an XML file you can read in a text editor, which gives you a cheap backup and something to diff when behaviour changes.

Route by sender and headers first, then by content. Rules about who sent something are stable. Rules about what's in the subject line ("invoice", "urgent") break as soon as someone phrases things differently.

Give the uncertain lane a real owner and a time limit. If "needs a human" turns into a folder nobody opens, you've built a slower way of losing mail.

Watch replies. Gmail's help page notes, in its section on forwarding filters, that a reply to a filtered message is only filtered if it meets the same search criteria, so a conversation can start in one place and continue in another. Check that your buckets make sense for threads, not just first messages.

Where an LLM fits, and what it should be allowed to do#

Rules run out when the signal is in the wording: telling a complaint from a routine question, or spotting that a "quick query" is really a cancellation. That's a reasonable job for a language model, as long as its job is classification and nothing else.

Email is also the textbook route for indirect prompt injection. OWASP's LLM01:2025 entry describes indirect injection as an LLM taking input from external sources, and one of its example scenarios is an attacker exploiting a vulnerability in an LLM-powered email assistant (CVE-2024-5184) to inject malicious prompts, get at sensitive information and change email content. Every message in your inbox was written by someone outside your control.

OWASP's mitigations translate directly into triage design. Restrict the model's privileges to the minimum it needs. Put a human in the loop for privileged operations. Separate and clearly mark untrusted content so it has less influence on the instructions. In practice that means the model reads a message and returns one label from a fixed list (structured output, validated in code). It doesn't send, forward, delete or call other tools. If a message tries to talk the model into something, the worst outcome is a wrong label, which lands in the review lane. We cover the wider problem in our post on prompt injection.

Backfire: auto-replies that talk to other robots#

The oldest email automation failure is the mail loop. RFC 3834 gives the classic case: a loop can happen if both the sender and the recipient of a message have automatic responders. Each reply triggers the other.

The RFC's recommendations are short and worth following in anything that replies automatically, including an "AI acknowledgement" email:

• Don't send an automatic response to any message whose Auto-Submitted header has a value other than no.
• Mark your own automatic responses with Auto-Submitted: auto-replied.
• Consider ignoring messages that carry any List-* header, so you don't reply to a whole mailing list.
• For "I'm away" style notices, don't send the same response to the same sender more than once within several days; the RFC suggests a seven-day default.
• Send responses to the message's Return-Path, not to an address pulled from the body.

If you're building a custom auto-acknowledgement, check these by sending it a message from another auto-responder before it goes live.

Backfire: forwarding rules#

Forwarding feels like the simplest automation there is. It's also one of the first things attackers set up after getting into a mailbox.

MITRE ATT&CK lists email forwarding rules as a collection technique. Its entry notes that a rule can keep an adversary's access to a victim's email going even after the compromised credentials are reset, and that rule properties can be modified through MAPI so the rule is hidden from Outlook, Outlook on the web and most Exchange admin tools. Microsoft's own documentation on automatic external forwarding says forwarding "can also pose a security risk due to the potential disclosure of information", and that users can set up inbox rules forwarding to external recipients "deliberately or as a result of a compromised account".

That page also explains a default that catches people out. The "Automatic - System-controlled" setting changed in 2021 to mean forwarding is off for new organisations, but organisations that were already relying on it may still have it behave as on. Microsoft recommends setting On or Off explicitly instead. If your triage plan includes forwarding anything outside the organisation, make that a deliberate, documented exception rather than something an individual's rule happens to do. MITRE's mitigations (audit inbox and transport rules regularly, consider disabling external forwarding) are a sensible monthly habit either way.

Backfire: giving the automation the whole mailbox#

Third-party triage tools and home-built scripts both need access to your mail, and it's easy to grant more than they use.

Google's guidance on Gmail API scopes is to choose the most narrowly focused scope possible. The differences are real. The full-access https://mail.google.com/ scope can permanently delete mail, bypassing the trash. gmail.modify can read, compose and send but can't permanently delete. gmail.labels only views and edits labels, and is the one scope in that set Google classes as non-sensitive. A triage tool that only labels and archives has no business holding the full-access scope, and if a vendor asks for it, ask why.

Backfire: misfiling nobody notices#

The most common failure isn't dramatic. A rule quietly starts catching the wrong messages, perhaps because a supplier changed their sending domain or a customer's reply happened to contain the word "newsletter", and nobody looks in that folder for weeks.

Treat triage like any other automation you need to trust. Before switching it on, run it in shadow mode for a week or two: let it label, keep the old process going, and compare. Afterwards, sample the low-attention buckets on a schedule and track how often a person has to move a message. Our guide to evaluating an AI automation goes through building the test set.

The order that tends to work: headers and known senders first, a small LLM classifier for what's left with labels as its only output, a staffed review lane for anything uncertain, and no automatic replies, forwards or deletes until each one has been checked against the failure it's most likely to cause. Start with the noise you can sort with certainty, and leave the hard calls with people until the numbers say otherwise.

Sources

1. Recommendations for Automatic Responses to Electronic Mail (RFC 3834) — K. Moore, IETF (August 2004) (checked 2026-10-21)
2. List-Id: A Structured Field and Namespace for the Identification of Mailing Lists (RFC 2919) — R. Chandhok and G. Wenger, IETF (March 2001) (checked 2026-10-21)
3. Email sender guidelines — Google, Gmail Help (checked 2026-10-21)
4. Create rules to filter your emails — Google, Gmail Help (checked 2026-10-21)
5. Choose Gmail API scopes — Google for Developers (checked 2026-10-21)
6. Control automatic external email forwarding in Microsoft 365 — Microsoft Learn (updated 18 August 2026) (checked 2026-10-21)
7. Email Collection: Email Forwarding Rule, Sub-technique T1114.003 — MITRE ATT&CK (checked 2026-10-21)
8. LLM01:2025 Prompt Injection — OWASP Gen AI Security Project (checked 2026-10-21)