Skip to content
Avanet

Configure and test Sophos Firewall email notifications

Sophos Firewall

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 quick procedure:

  1. Configure the mail server, port, authentication, encryption, sender and recipient under Administration > Notification settings.
  2. Send a test email and confirm delivery in the destination mailbox or mail server tracking.
  3. Enable the global Email notifications switch under System services > Notification list.
  4. Select only events for which a responsible recipient can respond.
  5. 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.

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.

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.

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:

  1. Enable the Built-in email server under Administration > Notification settings.
  2. Enter the sender, recipient and optionally the Management interface IP address.
  3. 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

  1. Open Administration > Notification settings.
  2. Select External email server.
  3. Enter the mail server’s IPv4 address or FQDN and the specified port.
  4. Under Authentication, select None, Basic or OAuth 2.0 to match the server.
  5. Under Connection security, select the transport encryption required by the mail server.
  6. Enter the sender, recipient and optionally the Management interface IP address.
  7. 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. According to Sophos, 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.

If the firewall uses Mail Protection in MTA mode, the certificate used for email delivery also depends on the configuration under Email > General settings. A change should therefore not be made in isolation without considering the production mail flow.

Gmail and Microsoft 365 with OAuth 2.0

For Gmail and Microsoft 365, the current SFOS 22 help requires OAuth 2.0. The provider, Client ID, Client secret and Refresh token are entered in Notification settings. Although the general Sophos help describes the Client secret as optional for Microsoft 365, the Microsoft 365 procedure documented by Sophos explicitly creates and uses one. 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 current steps are provided by Sophos under Configure OAuth 2.0 on Gmail.

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 by Sophos 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 current Entra steps are available under Configure OAuth 2.0 on Microsoft 365.

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 current Sophos Known Issues list still includes NC-166854: Microsoft 365 OAuth for notifications does not work on the listed builds 22.0.0.274, 22.0.0.323, 21.0.2.349 and 21.5.1.261. No fixed version is specified there. Check the exact SFOS build 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.

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 and, above all, failed installations in line with the organisation’s update process.
  • System: failed signature or database updates, system startup, high CPU usage and Gateway status.
  • IPS and Active threat response: initially critical or blocking events when a triage process exists.
  • RED, AP and VPN: only for devices and important connections that are actually in use.
  • Web - Instant alerts: deliberately selected web categories. These notifications are sent in five-minute batches 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. These include certain HA role and status changes, the status of virtual hosts, and a restart or shutdown through WebAdmin. The configured mail path must also be reachable for these notifications.

Verify a test email and a real event

The verification consists of two stages.

1. Confirm SMTP delivery with a test email

Send the test email under Administration > Notification settings. 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.

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;
  • the up/down state of a VPN test tunnel explicitly intended for this purpose;
  • 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:

  1. Is Email notifications enabled globally?
  2. Is the specific event selected in the Email column?
  3. Did the expected event actually occur, and does it belong to the correct category?
  4. Is there a known delay or batching, for example for Web Instant Alerts?
  5. 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 and drop the event. A VPN notification depends on the tunnel type and the actual up/down state.

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

  • 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.

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.