Configure and test Sophos Firewall email notifications

Working email notifications require two separate configurations in Sophos Firewall: the mail transport is set up under Administration > Notification settings. The events that are actually reported by email are selected under System services > Notification list.

The user quarantine digest also uses this mail transport, but its schedule, portal link, and user assignment are separate settings.

The visible authentication, SMTP, admin, and SMS texts under Administration > Messages are a third, separate layer. Configure the login disclaimer and messages on Sophos Firewall explains their content and tests; changing a message configures neither SMTP transport nor event selection.

The quick procedure:

Configure the mail server, port, authentication, encryption, sender and recipient under Administration > Notification settings.
Send a test email and confirm delivery in the destination mailbox or mail server tracking.
Enable the global Email notifications switch under System services > Notification list.
Select only events for which a responsible recipient can respond.
In addition to the test email, trigger a real selected event in a controlled manner and verify its delivery.

A successful test email only proves that the SMTP path works in principle. It does not prove that the global email switch and the correct events are enabled. Conversely, a selected event row does not send a message while the mail transport is not working. This distinction also explains why a configured SMTP server alone does not operationally satisfy the Notification Emails item in the Sophos Firewall Health Check.

If WebAdmin is unavailable or the recipient address needs to be corrected through controlled CLI access, open 2. System Configuration > 3. Set Email ID for system notification from the CLI Main Menu. System Configuration is option 2 of the Main Menu, not a submenu of the Device Console (option 4). If you are already in option 4, first return to the Main Menu, then select option 2. This option only changes the administrator email address for system alerts. It configures neither the mail server, sender, authentication, and TLS nor the global switch and events in the Notification list.

Record the previous address first. Confirm the change with y, enter the new address, and check the address displayed by SFOS for typing errors. Press Enter to return to the menu. A test email and a controlled real event must then reach the new recipient; the console confirmation alone does not prove delivery.

Prepare email delivery

Before configuration, confirm the mail server, port and authentication method with the responsible mail administrator. If an FQDN such as smtp.example.net is used, the firewall must be able to resolve it and reach the server through the intended routing path. A general internet connection is only required if the selected mail server or OAuth provider is on the internet. An internal SMTP relay can also work without direct internet access from the firewall.

Before making a change, record the selected mail server option, mail server, port, Authentication, Connection security, sender, recipient, management interface, and selected events. If certificate settings are part of the change, also record the current selection under Administration > Notification settings or Email > General settings, as applicable. Make sure the required credentials and OAuth tokens are available in a secure password or secrets manager; don’t put them in unprotected screenshots. This information is needed to restore the previous configuration if the new mail route fails its delivery test.

A realistic example:

Mail server: smtp.example.net
Port: 587
Authentication: Basic
Connection security: STARTTLS
Sender: fw-zrh-01@example.net
Recipient: firewall-alerts@example.net
Management interface IP address: the firewall’s internal management interface

Replace all values using example.net with the organisation’s domain and addresses approved by the mail administrator. A distribution address is usually better than a personal mailbox: responsibilities can change without reconfiguring every firewall.

The Management interface IP address does not control which interface the firewall uses for the SMTP connection. The selected IP address is included in the notification and helps identify the sending firewall. For multiple sites, choose an enduring and understandable management IP; with only one firewall, None may also be sufficient.

Physical, bridge and LAG interfaces appear in the dropdown only if they have an assigned IP address. If an interface is missing, this requirement explains its absence; do not assign IP addresses or change interfaces or routing merely to add identification to a message.

Configure the mail server

Choose Built-in or External email server

Sophos Firewall can use the Built-in email server or an External email server. Built-in delivery is practical for a simple start. In production environments, a dedicated relay or cloud mail server is often easier to trace because authentication, mail tracking, sender permissions and delivery errors are visible in one central location.

We therefore recommend the External email server when a reliably operated SMTP service is already available.

For the Built-in email server, this short branch is sufficient:

Enable the Built-in email server under Administration > Notification settings.
Enter the sender, recipient and optionally the Management interface IP address.
Save and send the test email.

The Built-in email server has no separate relay tracking where an administrator can trace acceptance and forwarding. Delivery must therefore be checked particularly carefully. If it fails repeatedly or the recipient domain and security requirements demand a controlled SMTP path, an External email server is the more manageable option.

Configure an External email server

Open Administration > Notification settings.
Select External email server.
Enter the mail server’s IPv4 address or FQDN and the specified port.
Under Authentication, select None, Basic or OAuth 2.0 to match the server.
Under Connection security, select the transport encryption required by the mail server.
Enter the sender, recipient and optionally the Management interface IP address.
Save and run the test email function.

The default port in SFOS is 25, but it is not a recommendation for every environment. The listener on the organisation’s relay is authoritative. Common choices are 25 for an internal relay authorised by source IP, 587 for authenticated submission with STARTTLS, or 465 for direct SSL/TLS. Port, authentication and encryption mode must match the mail server as a combination.

None does not mean the same thing in both selection fields: under Authentication, it disables authentication to the mail server. This can be correct for an internal relay that exclusively authorises the firewall’s source IP. Under Connection security, however, None means unencrypted SMTP transmission. This setting is unsuitable for internet paths and should only be used internally when the security model explicitly permits it.

With Basic, the firewall uses a username and password. The username is case-sensitive. The relay must support the authentication method used; an Authentication method error points in particular to a mismatch involving LOGIN or PLAIN.

STARTTLS is easily misunderstood: the firewall follows the mail server’s capability. If the server offers STARTTLS, the connection is encrypted; if it does not, the message may be transmitted without encryption. When encryption must be enforced, use SSL/TLS with the matching port and server listener.

⚠️ Allow invalid certificate under Email > General settings should not be enabled as a quick workaround. An expired or untrusted certificate, or one that does not match the server name, should be corrected on the mail server or in the trust chain.

The certificate SFOS uses also depends on the email mode. With STARTTLS in MTA Mode, the firewall uses the certificate under Email > General settings. In Legacy Mode, you can select a certificate for STARTTLS directly under Administration > Notification settings; if you don’t select one, SFOS also uses the certificate under Email > General settings. With SSL/TLS, it uses the certificate under Email > General settings. Therefore, don’t change a certificate in isolation without considering the production mail flow.

Gmail and Microsoft 365 with OAuth 2.0

For Gmail and Microsoft 365 in SFOS 22 and 23, select OAuth 2.0. The provider, Client ID, Client secret and Refresh token are entered in Notification settings. The Client secret field is optional for Microsoft 365; however, the Microsoft 365 procedure described here explicitly creates and uses a secret. It is therefore configured for this procedure.

For Gmail, a project and the Gmail API must be set up in Google Cloud, and an OAuth client and Refresh Token must be generated. The following procedure describes these steps. Google and Microsoft change their portals and requirements independently of SFOS; before configuring a production system, check the providers’ current requirements and the permissions of the intended sending account.

Configure Gmail OAuth 2.0 step by step

Before generating the Refresh Token, check the intended sending account, the OAuth client, the Redirect URI and the broad Gmail scope described below. For the following procedure with User type: External, approval to run the OAuth app in production must also be established. Publish App replaces neither required provider verification nor approval from the responsible Google Workspace or security administrator. If publication is not permitted under Google’s current requirements or your own policies, do not bypass those safeguards: use an approved SMTP relay for a lasting alert path instead.

Sign in to Google Cloud Console with the intended Google account, create a new project, and select it.
Open APIs & Services > Library, search for Gmail API, and enable the API.
Under APIs & Services > Credentials, click Create credentials > OAuth client ID.
If the consent screen is required first, open Configure the OAuth consent screen > Get started. Enter the app name and email address, select User type: External, add the developer contact address, and create the configuration.
Select Create OAuth client, set Application type: Web application, and enter a unique name.
Under Authorized redirect URIs, add exactly https://developers.google.com/oauthplayground.
Create the OAuth client and immediately record the Client ID and Client secret securely.
Under Audience, check the intended sending account and the current publication status. While the app is set to Testing, add the account as a test user under Add users. This test user list is not an access restriction for an external app once it is published.
After obtaining the required approval, run Publish App and check that Publishing status has changed from Testing to In production. An external app is then generally open to authorization by Google accounts outside the test user list; applicable account and organisation policies still need to be observed. Only then generate the Refresh Token. A token generated before publication expires after seven days in this Gmail procedure; for ongoing operation, therefore, generate a new Refresh Token after publication rather than continuing to use the previous one.
Open Google OAuth 2.0 Playground. Use the gear icon to enable Use your own OAuth credentials, then enter the Client ID and Client secret.
Under Step 1 Select & authorize APIs, expand Gmail API v1, select the scope https://mail.google.com, and start Authorize APIs. Use the intended sending account and, before granting consent, compare the displayed app and its permissions with the approved configuration. If anything differs, stop and check the configuration.
Under Step 2 Exchange authorization code for tokens, exchange the code for tokens and securely copy the Refresh token. Client secret, Authorization Code, Access token and Refresh token do not belong in tickets, unprotected screenshots or logs.
On the firewall, under Administration > Notification settings, configure the External email server with Authentication: OAuth 2.0 and Provider: Gmail. Enter the Client ID, Client secret and Refresh token, save, and send a test email. Confirm actual delivery in the destination mailbox or mail server tracking; saved OAuth fields alone do not prove that the mail path works.

Google does not treat an OAuth project with User type External and Publishing status Testing as a permanent production configuration: when the Gmail scope is used, the Refresh Token expires after seven days according to Google OAuth 2.0. The Gmail scope https://mail.google.com used here allows reading, creating and permanently deleting emails in addition to sending them. The OAuth app, credentials and preferably dedicated sending account must therefore be protected and operated just like a mail server password.

For Microsoft 365, the app requires the delegated permissions SMTP.Send and offline_access; Authenticated SMTP must be enabled for the sending account. The documented standard method uses smtp.office365.com, port 587 and STARTTLS. If the sender address differs from the authenticated mailbox, the account also requires Send As. The complete Entra procedure follows directly below.

Configure Microsoft 365 OAuth 2.0 step by step

In Microsoft Entra admin center, create a New registration under Identity > Applications > App registrations.
Enter a unique name. For this procedure, select Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant). Under Redirect URI, select the Web platform and enter https://outlook.office365.com/ as the URI. Alternatively, use http://localhost/. The registered URI must be reused exactly in the authorization request and token exchange; if you use localhost, adjust the redirect_uri in both examples below accordingly.
Register the app and securely record the Application (client) ID.
Under API permissions > Add a permission, configure the delegated SMTP permission for the Outlook/Exchange resource and grant the required consent. Microsoft documents the scope https://outlook.office.com/SMTP.Send for this purpose; offline_access is also requested for the Refresh token. The SMTP permission is essential, not a Graph permission such as Mail.Send. Check the resource selection and displayed permissions against Microsoft’s guidance on SMTP with OAuth before creating the token. If the appropriate permission is missing, do not proceed with one that merely appears similar.
In Microsoft 365 admin center, check Authenticated SMTP for the sending account under Users > Active users > Mail > Email apps > Manage email apps and, if security policies permit, enable it and save. This mailbox switch is separate from the app registration in Entra admin center.
Under Certificates & secrets > Client secrets > New client secret, create a secret with a monitored expiry date. Securely copy the displayed Value immediately; Entra no longer shows it after the page reloads.
Open the following URL in a browser. Replace YOUR_CLIENT_ID with the Application ID and YOUR_RANDOM_STATE with a random value generated only for this operation; the redirect_uri must match the app registration. URL-encode parameter values correctly. The state value must be returned unchanged in the response; a fixed example value does not protect the operation. Microsoft’s guidance on the authorization code flow explains state verification and PKCE for suitable clients.

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=YOUR_CLIENT_ID&response_type=code&redirect_uri=https://outlook.office365.com/&response_mode=query&scope=https://outlook.office365.com/.default+offline_access&state=YOUR_RANDOM_STATE

Sign in with the intended sending account, compare the returned state value with the stored value, and only use the short-lived authorization code from the redirected URL if they match. If they differ, stop and restart the procedure.
Use an API client to send the code as application/x-www-form-urlencoded to the token endpoint. Replace every placeholder with the values for this app. The following block shows the fields on multiple lines for readability; enter them as individual form fields in the API client so that spaces and special characters in the code, secret and Redirect URI are encoded correctly. This is not a shell command that can be copied and run unchanged.

POST https://login.microsoftonline.com/common/oauth2/v2.0/token

client_id=YOUR_CLIENT_ID
&scope=https://outlook.office365.com/.default offline_access
&code=YOUR_AUTHORIZATION_CODE
&redirect_uri=https://outlook.office365.com/
&grant_type=authorization_code
&client_secret=YOUR_CLIENT_SECRET

Store the returned Refresh token securely straight away. The authorization code, Client secret, Access token, and Refresh token do not belong in tickets, unprotected screenshots, or logs.
On the firewall, configure the External email server under Administration > Notification settings with Authentication: OAuth 2.0 and Provider: Microsoft 365. Enter smtp.office365.com, port 587, STARTTLS, Client ID, Client secret, and Refresh token, save, and send a test email.

For this token-generation procedure, the system running the API client and the firewall must use the same time zone. Check the system time and time zone before the procedure. Do not change the firewall time zone spontaneously in production; the required restart afterward must take place in a maintenance window.

Microsoft Security Defaults disable SMTP AUTH. This protection should not be disabled across the entire tenant simply to allow a firewall to send messages. If the targeted exception for the sending account does not fit the security model, a purpose-built internal or external relay is the cleaner approach.

⚠️ The known issue NC-166854 affects Microsoft 365 OAuth for notifications on SFOS builds 22.0.0.274, 22.0.0.323, 21.0.2.349 and 21.5.1.261. This does not establish either that every other build works or that no fix has since become available. Before putting this mail path into service, check the exact SFOS build and its applicable issue/fix status, and require a successful test email. Saved Client ID, secret and token fields are not proof that the function works.

If a listed build is affected, use a supported SMTP relay or another verified mail path until a corrected firmware version is reliably confirmed. Unsafe TLS exceptions or unverified Basic Authentication are not good substitutes for a working alert path.

Select events in the Notification list

After a successful mail test, open System services > Notification list. First enable Email notifications, then select the checkboxes in the Email column for the required events and save with Save.

Email and SNMP are separate output channels. For traps, the SNMP agent and the appropriate communities or users must also be configured under Administration > SNMP. Then enable the global SNMP traps switch and the available SNMP event checkboxes in the Notification list, and save. Selecting email does not enable traps; for each event, you can select email, SNMP or both available channels. The SNMP article linked below explains how to configure and test the SNMP manager.

Not every firewall needs the same selection. A useful baseline is based on the risks and the functions actually in use:

Admin: failed logins and too many failed login attempts.
HA: disconnected monitored ports or interfaces when an HA cluster is operated.
Disk/Memory: storage warnings so that a full reporting or system area is not only noticed during a maintenance window. The thresholds and consequences are explained in Check storage and reports on Sophos Firewall.
Firmware: new firmware ready for installation, successfully installed firmware and failed installations in line with the organisation’s update process.
SFOS 23 only – Firmware > Security updates: Under System services > Notification list, enable the Email column for Security updates. The global Email notifications switch and a working SMTP path are still prerequisites. SNMP notifications are not available for hotfix security updates; this restriction does not apply indiscriminately to all hotfixes or firmware events. Immediate delivery is not guaranteed, and missing email proves neither success nor failure. Check applied updates using the SFOS 23 hotfix verification procedure.
System: failed WebCat database, IPS signature and antivirus definition updates, system startup or restart, high CPU usage and Gateway status.
IPS: the levels Critical, Major, Moderate, Minor and Warning can be selected. The alert requires the firewall to log the IPS event and drop the packet. Critical events with a defined triage process are a suitable starting point.
Active threat response: log and drop events for MDR, NDR Essentials, Sophos X-Ops and third-party threat feeds are selected separately. Match types and restrictions are covered in the next section.
RED: connection failure, firmware update failure, automatic device deauthorisation or a new Unlock Code. AP: access point offline or firmware update failure. Select only notifications for devices actually in use and assign a responsible recipient.
VPN: IPsec tunnel up, down and failover/failback, and established or disconnected SSL VPN connections. The IPsec trigger conditions explained below are narrower than this general list; selecting these events does not promise a notification for every manual tunnel change.
Virus: select alerts for HTTP, FTP, SMTP, POP3 and IMAP4 according to the protection functions actually in use. The checkbox replaces neither the corresponding inspection nor its event detection.
Web - Instant alerts: deliberately selected web categories. These notifications are sent in fixed five-minute batches that cannot be changed and require separate category activation, as described under Web categories and Instant Alerts.

Enabling all events indiscriminately quickly causes alert fatigue. VPN notifications in particular may be repeated approximately every 60 seconds until the cause is resolved; with multiple local and remote networks, a notification may also be generated for each subnet pair. A small selection with a clear response is better: Who receives the alert, how urgent is it, and what is the first check?

The firewall sends some Default Notifications automatically and does not allow them to be deselected: HA role changes from Standalone, Primary or Auxiliary, HA device status faulty, virtual hosts up/down, and a restart or shutdown through WebAdmin. The configured mail path must also be reachable for these notifications. An event category that cannot be deselected does not guarantee that a message will reach an unreachable mailbox.

Active threat response: distinguish matches and channels

Each of the following match types has a Log event and a Drop event:

Destination match for all traffic: the destination address matches a threat feed entry.
Remote source match for inbound traffic: the remote source address of inbound traffic matches an entry.
Local source match for outbound traffic: the local source address of outbound traffic matches an entry.

A log alert alone does not prove that traffic was blocked. Conversely, a drop event depends on an actual match and the corresponding Active threat response configuration; the email checkbox creates neither a match nor a new protection rule.

The Sophos notification help lists local and remote source matching as unsupported for Sophos X-Ops. However, this conflicts with the SVG traffic matrix as explained in the NDR/ATR article, particularly for local source matching. The email option therefore proves neither a specific X-Ops matching effect nor that this conflict has been resolved; clarify disputed cases separately before relying on them for protection. Remote source match alerts are not forwarded to the central Sophos service, but their logs are visible in Central Firewall Reporting (CFR). The central service’s name varies between versions (Sophos Central or Sophos Fusion); this does not extend alert forwarding. For these events, therefore, check the local email/log path rather than relying solely on a central alert display.

Understand trigger conditions and repetition

An enabled checkbox does not mean that every brief state change generates an email. In SFOS 22.0 and 23.0, the following events have these conditions:

Admin: Sign-in failed includes incorrect credentials or an incorrect OTP (one-time password). Too many failed sign-in attempts is triggered when the number of unsuccessful attempts configured under Administration > Admin and user settings > Login security is reached. This threshold explains the alert; it is not an instruction to cause an account lockout.
High CPU usage: The first notification log is generated only when CPU usage reaches 95% and stays at or above 95% continuously for at least 25 minutes. Further entries are generated every 25 minutes until usage falls below 95%. A brief CPU spike without an event email therefore does not demonstrate an SMTP failure.
Gateway status: The event selection is enabled by default. Sending still requires the separate global Email notifications switch to be enabled.

For disk events, usage must remain at or above the respective threshold continuously for at least 50 seconds. Logs and notifications are then repeated at the following default frequency until usage falls below the threshold:

Area	Notification threshold	Repetition
Configuration storage	≥80%	every 50 seconds
Signature storage	≥90%	every 50 seconds
`/var`	≥80%	every 12 hours

For /var, the lower threshold already generates logs; notifications start only at the higher threshold of 80%. If usage exceeds the higher threshold and then falls below the lower one, recovery is logged but no recovery notification is sent. This differs from the report warning and stop behaviour in the storage article linked above; a missing recovery email is not a delivery failure here.

For IPsec, the documented scope is narrower than any VPN up/down change: notifications apply only to host-to-host and site-to-site tunnels with the described disconnection conditions:

Dead peer detection (DPD).
Failure to re-establish the connection after DPD.
The IPsec Security Association (SA) has expired and must be re-established.
This list also includes the tunnel coming back up after losing connectivity without administrator intervention.

If a description is configured in the IPsec connection settings, the notification includes it. This does not promise notifications for every manual disconnection or for remote-access or SSL VPN tunnels.

The CPU timings describe notification-log generation, and the disk intervals describe documented repetition—not a guaranteed arrival time in the mailbox. If email is missing, first compare the event condition, log timestamp and mail server tracking. Do not deliberately cause CPU or disk saturation, login lockouts, HA interruptions or production VPN failures solely to test an alert.

Verify a test email and a real event

The verification consists of two stages.

1. Confirm SMTP delivery with a test email

First check the mail configuration saved under Administration > Notification settings and run the test email function available in the SFOS build in use. The report test path is Reports > Show report settings > Report scheduling: select a report, open Send test mail, enter the test recipient address and click Send. This report test checks the mail transport, not event selection; its recipient is not automatically the saved recipient for system alerts. The firewall’s success message is not sufficient: the destination mailbox, spam filter or mail server tracking must show that the message was actually accepted and delivered. Report content and scheduling are checked separately, as described in the report article linked below.

Check the following:

Sender and recipient are correct.
The expected firewall can be identified from the subject, content or management IP.
The message does not permanently land in spam or quarantine.
The distribution list accepts messages from the configured sender.

2. Test the complete event chain

Then trigger a selected event in a controlled manner. Suitable examples include:

one failed login with a test account after reviewing login lockouts and thresholds;
a documented VPN event on a designated test tunnel, but only if the tunnel type and trigger condition match the selected notification; a manual IPsec up/down change alone is not a reliable alert test;
Gateway status during a planned WAN failover test.

Restarting or disconnecting a production gateway, an HA port or the firewall itself solely for an email test would be disproportionate. A maintenance or failover scenario that is already planned is the better test.

The complete chain is only confirmed when the event reaches the correct recipient within the expected time: event detection, event selection, global email switch, SMTP transport and delivery.

Troubleshoot systematically

The test email already fails

The SFOS 22 API distinguishes several error classes:

Failed to connect or SMTP server failed to respond: check FQDN resolution, route, port, upstream firewall and the mail server listener.
Password mismatch: check the username, case, password and whether the account is locked.
Authentication method mismatch: check whether the relay and SFOS both support LOGIN or PLAIN for Basic Authentication.
STARTTLS not supported: port and Connection security do not match the server listener.
Mail server refused to communicate: check relay permission, sender address, permitted source IP and the mail server logs.
Couldn’t generate the OAuth 2.0 access token: check provider, Client ID, secret, Refresh Token, permissions and system time.

DNS and STARTTLS can be pre-checked without changing the mail server from an administration system using a comparable network path:

nslookup smtp.example.net
openssl s_client -starttls smtp -connect smtp.example.net:587 -servername smtp.example.net

Replace smtp.example.net and 587 with the organisation’s server and port. nslookup only confirms name resolution from the administration system. openssl s_client shows SMTP reachability, TLS handshake and certificate chain, but does not test the route from the firewall’s perspective, its authentication or subsequent delivery.

In Log Viewer, and for a deeper analysis in cschelper.log, the test time can be correlated with the system-generated email. Access to service logs and the distinction from the Advanced Shell are explained under Sophos Firewall Services and Logs. MTA logs such as smtpd_main.log primarily belong to Mail Protection and are not generally the notification log.

The test email arrives, but event emails do not

The transport is then working, and the investigation starts under System services > Notification list:

Is Email notifications enabled globally?
Is the specific event selected in the Email column?
Did the expected event actually occur, and does it belong to the correct category?
Is there a known delay or batching, for example for Web Instant Alerts?
Does the spam filter, quarantine or mail server tracking show acceptance or rejection?

For an individual specialised event, also check its functional condition. An IPS alert, for example, is not generated merely by enabling a checkbox. A corresponding IPS rule must first log the event and drop the packet. A VPN notification depends on the tunnel type and the actual up/down state.

Gmail OAuth fails after a password change

In the Gmail notification procedure described here, with the scope https://mail.google.com, the Refresh Token becomes invalid when the password of the Gmail sending account in use is changed. The firewall can then no longer obtain a new Access Token using that token. This is not a statement about all Google OAuth tokens or about Microsoft 365.

Check whether the password of this specific sending account was changed. Compare the OAuth client, account, approved permissions and Publishing status: In production with the documented configuration. A token generated before Publish App is also not a lasting basis after seven days; investigate these two causes separately.
Using the current account login and your own OAuth client credentials, repeat the Gmail authorization and token exchange in the Playground procedure described above. Check the app and requested permissions before granting consent, and store the new Refresh Token securely.
Under Administration > Notification settings, with Provider: Gmail, replace the invalid Refresh token with the new one and save. Client ID and Client secret must match the OAuth client used; do not change SMTP, TLS, sender, recipient or event settings without a reason.
Send a test email and confirm its actual delivery in the destination mailbox or mail server tracking. Then check a controlled selected event as described in the section on the complete event chain.

Entering the old token again does not make it valid. Do not reset the account password merely to restore the previous mail path. If delivery still fails after reauthorization, record the exact error message, SFOS build and provider configuration, without secrets or tokens, for further analysis. Until recovery is confirmed, use an approved alternative alert path or the documented SMTP relay.

Microsoft 365 OAuth saves but does not send

First compare the SFOS version and build with NC-166854. Then check Client ID, Client secret, Refresh token, SMTP.Send, offline_access, Authenticated SMTP for the sending account, and the correct system time.

If the test email continues to fail on a build that is not listed as affected, this is not automatically the same issue. The exact message, SFOS build and provider sign-in logs should then be included in further analysis or a support ticket.

Operate notifications

If delivery fails after a change, first restore the recorded mail configuration: mail server option, server, port, Authentication, Connection security, sender, recipient, and management interface, plus the previous certificate selection if you changed it. Leave the event selection unchanged unless it was part of the change. After saving, confirm the previous alert path again with a test email and a controlled selected event. Rollback is only complete when both messages have actually arrived.

Use a functional distribution list with a responsible owner for recipients.
Retest the test email and a real event after changes to the mail server, DNS, routing, certificate, credentials, OAuth app or firmware.
Test the complete alert path at least quarterly if central monitoring does not monitor it continuously.
Document the expiry and rotation of passwords, Client Secrets and tokens.
Regularly adapt the event selection to new functions and decommissioned services.
Define a first check and an escalation path for every important alert.

The daily Sophos Firewall admin checklist summarises which status, security, and admin signals should also be actively reviewed during ongoing operations.

Email is a good direct alert channel, but it does not replace central log retention or correlation. For a longer history and security analysis, use Send Sophos Firewall Syslog to a SIEM. For traditional status monitoring and traps, SNMP hardware monitoring is the appropriate complement.

Daily or weekly PDF analyses don’t use the Notification list, but a separate report schedule. Schedule Sophos Firewall reports and send them by email explains report selection, bookmarks, transport testing, and content review.

Change the recipient address via CLI Main Menu > 2. System Configuration