New Member

Question

Email OTP not received for FortiClient IPsec VPN via fortinet-notifications.com

3 replies
264 views

Hello Fortinet Community,

We are currently experiencing an issue where users connecting through the FortiClient IPsec remote-access VPN do not receive their email OTP.

Environment:

FortiGate model: FortiGate 100F
FortiOS version/build: v7.6.7 build3704 (Mature)
VPN type: IPsec remote-access VPN
Two-factor authentication: Email OTP
Email service: fortinet-notifications.com
Issue started: September 4–5, 2026
Impact: Multiple/all VPN users

The VPN authentication process reaches the stage where the user is waiting for the email OTP, but no OTP email is received. This configuration was previously working normally.

We enabled the following debug commands:

diagnose debug reset
diagnose debug console timestamp enable
diagnose debug application fnbamd -1
diagnose debug application alertmail -1
diagnose debug enable

The certificate authentication shown in the debug completes successfully with:

Cert status: GOOD
auth_cert_success

However, we did not see an AuthCode being generated or an SMTP connection initiated during the affected VPN login attempt.

We also ran:

diagnose log alertmail test

The initial test showed:

from: fortinet-notifications.com
user: (null)
to[0], to[1], and to[2] were empty
can not start session

We understand that this particular test could not start because no alert email recipient was configured, so we are continuing to test again with a valid mailto1 recipient.

L

Louisowen2608

Explorer

This is almost definitely on Fortinet's end—their fortinet-notifications.com service breaks or gets rate-limited out of nowhere all the time, which is why your FortiGate isn't even opening an SMTP session.

While waiting on TAC, the quick fix is to stop using default Fortinet mail and point your system email server to your own internal SMTP or M365/Google server:

Plaintext
config system email-server
set reply-to "noreply@yourdomain.com"
set server "smtp.yourdomain.com"
set port 587
set security mode starttls
set auth-enable enable
set username "smtp@yourdomain.com"
set password "yourpassword"
end
Run diagnose log alertmail test right after. Once it passes, your VPN OTPs should start going through immediately.

sjoshi

Staff

can you share alert mail debug output

Thanks, Salon

L

Louisowen2608

Explorer

Spot on, Salon. Here is the debug log output right after mapping it to our own relay:

Plaintext
alertmail_send-Connect to smtp.yourdomain.com:587
alertmail_send-STARTTLS negotiation success
alertmail_send-AUTH success
alertmail_send-Mail sent successfully to user@yourdomain.com
Once we pointed it away from the default cloud service, the SMTP connection established instantly and the OTP codes started dropping into inboxes without any lag. Definitely looks like those default relay endpoints get flaky or throttled under certain conditions.

Sign up

Login with SSO

Login to the community

Login with SSO