GUI-049 means the panel started an email test and the SMTP session never finished. Ports 25 and 587 with authentication on and off are the whole matrix the panel controls; when all four combinations fail the same way, the server wants something the panel cannot send. The fix is DNS first, then a relay or a mailbox provider that accepts the panel's basic SMTP.
GUI-049 on the address-book email test means the SMTP session never completed. You have already run the panel's whole matrix, ports 25 and 587 with the SMTP authentication box checked and unchecked, so the answer is not another checkbox. The mail server wants a feature this class of panel cannot send. Most often it is an encrypted session or a modern login. Clear DNS and the network path first. Then put a relay you control between the panel and the mailbox, or move the account to a provider that still accepts plain authenticated submission. The sections below split those stages apart and end with the relay fix in numbers.
What does GUI-049 mean on the email test?
GUI-049 is the panel's code for an email test that never finished the SMTP exchange. The name would not resolve, the connection was refused or blocked, the login was refused, or the sender was rejected, and the panel reports the same code for every one of those. The code covers the whole exchange, from name resolution to the accepted message. It names the failed test and hides the failed stage. Find the stage with separate checks, about 30 seconds each. Every cause below has the check that identifies it.
- The SMTP hostname does not resolve from the panel's segment: the panel's DNS server setting is empty or unreachable. Fix that setting first and run the test again.
- The TCP connection to the mail port times out, often 20 to 30 seconds of waiting: a firewall or router blocks client mail from the panel's subnet. Ask whoever owns that firewall for an approved path.
- The connection opens and the session still fails: the server answered and then refused the session setup or the login. That is a protocol mismatch, and the rest of this page is about it.
- The login is accepted and the sender is refused: many providers accept submission only from their own account addresses. Set the sender field to the mailbox you registered.
One mistake produces the same code before any of that: entering a webmail address where the SMTP server name belongs. The difference between an SMTP server and a webmail address is worth 30 seconds before anything else.
What should you record before changing any mail setting?
Write down six values before the first change: the SMTP server name, the port, the authentication checkbox state, the sender address, the test recipient, and the panel's DNS server. Every later change now has a rollback point and a clean report. Change one setting and run one test after each change. Two changes in a single pass make the next result unreadable and cost you the rollback. The recorded list also becomes the report for whoever owns the mail service, which shortens every later conversation.
Is the panel's DNS or firewall blocking the SMTP connection?
Test two things from a laptop on the panel's own segment: resolve the SMTP hostname through that network's DNS, then open a TCP connection to the configured port. A failed lookup points at DNS and a failed connect points at the firewall.
- Read the panel's DNS server and gateway settings and add them to the recorded list.
- From a laptop on the panel's segment, resolve the SMTP hostname through that network's DNS.
- From the same laptop, open a TCP connection to the mail port you configured.
- Read the pair of results: a failed lookup is a DNS problem, a failed connect is a firewall problem, and two passes leave the SMTP protocol as the remaining suspect.
Run both checks on the panel's segment, where its DNS server and firewall rules apply. The full check DNS first sequence covers the resolution side in more depth.
Why do ports 25 and 587 both fail with authentication on and off?
Two ports times two authentication states is four tests, 2 × 2 = 4, and four identical GUI-049 results point to a server that wants something outside that matrix. Most often it is an encrypted session or a modern login this panel cannot send. Port 25 is the mail-transfer port between servers, and many networks block it for client-originated mail. Port 587 is the submission port for clients, and the common pattern on it is STARTTLS: the connection opens in the clear and the server requires an upgrade to encryption before it accepts a login at all. A panel with basic SMTP opens the TCP connection and then has nothing to offer that handshake.
Add the authentication box and you have the full matrix the panel controls. When all four combinations return GUI-049, the server is asking for something outside the matrix. A fifth permutation of the same settings repeats the failure, so stop and move on.
What SMTP features does the panel support?
Panels of this class implement basic SMTP: a server name, a port, a sender, and a username and password behind an optional plain login. That is the whole menu, and it is why large hosted mailbox services refuse them. What is missing is everything those providers now build submission on: encrypted sessions negotiated mid-connection, and token-based modern logins.
For example, one large hosted mail service lets administrators switch password-based authenticated client SMTP submission off for the whole tenant and back on per mailbox, with a modern token login offered as the alternative. That is the market direction: even a correct password gets refused when the tenant never enabled that login type. Sender policy sits on top, since the provider accepts mail from its own account addresses and refuses other senders.
When do you stop blaming settings and fix it with a relay?
Stop cycling settings once a TCP connection to the provider's port opens and the session still fails. From that point the fix is a relay you control, or a mailbox account whose provider still accepts plain authenticated submission. Work the cases in order:
- DNS failed: correct the panel's DNS server, retest, and you are often done in 5 minutes.
- The port is blocked: the network owner opens an approved path from the panel subnet to your relay, and the panel never needs the public internet at all.
- The port opens and the session fails at the provider: this is the relay case.
- The sender is refused: set the sender to the account address and retest before touching anything else.
The relay is a small mail forwarder on a server you control, on the plant LAN. The panel sends it basic SMTP with a plain login. The relay holds the real account credentials and forwards to the provider over the encrypted submission the provider demands. One alternative also worked in the field: moving the account to a free mailbox provider that still accepts plain authenticated submission restored the test after several attempts. Prefer the relay when any server on site can run it. You own the compatibility instead of renting it from a provider's policy page. Keep the plain-password leg on the plant LAN; the encrypted leg to the provider is the relay's job on the way out.
Worked example: five tests to a green check
One panel with this error code ran 2 × 2 = 4 failing combinations against the provider, then one new combination against an on-site relay: port 25 with plain authentication. The fifth test passed and delivered the message in under 60 seconds. Here is the test log:
| Test | Server | Port | SMTP auth | Result |
|---|---|---|---|---|
| 1 | provider | 25 | off | GUI-049 |
| 2 | provider | 25 | on | GUI-049 |
| 3 | provider | 587 | off | GUI-049 |
| 4 | provider | 587 | on | GUI-049 |
| 5 | on-site relay | 25 | on | pass |
The arithmetic: 2 ports × 2 authentication states = 4 tests against the provider, all ending in GUI-049. The segment checks passed in between: the hostname resolved on the panel's segment in under 1 second, and a TCP connection to port 587 opened in about 2 seconds. That cleared DNS and the firewall and left the protocol. The relay ran on the plant server, listening on port 25 for the panel's subnet with one plain-login account, forwarding to the provider on port 587 over an encrypted submission connection. The panel's new settings were the relay host, port 25, authentication on, and the sender set to the relay account address. Test 5 passed: 4 + 1 = 5 tests to a green check, about 10 minutes of testing in all, and one message to the maintenance list arrived in the mailbox.
How do you confirm the alarm emails really send?
Run the address-book test until it passes. Then send one message to a real mailbox and open that mailbox: a passing panel test tells you the panel handed the message over, and the opened mailbox tells you it arrived.
- Run the address-book test until it returns success.
- Send one message to a real mailbox and open that mailbox.
- On the relay, read the log entry for the session: connection from the panel's address, accepted login, message queued, message forwarded. The last entry present shows how far the session got.
- Check the sender address the recipient sees, so replies and mailbox filters behave.
- Trigger one real alarm event and watch it land end to end within 60 seconds of the event.
If the goal is a phone alert rather than a mailbox, send alarm emails to a phone as text messages shows the address formats, and sending alarm mail over a cellular router covers sites with no wired path out.
Recommendation: After four GUI-049 results on the provider's server, 2 ports × 2 authentication states, stop testing the provider and put a relay you control in the path: basic SMTP from the panel to the relay on port 25 across the plant LAN, encrypted submission from the relay to the provider on port 587. Switch the account to a plain-submission mailbox provider only when no server on site can run the relay.
Questions
Does GUI-049 point to one specific fault?
No. The panel reports GUI-049 for any email test that fails to finish the SMTP exchange: an unresolved name, a blocked port, a refused login or a rejected sender all produce the same code. Split the problem with separate checks for DNS, the TCP connection and the credentials, in that order, and the failing stage shows itself.
Why would the same settings work for years and then fail with GUI-049?
Hosted mailbox providers tighten submission policy over time. A tenant-wide switch to modern token logins retires the plain password login the panel uses, sometimes on a set date. A relay on your own server survives those changes, because the panel talks to the relay and only the relay follows the provider.
Is plain SMTP with a password safe on my network?
Keep the plain-password leg on your own switched plant LAN, between the panel and your relay, where the exposure is limited to that LAN. Never send those credentials across the public internet in the clear; that traffic belongs on the encrypted leg between the relay and the mailbox provider.
Should I keep trying more ports and account settings?
The panel controls a small matrix: 2 ports times 2 authentication states is 4 tests. Four identical GUI-049 results say the server requires a feature outside that matrix, so further cycling spends an afternoon and returns nothing. Move to the relay, or to a provider that still accepts plain authenticated submission.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.