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, and use the smallest reliable combination of source IP, sender, and recipient for the scope. 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. Define Sources or hosts, Sender addresses, and Recipient addresses as narrowly as possible.
5. Test one equivalent message positively and at least two variations outside the scope negatively.
6. Use Mail logs and the MTA logs to confirm that only the intended check was skipped and all remaining protection functions still apply.
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.

The general MTA path remains documented in Set up Sophos Firewall Mail Protection in MTA mode. For the transparent proxy, see Configure Mail Protection in legacy mode. In neither mode does an exception replace routing, relay, a firewall rule, or a suitable scan policy.

Understand the scope before saving

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, a single IP may be too narrow, while an entire provider network may be far too broad. Use only the published source object actually observed in the local mail flow. If the provider changes its networks, don’t blindly expand the exception to Any; compare it with the logs and vendor information again.

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 domain wildcard covers every sender or recipient in that domain and therefore needs a narrower counter-anchor, such as a confirmed source IP and a pilot recipient.

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. 203.0.113.25 is a documentation address and must be replaced with the actual public source IP observed in the SMTP log. partner.example and pilot@example.com are also sample values.

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. Under Sender addresses, enter *@partner.example, and under Recipient addresses, initially enter only pilot@example.com.
6. Save the exception and don’t extend it to additional recipients yet.

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 to the pilot mailbox. It must pass through the intended mail flow and must no longer fail for the confirmed SPF reason. Correlate Mail logs, smtpd_main.log, and, for rejections, smtpd_reject.log using the timestamp, sender, recipient, and Message-ID. Sophos Firewall services and logs explains the log mapping.

Then perform two negative tests. A message from the same sender using a different source IP and a message from the confirmed source IP to another recipient must not receive the same exception. In addition, a harmless test file remains subject to the normal malware and File Protection path. Don’t use real malware.

Successful delivery alone doesn’t prove the scope. The expected message must be delivered, variations outside the scope must continue to be scanned normally, and no second security check may be skipped unintentionally.

Identify risky exceptions

A broad domain wildcard combined with a large source network can remove protection for a substantial portion of the mail flow. Exceptions for Malware, Zero-Day Protection, Data protection, and File protection in particular require a documented risk decision and a very small pilot 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 levels individually with the actual mail flow. Often, *@domain without a narrow source IP or with too many recipients is the broad factor. Don’t correct the exception by skipping more checks; reduce it to the smallest confirmed combination and run the negative tests again.

The email passes the check but isn’t delivered

An exception controls security checks, not MX, the internal route, relay, 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. Don’t expand the exception if the error occurs after the security check.

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.

For rollback, remove the exception or restore the documented previous state. 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.
• Sources or hosts, Sender, and Recipient form the smallest meaningful scope.
• Wildcard FQDNs aren’t used as host exceptions.
• A BATV exception contains the sender address in both address fields.
• Positive and negative tests confirm match and non-match.
• The remaining spam, malware, file, data, and DKIM checks stay active.
• Owner, justification, review date, and rollback are documented.

FAQ