Triggering a workflow when an email arrives: n8n's Email Trigger (IMAP) node

A webhook starts a workflow when an application calls you; the Schedule Trigger when the clock decides. But a huge share of the events worth automating arrive through a much older channel: email. A support request, a supplier invoice as an attachment, a job application, an order confirmed by a third party with no API — all of it lands in a mailbox and stays there until a human opens it. n8n's Email Trigger (IMAP) node turns that mailbox into a workflow entry point: every new message becomes an item, with its sender, subject, body and attachments, ready to be classified, extracted, forwarded or processed.

The phenomenon you're trying to contain has had a name for thirty years: "email overload," described by Steve Whittaker and Candace Sidner in their foundational study Email overload: exploring personal information management of email (CHI 1996, ACM — see on Google Scholar). Their observation still holds: the inbox serves at once as a task queue, an archive and a communication channel — three functions no manual sorting can reconcile for long. That's exactly the argument for moving the sorting to the moment of arrival, automatically — which is what this guide sets up.

Why IMAP: the universal email trigger

n8n offers several ways to react to an email: the Gmail node's trigger, Outlook's, and the Email Trigger (IMAP) node. The first two are tied to one provider and its proprietary API, with the OAuth authentication that comes with it. The third speaks IMAP, the standard protocol that virtually every mailbox in the world exposes: an address hosted at OVH or Infomaniak, an Outlook or Gmail mailbox, a self-hosted mail server, the email that comes bundled with your web hosting.

That's what makes it the trigger of choice for a small business's functional addresses — contact@, support@, invoices@, jobs@ — which rarely live with a single big provider and sometimes move along with the hosting plan. No application to register in a developer console, no OAuth consent to renew, no proprietary API quota: a host, a port, a username, a password, and the workflow fires on every new message.

Two reasonable exceptions to this preference: if your email lives entirely on Google, the Gmail node with its own trigger is often simpler to configure and richer in operations (labels, threads) — our Gmail connection guide covers that path. Same logic on the Microsoft 365 side, detailed in our Outlook / Microsoft 365 guide. IMAP remains the common denominator when the mailbox lives elsewhere, or when you want a setup that survives a change of provider.

Creating the IMAP credential

The credential asks for four pieces of information, all supplied by your mail host:

• Host: the provider's IMAP server — ssl0.ovh.net at OVH, mail.infomaniak.com at Infomaniak, outlook.office365.com for Outlook, imap.gmail.com for Gmail. When in doubt, your provider's "set up a mail client" help page always lists these values.
• Port: 993, the standard IMAP port over SSL/TLS, with the secure connection option enabled. That's the setting to use everywhere today.
• User: the full email address, in nearly every case.
• Password: the mailbox password — with one important nuance for the big providers.

The Gmail case. Google no longer accepts regular account passwords over IMAP. You need to check that IMAP is enabled in the Gmail settings on one hand, and create an app password on the other — which requires two-step verification to be active on the account. It's that app password, not the account password, that goes into the credential. If this gymnastics feels heavy, that's the sign you should use the native Gmail node instead: its dedicated trigger goes through OAuth and avoids all this configuration.

Once the credential is saved, the node's test button tells you immediately whether the connection works. An authentication error on an OVH or Infomaniak mailbox almost always comes from a mailbox-specific password (different from the customer account's) or from two-factor authentication requiring, there too, an app password.

The Email Trigger (IMAP) node's parameters

The node is short, but each of its settings has concrete consequences:

• Mailbox: the folder being watched, INBOX by default. You can point it at any IMAP folder — and that's actually the best practice, as we'll see below: a dedicated folder (n8n, to-process) fed by a server-side filtering rule, rather than the entire inbox.
• Post-read action: what the node does with a message once retrieved, typically marking it as read. This is the key behavior of the whole setup: a message marked as read no longer matches the retrieval rule and will therefore not be reprocessed on the next pass. Only disable this marking if you know exactly why.
• Attachment download: when enabled, the node attaches every file in the message as binary data on the output item — essential for processing PDF invoices or documents received by email.
• Output format: Simple delivers ready-to-use fields (sender, subject, text and HTML body); Raw provides the raw message in source format, useful for fine-grained analysis needs (full headers, for instance) at the cost of parsing it yourself.
• Custom email rules: the advanced options let you customize the IMAP search rule used to retrieve messages, ["UNSEEN"] being the default logic — only take unread messages. You can narrow it further (by sender, by subject) using IMAP search syntax, but in most cases the filtering is better placed in a server-side rule than in the node.

How the node actually works

Unlike a webhook that passively waits for a call, the node maintains a connection to the IMAP mailbox and checks for new messages matching its rule. As soon as a message matches — unread in the watched mailbox, with the default UNSEEN rule — the workflow runs with that message as input, then the node applies its post-read action (marking as read).

This behavior has a happy consequence: emails that arrived while the instance was down (restart, update, outage) are not lost. At restart, they're still unread in the mailbox, so still eligible under the UNSEEN rule: the trigger picks them up and processes them. The queue is the mailbox itself.

But the same mechanism creates this node's sneakiest trap: anything that marks a message as read makes it invisible to the trigger. Open the mailbox in a mail client on your phone, leave a webmail tab open displaying the messages, or let a colleague "take a quick look" at the support mailbox — and the messages viewed vanish from the trigger's scope with no error, no trace, no execution. The workflow appears to work; it just processes fewer and fewer messages. It's the first thing to check when "some emails don't trigger the workflow": who else reads this mailbox?

Using the output: classify, extract, decide

Every processed email becomes an item with the sender, the subject, the body in text and HTML, and the attachments as binary data if download is enabled. It's ideal raw material for AI workflows, because the whole value of automatic sorting lies in the nodes that follow:

• Classify the type of request: a Text Classifier node routes each message to the right branch — sales question, support request, invoice, spam — from the subject and body. Our Text Classifier guide covers category definitions and confidence thresholds.
• Extract data from invoices received as attachments: the PDF binary flows into a structured extraction chain (amount, supplier, due date), as in our guide to extracting data from PDF invoices with AI.
• Detect phishing before a human clicks: sender, links and phrasing go through a dedicated analysis — the full setup is in our guide to detecting phishing and spam with AI.
• Prepare a draft reply: for requests classified as simple, an LLM node writes a proposed reply that a human validates before sending.

Example: automatically sorting the support@ mailbox

The representative setup, described end to end:

1. Email Trigger (IMAP) watches the n8n folder of the support@ mailbox, fed by a server rule (see the next section). Simple format, mark as read, attachments enabled.
2. Text Classifier sorts each message into four categories: urgent, product-question, billing, other. Each category prompt describes its case in one sentence with two examples.
3. urgent branch: a Slack node posts the message to the on-call channel with the sender and subject, tagging the person responsible.
4. product-question and billing branches: an HTTP Request node creates a ticket in the support tool with the right category pre-filled and the email body as the description.
5. other branch: the message goes to a weekly review folder, with no notification.

This workflow exists as a downloadable, ready-to-connect version: AI email sorting via IMAP, with the classification prompts and branches already wired — only the IMAP credential and the Slack channel remain to be filled in.

The robust pattern: dedicated address, dedicated folder

All the traps above (messages read by a human, double processing, shared INBOX) share the same structural solution:

• A dedicated address for the flow being automated (invoices@, support@) rather than a personal mailbox where messages to process mix with human conversations.
• A server-side filtering rule (a sieve or filtering rule at OVH, Infomaniak, Gmail or Outlook) that moves the messages to process into an n8n folder as soon as they arrive — by sender, by subject, or whatever matches the flow.
• The trigger pointed at that folder, and nobody else reads it. Humans keep the INBOX; n8n has its folder; mark-as-read can no longer collide with a mail client.

This split has a secondary benefit: the server rule acts as a free first filter, before the workflow even runs. Newsletters and automated notifications never reach the n8n folder, so they consume neither an execution nor an AI model call.

Common pitfalls

• Opening the watched mailbox in a mail client (phone, webmail) that marks messages as read: they become invisible to the trigger, with no error and no log. The classic symptom of the "workflow that misses emails."
• Watching INBOX on a shared mailbox instead of a dedicated folder fed by a server rule: guaranteed collisions between human sorting and automated sorting.
• Disabling mark-as-read with no other deduplication mechanism: the same messages remain eligible under the UNSEEN rule and can be reprocessed.
• Using the Google account password instead of an app password on Gmail: the IMAP connection will be refused. And if you're entirely on Google, the Gmail node is the simpler path anyway.
• Forgetting to enable attachment download and then hunting for the invoice PDF in the JSON: the files only exist as binary data if the option is enabled.
• Wiring two workflows to the same mailbox with the same rule: whichever marks the message as read first steals it from the other. Two separate folders, fed by two server rules, solve the problem cleanly.
• Choosing the Raw format without needing it: the raw message requires manual parsing that the Simple format makes unnecessary in the vast majority of cases.

In summary

The Email Trigger (IMAP) node is the universal mailbox trigger: four credential fields (host, port 993, user, password), one folder to watch, and every email becomes a usable item with its subject, body and attachments. Its mechanics fit in one rule — retrieve unread messages, mark them as read after processing — from which flow both its robustness (emails that arrived during an outage are caught up) and its single real trap (any external read makes messages disappear). The dedicated address + server rule + n8n folder pattern neutralizes that trap once and for all. To go from the trigger to the complete system — request classification, prioritization, attachment extraction and draft replies — the Inbox AI Pack (€79) provides the full set of mailbox sorting and prioritization workflows, ready to import, including the finished version of the support@ example described in this guide.