Troubleshooting Tip: Email alerts
| Description | This article describes troubleshooting steps to perform when Email alerts are not received. This covers scenarios using the default FortiGate settings using the Fortinet Email relays/servers (notifications.fortinet.net,fortinet-notifications.com) or when using a relay/server defined by the administrator. |
| Scope | FortiGate. |
| Solution | Step 1: Verify WAN connectivity to the mail server.
Before investigating email configuration, confirm the FortiGate has a working path to the default mail server: notification.fortinet.net or fortinet-notifications.com.
execute ping fortinet-notifications.com
If ping fails, confirm the WAN interface is up, that a default route exists, and that outbound firewall policy permits traffic from the FortiGate itself (not just through it). Confirm system DNS settings.
Step 2: Verify TCP connectivity on the mail port.
ICMP success does not guarantee the SMTP port is reachable. Test the actual TCP connection:
execute telnet 208.91.114.151 465
Working scenario:
Trying 208.91.114.151... Connected to 208.91.114.151.
Non-working scenario:
Trying 208.91.114.151... Connected to 208.91.114.151. x.x.x.x is blocklisted by FortiGuard. This email from IP has been rejected. The email message was detected as spam. Connection closed by foreign host. If the response displays the message seen above, submit a request for re-evaluation to the FortiGuard team on the AntiSpam Blocklist Appeal form, and ensure to include the public source-IP used by the FortiGate.
Step 3: Review the email server configuration.
Check the existing configuration in FortiGate.
get system email-server
The following is an example of default settings:
type : custom
Common configuration issues to check:
If the FortiGate has multiple WAN interfaces or uses SD-WAN, interface-select-method auto may select the wrong interface. Force it explicitly if needed:
config system email-server set interface-select-method specify set interface "wan1" end
Available options:
set interface-select-method ?
When the custom email server is used on FortiGate to send the emails out from the FortiGate for purposes like FortiToken Activation Email or Email Alerts, the emails may not be received on the user side.
Check the connection to the Email Server:
execute ping <SMTP server IP>
If the ping succeeds, the FortiGate has a basic network path to the server. If it fails, investigate routing, firewall policy, and whether the server IP is correct in config system email-server.
If the SMTP server is beyond the IPsec tunnel, set the source IP in the email server settings of the FortiGate with the internal interface IP so that FortiGate can reach the server over the tunnel.
config system email-server ... set source-ip {ipv4-address} ... end
Starting from v7.4.4, the default email server changed from notification.fortinet.net to fortinet-notifications.com. This server is only available to registered FortiGate devices with an active FortiCare support contract.
config alertemail setting
In newer versions (7.4.4+ and 7.6.0+), the 'reply-to' field is no longer configurable: Technical Tip: Unable to configure 'Default Reply To' via GUI and CLI.
Step 4: Confirm the alertmail recipient is configured.
Before running the debug commands, ensure the alertmail setting has a recipient:
config alertemail setting ... set mailto1 "test@example.com" ... end
Refer to this article to configure it: Technical Tip: How to configure alert email settings.
Step 5: Enable debug and send a test email.
Run the following alert email debugs to see if there are any errors.
diagnose debug reset
diagnose log alertmail test
Capture all output before disabling debug:
diagnose debug disable
Step 6: Interpret the debug output.
A complete, successful SMTP exchange looks like this:
2024-11-25 00:04:42 Arrived msg(type 8, 818 bytes):XXXXXX@gmail.com <----- User's email. "EEIJEOT7WMAVXDHV" Alternatively, use the attached QR code image to activate your token with the "Scan Barcode" feature of the app. FortiGate 2024-11-25 00:04:42 mail_info:
If any failures or errors show in the debugs, check for the following things:
diagnose sniffer packet any 'host <server IP> and port <port no>' 4 0 l
Common failure scenarios details with debug output:
Scenario 1: SSL_connect failure (custom server, port/security mismatch) If a custom SMTP server is configured with set security smtps but the server expects STARTTLS on port 587 rather than native SMTPS, the SSL handshake will fail. The debug shows the SSL structure being created but immediately failing to connect:
2024-12-31 10:19:58 connecting to 10.10.110.39 port 587
The above error is seen when using an SSL-enabled security mode under the email-server settings as follows:
config system email-server
To bypass this error, use 'set security none'.
Scenario 2: SSL_connect failure (default server, FortiGuard anti-spam blocklist).
A similar error in SSL_connect (null) can occur when using the default fortinet-notifications.com server if the FortiGate's public IP is blocklisted by FortiGuard Anti-Spam. Unlike the port mismatch scenario above, this occurs even with a correctly configured default setup:
connecting to 208.91.114.151 port 465 _session_on_destroy
To verify, cross-check on the AntiSpam Service. If it is found that the IP is marked as spam, contact the FortiGuard AntiSpam team via AntiSpam Contact Form to request whitelisting.
Scenario 3: SMTP authentication failure (code: 530 | code: 550).
In some cases, it is possible to see an error with 'code: 530', which states that the issue is with the server, specifically, the client would not be successfully authenticated by the server. This can also be confirmed by taking a packet capture in the firewall for the port that is being listened to by the email server.
024-09-02 21:53:38 create_ssl: 0x7f9561385000
And the error with 'code 550' is normally due to a few possibilities, such as a recipient address being invalid, poor sender reputation, a recipient sender block caused by a full inbox, and server policy limitations.
2025-12-02 17:04:48 create_ssl: 0x7face42800 2025-12-02 17:04:48 sessionn 0x2e677940, SSL connected 2025-12-02 17:04:48 session: 0x2e677940, rsp_state: ehlo, code: 250 2025-12-02 17:04:48 session: 0x2e677940, rsp_state: auth, code: 334 2025-12-02 17:04:49 session: 0x2e677940, rsp_state: auth2, code: 235 2025-12-02 17:04:49 session: 0x2e677940, rsp_state: mail, code: 550
Scenario 4: Sender and recipient address are identical.
In the alertmail debugs, check whether the sender and receiver email addresses are different. Sometimes, if the sender and receiver email addresses are the same, the email server blocks the email send request. See the example logs below where the sender and receiver email addresses are the same:
WIG-FGT-01 (global) # Arrived msg(type 6, 83 bytes):sajeermkit@gmail.com AuthCode: 240126 mail_info:
Scenario 5: Fortinet_Factory certificate failure.
As fortinet-notifications.com uses the Fortinet_Factory certificate to set up an SSL connection, the certificate must be valid. A broken certificate may result in the following debug output:
2025-12-30 14:54:13 connecting to 208.91.114.151 port 465
To verify, run the following command:
diagnose hardware certificate
Output:
Checking Fortinet_CA.cer integrality ........Passed
As a workaround, failover to another FortiGate if the other unit does not have this issue.
Scenario 6: No debug output generated.
Sometimes it may happen that even after the debug commands are in place and the command diagnose log alertmail test is run, there is no output generated. In those scenarios, check the alertmail process (especially in low-end devices)
diagnose sys top 2 99 10 | grep alertmail
If the CPU shows 99 percent constantly, try restarting the alertmail process:
diagnose sys kill 11 <pid>
Scenario 7: Send mail failed with the following errors.
2026-04-08 16:42:08 <== send mail failed, m = 0x5598d77d0 s = 0x559d527d0
Arrange a maintenance window. Console access is needed for both units (if there is an HA cluster).
Prepare and verify a working TFTP server that can be used if formatting or image loading is required by a TAC engineer. For information on TFTP server preparation, see Technical Tip: Formatting and loading FortiGate firmware image using TFTP.
Test each unit separately in standalone mode before forming the HA cluster and collecting new debug output (if there is an HA cluster). If one standalone unit shows the same problem, factory reset the unit with the issue and load back the backup configuration file, and test again. If both standalone units work correctly, proceed with forming the HA cluster again.
Note: If the process form above resolves the issue, this is an individual problem with the specific unit in use, and this is not reproducible in Fortinet's lab.
If the issue persists after reviewing the resource, open a case with TAC through the Fortinet Support Portal. Collect all debug files and the outputs of the commands listed above, and submit them with the TAC ticket along with the FortiGate configuration file.
Related articles:
|