The email error appears because the address book entry is only a recipient; the email function needs an SMTP relay to submit through. Enter the relay's host, port 587 with STARTTLS or port 25 on a plant relay, and the relay account credentials, in the email settings, then send the test message and confirm it in the inbox.
An email error on the panel means the alarm mail has nowhere to go. The address book entry you made is a recipient, not a mail server. The email function on an HMI submits every message to an SMTP relay, a server that accepts mail from the device and passes it on. A webmail mailbox sits at the far end of that chain, and a webmail account is not a relay. Enter the relay's host name, port and credentials in the email settings, keep the webmail address as the recipient, send the test message, and alarm mail starts to move. This page names the settings, the ports, and the checks that find the step that fails.
The address book and the outgoing server are two settings
The address book answers one question: who gets the alarm. The email settings answer another: which server carries it. A webmail address names a destination account at a provider. The email feature needs an SMTP server to submit through, and a destination account is not one. The device needs a relay it is allowed to use, with a host name, a port and credentials of its own.
Where those fields live depends on the HMI software. Two documented patterns cover most products. In software that distributes alarms through a dedicated object, the email settings are fields of that alarm distributor. On runtimes configured from the device's control panel, look for an E-mail settings page with an SMTP server field and a port field. Read the exact names from your own settings screens; the pair to look for is always recipient in one place, outgoing server in the other.
What the on-screen error tells you
- Error at the top left of the screen when an alarm fires. The alarm path reached a send attempt. The alarm logic is alive; the fault sits in the send path after it.
- The error shows and no mail arrives anywhere. The usual cause is a missing or unreachable relay. If the only mail setting entered was the recipient address, this is your case.
- The send fails within 1 second. The relay's name did not resolve, or the relay refused the connection. Check the name resolution first; HMI panel email send errors that trace to DNS have their own test order.
- The send hangs for 30 seconds or more, then fails. Something on the path is dropping the port, and the device waits out a connection timeout in that range before reporting. That is common where mail leaves through a firewall; sending HMI alarm email over a cellular router carries its own settings and tests.
- Test mail arrives but real alarm mail does not. The recipient is not attached to the alarm event in the alarm distribution settings.
Choose the relay and the port
The relay is either a server you control or a submission service the provider runs. Port 587 with STARTTLS, the setting that upgrades the connection to encrypted before login, is what most external relays require. Port 25 is for a relay on your own plant network that permits plain SMTP from the machine network; with the traffic staying inside the firewall, many plants run it without encryption. Port 465 is submission over implicit TLS; enter it only where the device's email settings list that encryption option, because older HMI email clients often ship without it.
| Port | Use it for | What you enter |
|---|---|---|
| 587 | A relay outside your plant, or any relay whose policy requires encryption | Host name, port 587, STARTTLS, user name, password |
| 25 | A relay on the plant network that allows plain SMTP from machines | Host name or IP, port 25, no encryption, credentials if the relay asks for them |
| 465 | Implicit TLS submission, only if the device lists the option | Host name, port 465, the device's TLS option, credentials |
Use 587 with STARTTLS whenever the relay sits outside the plant or policy requires encryption. Use 25 only for a relay you control that accepts plain SMTP inside the machine network. If the email settings offer no STARTTLS option and the only relay available demands it, no recipient address clears the mismatch; designate or stand up a relay that accepts what the device supports. Troubleshooting SMTP email when the provider requires STARTTLS walks that mismatch and its fix step by step.
Example: a webmail recipient and an email error at alarm time
The case: one address book entry holds a webmail address, an email error appears at the top left of the screen when an alarm fires, and no server settings were entered anywhere.
Inputs, with their sources:
- Address book: one webmail address as the recipient (the fault described above).
- SMTP server field: empty, because the address book entry was the only mail setting made.
- Relay for the fix: the plant's own mail server on the machine network. A typical plant relay accepts plain SMTP on port 25 from inside and STARTTLS on port 587, and this example assumes exactly that.
- The send path, in five steps: the alarm triggers a send; the device resolves the relay's host name; the device connects to the relay on the port; the device agrees encryption and logs in; the relay accepts the message and forwards it.
The rule: the message must pass all five steps, and the on-screen error proves the first one ran, because a send was attempted. Each later step has one matching check, and the first check that fails names the fix.
The arithmetic: 5 steps in the path. The error proves 1 of them. 5 - 1 = 4 steps still untested. Of those 4, steps 2, 3 and 4, name lookup, connection and login, depend entirely on the outgoing server settings, and the recipient address touches none of them. Only the last step involves an inbox. So 3 of the 4 untested steps are fixed by filling in the server settings, and editing the recipient can never reach them.
The result: enter the plant relay's host name, port 25 with no encryption, and the relay account's user name and password. Send the test message. It resolves, connects, logs in, and the relay accepts it; the message lands in the inbox.
The decision and its threshold: if the test still fails at the connection step after the port is confirmed open, or the device has no STARTTLS option and the only relay requires encryption, stop editing the address book. The fix is a relay that accepts what the device supports. A webmail-only setup with no relay is the one case with no device-side fix.
Set the relay and send a test message
- Open the email settings: the alarm distributor object in software that distributes alarms that way, otherwise the E-mail settings page in the device's control panel.
- Enter the relay's host name. A host name resolves only if the device has a DNS server address in its own network settings, so check those while you are there.
- Assign the port and encryption to match the relay's rules, as the table above shows.
- Enter the user name and password the relay requires. For a plant relay, IT issues these for the device.
- Leave the webmail address in the address book as the recipient, attached to the alarm event.
- Save the project, then run the built-in test send. If the software has no test function, trigger a controlled test alarm the way the site's procedure allows.
- Check the inbox, junk folder included, and confirm the message identifies the alarm.
Checks before you trust alarm mail
Treat the inbox as the proof. A cleared on-screen error only says the device handed the message to the relay; the message still has to arrive. Trigger one real alarm afterward and confirm its mail lands too, because the link between the alarm event and the recipient is its own setting.
Keep a local alarm path alongside the mail. Alarm history downloads only when logging was on, so leave logging enabled and a failed send still leaves a record. A pop-up message box shows the alarm at the panel even when mail is down. Where the line also needs the alarm visible to people nearby, a separate notice screen carries the display job; that is what our shop-floor signage is for.
Recommendation: point the email settings at a relay you control or a submission service your provider runs: the relay's host name, the port and encryption that match its rules, and the account credentials. Keep the webmail address as the recipient in the address book. Run the built-in test send, confirm the message in the inbox with the junk folder checked, and only then treat alarm mail as trustworthy.
Questions
Can a webmail address work as the SMTP server?
No. The address names a destination account at a provider, and the email settings need a relay the device may submit through. Providers publish their submission settings in their help pages: the host, port 587 with STARTTLS, and an app password where the provider issues one for equipment. If the email client on the device predates that security, point it at a relay that accepts what it supports instead of retrying the address.
Does the on-screen email error confirm the alarm logic works?
It confirms the alarm path reached a send attempt when the alarm fired. The four steps after that, name lookup, connection, login and acceptance, stay untested until a test message reaches an inbox. Mail that worked can stop later: providers change security policy and networks change, so run the test send again after either kind of change.
What if IT blocks SMTP from the machine network?
Ask the network owner for an allowed path: open the plant relay to the panel's address, or give the email settings an internal relay host name. Avoid public open relays, which fail spam filters and sit outside site policy. Where the plant network stays closed end to end, alarm mail can leave over a cellular connection instead, with its own relay and signal checks.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.