When I add an IMAP node to check a subfolder, the new mails are marked as read, due to the config, but the node has not triggered. When I “unread” them and trigger the node manually, it works. Just automatic trigger is not working correctly
IMAP Email Trigger Operation
The node connects to the IMAP server and uses the IDLE command (if available) to listen for new messages in real time.
If IDLE is not supported, you can use periodic polling.
Each new message that matches the filters triggers the flow.
Try the following:
Make sure you use the correct folder name, as interpreted by the IMAP server.
Example: Gmail: “[Gmail]/Inbox” or “INBOX/Subfolder”
Prevent other clients (such as Outlook) from automatically marking emails as read
As mentioned, mails are marked read by the node, it just does not trigger when enabled. It triggers only when running manually. Hence I assume filters and folder name are correct.
There is no other client marking the mails read.
The IMAP server is Fastmail.
Same Problem here. IMAP Trigger ist working correct in Test Mode, in active Mode Mails get marked as Read but nothings happens in the Workflow.
I have the same issue. I use n8n Version 1.88.0 (self hosted). IMAP from fastmail.
For gmail IMAP it worked fine.
Any solution found for this one? I am facing the exact same issue. Only Gmail IMAP Sseems working properly
Delete and recreate the workflow, I just tried and it works
I encountered a very strange problem. The email trigger of the archived workflow was still triggered.
Hey there,
I also have issues with the IMAP trigger on n8n stable @ docker. In manual test it sort of randomly succeeds, than again listening forever without input when adding new mails to the source folder and also not working when activated … 
I’m facing the same issue now. In addition, my workflow is running when I’m clicking on ‘Execute workflow’ but it’s neither getting published nor unpublished.
You can unarchive a workflow by following these steps. Go to workflows. On top right, you see ‘filter’ icon (beside ‘search’ and ‘create folder’ icons). Click on it. You will see a check box with label ‘Show archived workflows’. Check the box and you’ll see archived workflows. open the corresponding workflow, unarchive it (just like you archived it). stop the trigger and delete it if you wish to.
Same problem using the payed version of n8n on the cloud. I’m using IMAP of a Hostinger Mail Server.
From my tests, it seems the parameter Format=Resolved works, but Format=Simple don’t
I’m using self hosted version with Hostinger and it isn’t working for me too. When I add credentials it shows “Connection tested successfully” but node is not triggering. I’ve tested it with “INBOX” and “INBOX.subfolder”, Custom Email Rules both [“UNSEEN”] and [“ALL”]
And it seems that the Customer **(Un)**Success department is not very interested in fixing the IMAP problem, or even showing up here to provide any update or feedback.
Hi everyone,
Thanks for reporting this — we’ve identified and fixed several bugs in the IMAP Email Trigger node that could cause this behavior.
What was happening: When the IMAP server returned certain email formats, the trigger could crash silently and deactivate the workflow in the background. Emails would still get marked as read (since that happened before the crash), but the workflow would never execute. This particularly affected the Simple format — switching to Resolved could work around the issue, as some of you discovered.
What we fixed:
Added a safety check for malformed email headers in Simple format — previously a missing header would crash the trigger and silently deactivate the workflow
Fixed the mark-as-read logic to only flag emails that were actually processed and emitted to the workflow
Fixed duplicate processing when receiving large batches of emails (20+)
Added concurrency protection against rapid email notifications
Workaround until the fix ships: If you’re still experiencing this, try switching the Format parameter to Resolved. Also make sure the Force Reconnect Every Minutes option is set (under Options) — this helps with IMAP servers that don’t reliably send new-mail notifications.
The fix is in PR #30375 and should go live soon. Thank you for the detailed reports!
Great to see the n8n Team digging into this one! Thanks @garrit for the thorough breakdown of what was actually happening and for the fix in PR #30375.
Just to summarize the key points for anyone landing on this thread:
Root cause: When the IMAP server returned certain malformed email headers, the trigger crashed silently and deactivated the workflow in the background. Emails were still marked as read, but nothing executed.
Workaround (until the fix ships):
Permanent fix: Covered in PR #30375, keep an eye on the changelog for the version it ships in and update when it’s out.
Great community persistence on this one getting it properly investigated!