Fortinet FortiGate alert email (FortiOS email server) with Microsoft 365: email through Microsoft 365 after Basic auth is switched off

Short answer: FortiOS's email server settings have a user name and password but no OAuth option in the 7.4.0 and 7.6.4 CLI references. A FortiGate that logs in to smtp.office365.com with a mailbox password is using SMTP AUTH Basic auth, which stops working when Microsoft switches it off. Send to your MX host on port 25 with authentication off, behind a relay connector that trusts the FortiGate's public IP.

Deadline: Microsoft 365 turns off SMTP AUTH Basic auth by default at the end of December 2026 – dates and background.

Modern authentication (OAuth) support

Not documented. Fortinet's config system email-server reference (FortiOS 7.4.0 and 7.6.4) lists authenticate, username, password, security (none, starttls or smtps) and server/port, with no OAuth or token setting. Fortinet's own Microsoft 365 tech tip uses smtp.office365.com, port 587, STARTTLS and an app password for the mailbox, and doesn't mention OAuth. Fortinet does document Microsoft 365 OAuth for FortiMail, but that is a different product. An account that signs in over SMTP AUTH with a password is covered by the SMTP AUTH Basic auth switch-off. Check the release notes for your firmware before you rely on OAuth: it is not in the pages read.

What you will see when it breaks

Reported: alert emails and test mail from the FortiGate stop arriving after the tenant turns Basic auth off; diagnose log alertmail test returns an error (no official Fortinet wording found)
"535 5.7.3 Authentication unsuccessful" (Microsoft Learn: example SMTP response when an AUTH attempt is refused)
"5.7.57 Client not authenticated to send mail" (Microsoft Learn: SMTP AUTH refused; check the mailbox's Authenticated SMTP setting)
Reported: automation stitch and log-threshold emails go quiet at the same time (they use the same email server settings)

Best fix

Find out which mailbox the FortiGate signs in with: System → Settings → Email Service in the GUI, or show system email-server in the CLI. If server is smtp.office365.com and authenticate is enable, it is using SMTP AUTH. To list every mailbox in the tenant that still logs in this way, run the free SMTP AUTH sender script.
In Exchange admin center, create a relay connector (Mail flow → Connectors, from Your organization's email server) that trusts the static public IP the FortiGate's mail leaves from. The CLI has a source-ip option and an interface-select-method (auto, sdwan or specify), so confirm which address and interface the mail really uses.
Change the email server: config system email-server, set server contoso-com.mail.protection.outlook.com (your MX host), set port 25, set authenticate disable, then set security starttls or leave it none. Whether the MX host accepts STARTTLS from the FortiGate at your firmware level is not documented by Fortinet; Microsoft Learn describes the connector setup only.
Set the sender (the alert email's From address) to an address in a domain your tenant owns, or Microsoft 365 rejects the message (see 550 5.7.64 TenantAttribution).
Test with diagnose log alertmail test (from Fortinet's tech tip) and send a test from System → Settings → Email Service. If it fails, confirm the connector's IP, then check the message trace in Exchange admin center.

If it can't do OAuth

No static public IP for a connector? Put a small SMTP relay on your network that signs in to Microsoft 365 with OAuth itself, and point the FortiGate's server at it. Fortinet doesn't document a FortiOS-side OAuth option, so the relay has to do the OAuth step.
Without a connector, the MX host on port 25 is direct send, which only reaches mailboxes inside your organization (Microsoft Learn). Fine for alerts to a team mailbox, not for outside recipients. See 550 5.7.68 if direct send is blocked in your tenant.
An app password (Fortinet's tech tip uses one) is still a password sent over SMTP AUTH, so it doesn't survive the switch-off. Don't build a new setup on it.
Stopgap only: an admin can turn Basic auth for SMTP AUTH back on for now. See the SMTP AUTH change.

GUI path (Fortinet tech tip)	`System > Settings > Email Service`
CLI section	`config system email-server`
Options in 7.4.0 and 7.6.4	`type, server, port, security, authenticate, username, password, validate-server, ssl-min-proto-version, source-ip, source-ip6, interface, interface-select-method (7.6.4 also vrf-select)`
Defaults (CLI reference)	`authenticate disable, port 25, security none, validate-server disable (7.6.4 after a factory reset: port 465, security smtps)`
Microsoft 365 values in Fortinet's tip	`smtp.office365.com, port 587, STARTTLS, app password`
Relay connector values	`server: your MX host, port 25, authenticate disable`
OAuth / XOAUTH2	`Not documented (no OAuth option in the email-server reference)`
Alert email CLI	`config alertemail setting (username, mailto1, mailto2, filter, IPS-logs)`
Test command	`diagnose log alertmail test`

Check your domain's SPF and DMARC

A relay sends from your office IP, so it must be in your SPF record.

Several devices to move? The Microsoft 365 SMTP Fix Kit puts every printer, scanner, app and script on one printable guide: decision table, relay connector set-up, per-device steps, a sender worksheet and a checklist.

Get the kit ($19)

Rather have it done for you? I move your devices and apps on Fiverr – relay, Direct Send or OAuth, tested, from $25.

MSP or IT partner? The M365 Readiness Pack checks SMTP AUTH, EWS and SPF/DKIM/DMARC per client tenant and writes a report with your logo (from $49).

Sources

Did this fix it?