Create and test Sophos Firewall email exceptions safely

An email exception on Sophos Firewall doesn’t simply allow a sender. It skips selected security checks for a defined SMTP path. This is precisely why it can resolve a confirmed false positive cleanly, but it can also silently disable SPF, malware scanning, Zero-Day Protection, or DKIM checks.

⚠️ Create an exception only after reproducing a false positive. Skip only the affected check. Choose the smallest reliable scope condition because source host, sender, and recipient are alternatives, not a combined AND condition. All checks and broad wildcards aren’t a quick standard workaround.

Create the exception in seven steps

1. Record the test time, SMTP source IP, envelope sender, recipient, subject, Message-ID, and the exact rejection reason.
2. Check whether DNS, routing, relay, TLS, or the actual mail policy causes the problem rather than a security check.
3. Under Email > Policies and exceptions > Add an exception, select only the check proven to be affected.
4. Enable only the narrowest suitable condition under Sources or hosts, Sender addresses, or Recipient addresses.
5. Test one equivalent message positively and at least one variation outside the scope negatively.
6. Under Email > Mail logs, compare the result and reason before and after the change; test other protection functions separately with harmless, controlled cases.
7. Document the owner, justification, and review date; remove the exception after correcting the cause.

What an exception actually skips

SFOS groups the checks that can be skipped by their effect. Spam protection contains RBL, Anti-spam, Greylisting, Recipient verification, IP reputation, RDNS/HELO, SPF, and BATV. Malware protection contains Malware and Zero-day protection. Other contains Data protection, File protection, Encryption, Banner addition, DKIM signing, and DKIM verification.

This selection isn’t a convenience list. An exception for SPF, for example, leaves the remaining anti-spam and malware path in place. An exception for Malware or Zero-day protection, however, removes a central content check for every message that matches the scope. Encryption, DKIM signing, or DKIM verification also change the confidentiality and integrity validation of the outgoing or incoming mail flow.

This exception belongs to MTA mode. An SMTP route and scan policy combines routing with spam, malware, file, and data protection actions. In legacy mode, SFOS acts as a transparent mail proxy and instead uses separate SMTP malware scan and SMTP spam scan policies; the MTA exception object isn’t the appropriate control there. The complete workflows are covered in Set up Sophos Firewall Mail Protection in MTA mode and Configure Mail Protection in legacy mode.

Encryption in this exception list refers to the MTA policy’s email encryption, such as SPX email encryption. It isn’t an exception for SMTP transport encryption. Require TLS negotiation, certificate validation, and Skip TLS negotiation are controlled separately under Email > General settings > SMTP TLS configuration. Therefore, an email exception doesn’t fix a TLS handshake, routing, relay, or firewall rules.

Understand matching before saving

The three scope groups don’t form an AND condition. The official SFOS 22.0 configuration API names them ForTheseSourceHost, ORTheseSenderAddresses, and ORTheseRecipientAddresses. When several groups are enabled, a source host or sender or recipient match is sufficient. Entering a source IP, partner domain, and pilot mailbox therefore doesn’t restrict the exception to that combination; it creates three ways to match.

SFOS doesn’t offer an AND relationship between these groups in this exception object. If an exception is acceptable only when both the source and an address match, don’t try to recreate it with two exceptions: that widens the scope as well. Correct the cause or separate the mail flow with an appropriate policy or gateway path instead.

Sources or hosts

SFOS accepts IP addresses, IP ranges, IP lists, networks, or FQDNs as sources. Wildcard FQDNs aren’t supported for email host exceptions. Therefore, *.example.net isn’t a valid replacement for the observed SMTP source address. An exception isn’t required for localhost because SFOS doesn’t scan local emails by default.

For cloud mail services or distributed gateways, one IP may be too narrow, while an entire provider network may be far too broad. Use only a published source object actually observed in the local mail flow. If other tenants share the provider IP addresses, even that object may be too broad. Don’t exempt a security check based solely on that provider network.

Sender and recipient

For Sender addresses and Recipient addresses, a single address such as sender@example.net or a domain wildcard such as *@example.net is allowed. A second scope group isn’t a narrower counter-anchor because it is joined with OR. A sender address is especially not independent proof of trust when exempting SPF or DKIM: the exception skips that very identity check. A recipient exception, in turn, applies to matching messages from all senders.

BATV has an unusual special rule: To skip the BATV check for a sender’s emails, enter the sender’s address under both Sender addresses and Recipient addresses. If either field is missing, the exception is incomplete for this BATV case.

Create a narrow exception

The example handles a confirmed SPF false positive from a partner with a dedicated mail gateway. 203.0.113.25 is a documentation address and must be replaced with the actual public source IP observed in Mail logs. This example is suitable only when the IP is assigned exclusively to the trusted gateway; the bypass would be too broad for a shared cloud relay.

1. Open Email > Policies and exceptions > Add an exception.
2. Enter a traceable name such as FP-SPF-partner-example-review-2026-09-30.
3. Select only SPF under the checks to skip.
4. Under Sources or hosts, enter the host 203.0.113.25.
5. Leave Sender addresses and Recipient addresses disabled or empty. They would widen the scope through additional OR matches.
6. Save the exception and don’t add more hosts or checks.

The name deliberately includes the cause and review date. However, it doesn’t replace documentation in the change or ticket. The name doesn’t technically enforce an expiry date; the owner must actually perform the review.

Run positive and negative tests

First, the partner resends the same controlled message. It must pass through the intended mail flow and must no longer fail for the confirmed SPF reason. Under Email > Mail logs, filter by time, sender, recipient, or subject and by result and reason. SPF, RBL, Malware, Zero-day protection, DKIM verification, and BATV have dedicated reason filters. smtpd_main.log and, for rejections, smtpd_reject.log support deeper correlation; Sophos Firewall services and logs explains the log mapping.

Then run a negative test over a controlled SMTP path that isn’t exempted. It must not bypass the documented check because of this exception. With a source-host-only exception, other senders and recipients using the exempted IP are not negative tests: they match the same OR branch. A harmless test file can additionally confirm that the normal Malware and File Protection path still reacts; don’t use real malware.

Successful delivery alone doesn’t prove the scope. The official Mail logs description documents scan reasons and delivery status, but not an unambiguous “matched exception” field or a list of all skipped checks. Evaluate the before-and-after reason, the exception configuration, and separate positive and negative cases together. Don’t present successful delivery as proof that every other protection function ran.

Identify risky exceptions

Just one broad domain wildcard or large source network can remove protection from a substantial part of the mail flow. Entering both doesn’t narrow the scope; it creates additional OR matches. Exceptions for Malware, Zero-Day Protection, Data protection, and File protection in particular require a documented risk decision and a very small, independently trustworthy scope. Don’t disable the entire group as a precaution when the scan error is still unknown.

The seemingly functional options are also security-relevant. Skipping Encryption can send confidential content without protection. Without DKIM signing, the planned outgoing signature is absent; without DKIM verification, an incoming identity assertion isn’t evaluated. A Banner exception can remove required text or labels. Coordinate such changes with the mail and compliance owner.

Narrow down errors by symptom

The message is still rejected

Assess the new log entry rather than the old test message. The actual source IP, envelope sender, recipient, and Reason must match the scope and selected check. A wildcard FQDN under Sources or hosts doesn’t work. If the message is rejected because of RBL, IP reputation, RDNS/HELO, or another check, an SPF-only exception doesn’t resolve that separate reason.

The exception matches too many messages

Compare the three scope groups individually with the actual mail flow. A common mistake is to assume that source IP, *@domain, and recipient must all match. In fact, every enabled OR group increases the match set. Reduce the exception to one reliable group with as few values as possible and repeat the negative test.

The email passes the check but isn’t delivered

An exception controls security checks, not MX, the internal route, relay, SMTP TLS, or the destination mail server. Mail logs and the spool show whether the message fails after scanning because of DNS, routing, policy, or delivery. For a TLS error, check the certificate, Require TLS negotiation, and the peer; Encryption in the exception and a wider scope don’t solve it.

The BATV exception doesn’t apply

Check whether the identical sender address appears under Sender addresses and Recipient addresses. Then compare the specific BATV Reason and the remaining scope fields again. A second, broader exception isn’t a substitute for the missing BATV field.

Operation and rollback

Every exception has an owner, a proven false-positive reason, and a review date. Compare changes with the audit trail; Track configuration changes on Sophos Firewall describes the appropriate evidence. The actual mail flow remains visible separately in Mail logs and the MTA files.

Before the change, record the name, selected checks, scope values, and previous Mail log reason. For a state-preserving rollback, delete the newly created exception; leave existing policies and other exceptions untouched. Then retest the original error condition and one permitted control message. If the vendor or DNS cause hasn’t been corrected, the rollback must not silently cause production mail loss; first plan a maintenance window or a different, narrower correction.

Checklist

• A reproducible false positive and the exact Reason are available.
• Source IP, envelope sender, recipient, and Message-ID are documented.
• Only the affected check is skipped.
• Prefer exactly one suitable scope group; additional groups widen the match through OR.
• Wildcard FQDNs aren’t used as host exceptions.
• A BATV exception contains the sender address in both address fields.
• Positive and negative tests plus before-and-after reasons confirm the intended effect.
• The remaining spam, malware, file, data, and DKIM checks stay active.
• Owner, justification, review date, and rollback are documented.

FAQ