Skip to main content
Solved

SMTP Email monitoring issue

  • Oct 14, 2026 3:08 PM UTC
  • 3 replies
  • 52 views

parke372
Contributor
Forum|alt.badge.img+11

i’m using: FME Flow 2025.1.3.3 Build 25648 - win64

I’ve configured the SMTP settings in System Email under Network and Email - it validates with a green checkmark.

I then created a new flow with a Email - SMTP (received) using the same account as the one in system configuration. that also validates as correct.

when i run the flow and send emails to the address, nothing triggers.

i checked log files and found the following:

FME automations log:
Wed-14-Oct-2026 10:44:03.264 AM | INFORM | pool-6-thread-1 | SolarWinds Monitoring (85583c2d-4e61-4bd2-a384-41640a91ca35) | no-event | 410150 : (Automations) Logging events for component...
Wed-14-Oct-2026 10:44:03.268 AM | INFORM | pool-6-thread-1 | SolarWinds Monitoring (85583c2d-4e61-4bd2-a384-41640a91ca35) | no-event | 410109 : (Automations) Creating link from trigger...
Wed-14-Oct-2026 10:44:03.285 AM | INFORM | pool-6-thread-1 | SolarWinds Monitoring (85583c2d-4e61-4bd2-a384-41640a91ca35) | no-event | 410108 : (Automations) Creating email trigger...
Wed-14-Oct-2026 10:44:03.311 AM | INFORM | pool-6-thread-1 | SolarWinds Monitoring (85583c2d-4e61-4bd2-a384-41640a91ca35) | no-event | 410105 : (Automations) Creating project "SolarWinds Monitoring"...
Wed-14-Oct-2026 10:44:03.311 AM | INFORM | pool-6-thread-1 | SolarWinds Monitoring (85583c2d-4e61-4bd2-a384-41640a91ca35) | no-event | 410116 : (Automations) Finished assembling automation "SolarWinds Monitoring"


Trigger Email log:
Wed-14-Oct-2026 10:44:03.342 AM | INFORM | main | SolarWinds Monitoring (85583c2d-4e61-4bd2-a384-41640a91ca35) | no-event | 801004 : Configuring email account for user: blahblahblah

i found an article talking about this:
https://support.safe.com/hc/en-us/articles/25407759987981-Run-a-Workspace-in-Response-to-Incoming-Email

my fme flow server has a DNS entry with our domain DNS am i wrong in assuming if it validates in system configuration and the individual flow that this should work?

Best answer by macatsafe

Hi ​@parke372 

System Email controls outgoing mails, which FME Flow uses for sending notifications, it isn't involved in receiving email.

 

The Email - SMTP (received) trigger works differently: FME Flow acts as a lightweight mail sever to receive emails from external servers. That's why the requirement is your Flow instance needs a proper DNS record (server is accessible over the internet), with an MX record for the FME Flow hostname.

 

The green checkmark when you validates the SMTP trigger only means the form is filled in correctly. It doesn't test whether mail can actually reach the server.

 

To make sure the server is reachable from wherever the mail is coming from:

  • Port 25 and Port 7125 are open, with no firewall or ISP blocking it

  • Do you use FME Flow as email server or there is a separate server that relays emails to FME Flow?

    • If you use FME Flow as email server: First the server must be accessible over the internet. Second when you add a username to the trigger, you essentially create an email address on FME Flow's email server, using the hostname as the email domain. So if your Flow hostname is flow.example.com, the email address would be blahblahblah@flow.example.com.

    • If you use a separate server that relays the email to FME Flow, another thing to note: a rule must be configured on the email server that relays emails for the specified Email User Name on to FME Flow. The rule must specify the FME Flow machine name and SMTP port.

 

Also, SMTP isn't supported in fault-tolerant. If this is your Flow architecture, that might explain it.

View original

3 replies

macatsafe
Safer
  • Safer
  • Best Answer
  • Oct 29, 2026 5:18 PM UTC

Hi ​@parke372 

System Email controls outgoing mails, which FME Flow uses for sending notifications, it isn't involved in receiving email.

 

The Email - SMTP (received) trigger works differently: FME Flow acts as a lightweight mail sever to receive emails from external servers. That's why the requirement is your Flow instance needs a proper DNS record (server is accessible over the internet), with an MX record for the FME Flow hostname.

 

The green checkmark when you validates the SMTP trigger only means the form is filled in correctly. It doesn't test whether mail can actually reach the server.

 

To make sure the server is reachable from wherever the mail is coming from:

  • Port 25 and Port 7125 are open, with no firewall or ISP blocking it

  • Do you use FME Flow as email server or there is a separate server that relays emails to FME Flow?

    • If you use FME Flow as email server: First the server must be accessible over the internet. Second when you add a username to the trigger, you essentially create an email address on FME Flow's email server, using the hostname as the email domain. So if your Flow hostname is flow.example.com, the email address would be blahblahblah@flow.example.com.

    • If you use a separate server that relays the email to FME Flow, another thing to note: a rule must be configured on the email server that relays emails for the specified Email User Name on to FME Flow. The rule must specify the FME Flow machine name and SMTP port.

 

Also, SMTP isn't supported in fault-tolerant. If this is your Flow architecture, that might explain it.


parke372
Contributor
Forum|alt.badge.img+11
  • Author
  • Contributor
  • Oct 30, 2026 9:57 AM UTC

​@macatsafe thanks for the reply! i was thinking that the SMTP trigger would use the SMTP settings from the system email.. i’m not sure why? :D

i am using a separate server, and your explanation would certainly explain why it isn’t working - I didn’t request any rules of any sort from the mail team when they were helping me (though, you’d think they’d have some knowledge of this..)

i will reach out to them and discuss this.

 


parke372
Contributor
Forum|alt.badge.img+11
  • Author
  • Contributor
  • Nov 11, 2026 5:52 PM UTC

so it turns out, after a lot of testing that ultimately it appears that IMAP with Auth 2.0 instructions assumes Microsoft single sign on, but we are using Okta. currently, there is no way for us to “whitelist” the request through okta, so this avenue is not open to us.