Set up and test the Sophos Firewall quarantine digest

The quarantine digest emails users a list of spam messages held by Sophos Firewall. It isn’t just another system notification: the delivery path, user assignment, release link, and user portal must all work together.

The most important acceptance criterion is therefore the complete user journey. A successful test email doesn’t confirm that a real user receives the digest, can sign in to the correct portal, and can release an eligible message.

⚠️ The release link doesn’t release a message directly. It opens the user portal, where the user must sign in and select the message. The selected portal address must therefore be reachable by the intended recipients without exposing the interface indiscriminately to other networks.

Set up the quarantine digest in seven steps

Configure mail delivery under Administration > Notification settings.
Define the portal address, DNS, certificate, and allowed source networks for the intended users.
Turn on the digest under Email > Quarantine settings and set the delivery time, sender, and display name.
Select the correct user portal address under Release link settings, verify it with Send test email, and save with Apply.
In MTA mode only: define the quarantine area and any address patterns that should deliberately be excluded.
Assign the digest to the intended accounts under Authentication > Groups or Authentication > Users.
Use a real quarantined spam test message to verify the digest, portal sign-in, and release end to end.

What the digest does and doesn’t do

The digest lists quarantined spam messages with their receipt time, sender, recipient, and subject. It provides a convenient user view, but it doesn’t replace the administrative quarantine under Email > SMTP quarantine or technical analysis of the policy, mail logs, and MTA logs.

The general digest settings are available in MTA mode and legacy mode. However, SFOS shows Quarantine area and Skip address patterns only in MTA mode. Legacy administrators therefore configure only delivery, the release link, and user assignment.

Only users who have authenticated with the firewall at least once receive a quarantine digest. This is easy to miss when accounts have been imported from Active Directory but have never signed in to the user portal, captive portal, or another applicable service.

According to the SFOS 22/23 help, the quarantine digest isn’t available on XGS 87 and XGS 87w. This model restriction applies to the digest and must not be confused with the separate MTA mode restriction. Set up Mail Protection in MTA mode explains the mail flow, SMTP policy, and administrative quarantine.

Prepare mail delivery and the portal address

Delivery uses the settings under Administration > Notification settings. The mail server, sender, recipient, DNS, route, authentication, and TLS must work there first. The complete transport test is described in Set up Sophos Firewall email notifications.

There are two options for the release link:

Reference user portal IP: SFOS uses the address of the selected interface together with the user portal port.
IP address or hostname: SFOS uses the address configured under Administration > Admin and user settings > Admin console and end-user interaction.

The SFOS 22/23 quarantine help uses a different name for this area: Administration > Admin settings. What matters is the field under Admin console and end-user interaction, not the menu name alone. Compare the deployed interface with the link in the received digest email; different labels don’t imply an additional release capability.

An FQDN is usually easier to understand and can be secured properly with a matching certificate. It must resolve to the correct firewall address and be reachable from the recipients’ networks. A private interface IP in the digest is normally unusable for external or mobile users. Conversely, a public address isn’t a reason to enable the user portal for every WAN network. Sophos Firewall portals overview explains portal purpose and Device Access separately.

Sophos warns against allowing access to the User Portal from the WAN zone. External users should therefore connect securely, for example through a VPN, first; the digest alone does not justify WAN access. For externally authenticated accounts, include the required first sign-in to the Captive Portal before initial User Portal use in the pilot test.

The user portal is a local service. Access to it is controlled under Administration > Device access, not by a standard firewall rule. Use Local service ACL exception rules to restrict access more tightly to specific hosts or networks. The web proxy also needs to be checked: SFOS treats HTTP and HTTPS requests sent through the firewall’s proxy as internal. The user portal may therefore remain accessible even if access from the source zone is disabled. Proxy use and proxy rules must consequently be included in the same access test.

Configure the digest

Turn on Enable quarantine digest under Email > Quarantine settings. Then set the required delivery frequency, time, and, where applicable, day of the week. From email address must contain a valid sender address; Display name should clearly identify the sender as the firewall quarantine.

Next, select the prepared portal address under Release link settings. Use Send test email to send a test message; once it arrives, save the settings with Apply. This message isn’t sufficient for user acceptance: only the complete path with an assigned pilot user confirms the schedule, assignment, portal sign-in, and release.

Pilot example with adaptable values

An adaptable pilot example is Email frequency: Daily at 10:00, From email address: firewall@example.com, and Display name: Firewall Quarantine. Daily and the field names are UI values; choose the time, sender, and display name for the local environment. 10:00 allows review during working hours but isn’t a product requirement. Replace the example domain with an authorized sender domain. In MTA mode, an example for Skip address patterns is adding sales@example.com with + when that shared alias should deliberately be omitted from the digest. Then check that its messages remain in SMTP quarantine but aren’t listed in the digest.

Read the XML schedule and user lists correctly

For XML automation, AntiSpamQuarantineDigestSettings separates global configuration in SpamDigestSettings from user assignments in SpamDigestUsers. EmailFrequency uses Hourly, Day, or Week; the UI example Daily corresponds to Day. The fields under SpamDigestSettings > SendEmailAt depend on this choice:

Hourly: according to the reference, Hour describes the interval in hours, not a daily delivery time.
Day: Hour and Minute specify the daily delivery time. The pilot example 10:00 corresponds to Hour = 10 and Minute = 0.
Week: Hour and Minute specify the delivery time, while repeated Days entries specify the selected weekdays.

The reference gives a range of 0–23 for Hour and 0–59 for Minute. Its repeated Hour/Minute rows marked as mandatory describe different frequency contexts: they do not mean that every variant must be entered simultaneously. The documented range alone also does not establish a verified meaning for an hourly interval of 0.

⚠️ The SFOS 22/23 XML references contradict themselves about Saturday on the same page: the example includes Saturday, but the list of allowed Days values omits it. This proves neither support nor a prohibition of Saturday. If a Saturday run is required, clarify support on the installed SFOS build with Sophos Support rather than copying the example value without verification or guessing a numeric substitute. Do not deploy a production Saturday schedule through XML until this is resolved.

Under SpamDigestUsers, EnableUsers contains repeated EnableUser entries to enable the digest, and DisableUsers contains repeated DisableUser entries to disable it for named user accounts. The values are usernames, not recipient address patterns; these lists are therefore not Skip address patterns. For the pilot, record existing assignments, avoid conflicting entries for the same account, and afterwards check the saved user and schedule settings as well as the actual digest run. The reference does not clarify every detail of overlapping or omitted lists; do not infer precedence or replacement rules from the example. This field mapping is not a complete XML request.

Quarantine area and automatic cleanup

In MTA mode, select the size of the local quarantine area under Quarantine area. SFOS checks usage every five minutes. When it reaches at least 90 percent of the selected size, older messages are deleted until usage falls to 60 percent.

This automatic cleanup isn’t an archive. An area that’s too small can shorten the time available for review and release; a large area consumes local storage. Total utilization under Email > SMTP quarantine shows current usage. Check Sophos Firewall storage and reports explains how to assess the firewall’s overall storage status.

10 GB is a possible configuration example, not a default or a guaranteed retention period. Choose the size based on mail volume, free storage, and the required review time, then observe usage during the pilot. Increasing the size later won’t restore messages already purged automatically or removed with Delete.

Skip address patterns in MTA mode

In MTA mode, under Skip address patterns, enter each recipient email address whose quarantined messages you want to exclude from the quarantine digest, then click the plus button + to add that address to the list. Addresses under Skip address patterns are excluded from the quarantine digest. This can be useful for shared aliases whose spam shouldn’t be distributed to many users. The setting doesn’t delete messages and isn’t an exception from spam, malware, or data protection checks.

Assign users and groups

The global digest configuration alone doesn’t enable delivery for every user. Set Quarantine digest to Enable for the intended accounts under Authentication > Groups or Authentication > Users, then save with Save. Alternatively, assign it directly under Email > Quarantine settings > Change user’s quarantine digest settings. An individual user setting takes precedence over the group setting, so check both levels if the result is unexpected.

For bulk assignment, open Email > Quarantine settings > Change user’s quarantine digest settings, filter by Group if required, and select the intended users. If an individual user’s email address needs correcting there, change it using Edit and save it with Save. Then complete the assignment with Apply. Afterwards, check the primary address and deliberately assigned aliases against the affected user account.

There are two important limitations for alias addresses. By default, SFOS doesn’t automatically apply digest settings to aliases; they must be stored with the user’s primary email address or assigned deliberately. The digest can then list spam for primary and alias addresses. However, Sophos states that quarantined messages sent to aliases don’t appear in the user portal. These addresses therefore need a clear administrative release process under Email > SMTP quarantine.

Manage messages in the User Portal

After following the digest link, the user signs in to the User Portal and opens Quarantine, which contains the SMTP quarantine. The link itself does not release anything. Only messages addressed to the user’s own primary email address are visible there, not messages sent to aliases or other mailboxes.

Narrow down the required message by date range, sender, and subject, using the available filters if needed.
For a single spam message, select Release on the message. For multiple messages, select the required rows, choose Release from the actions, and click Go.
For a confirmed false positive classified as Spam or Probable Spam, use Release and report to release it and report it to SophosLabs. An unwanted message can instead be deleted with Delete. Check the recipient and message before either action.

Users can release only quarantined spam. Virus-infected messages can neither be released nor downloaded. The firewall scans released messages again and then delivers them; alias messages and other quarantine reasons remain subject to the administrative review process described below.

Control user sender exceptions

Under Exception in the user portal, an authorized user can allow or block individual sender addresses or wildcards such as *@example.com. Allowed senders aren’t marked as spam or moved to spam quarantine, but antivirus scanning remains active. If the same address appears in both lists, the block list takes precedence and the message is quarantined. Include these user-specific exceptions in pilot and support tests, and don’t confuse them with the digest’s global Skip address patterns.

A single sender address is narrower than *@example.com. Before adding an exception, record the existing list entries and investigate the false positive. Afterwards, check a matching and a non-matching test message. To roll back, restore the recorded lists and verify the expected spam classification again; this does not recall messages already delivered.

Test the complete release path

Use a pilot user who has already authenticated with the firewall at least once. A controlled message must be quarantined as spam by the expected SMTP policy. Then verify the following states:

The message appears under Email > SMTP quarantine with the expected recipient, subject, and reason.
The pilot user receives the digest at the configured time.
Sender, display name, subject, and metadata meet the data-protection and operational requirements.
The release link opens the intended user portal FQDN with a valid certificate chain.
Sign-in succeeds from an allowed network and fails from a network that isn’t authorized. If an explicit web proxy is in use, repeat the negative test once without and once with the proxy.
The eligible test message can be released after sign-in and is actually delivered.
A user without digest assignment receives no report.

In the user portal, users see quarantined messages addressed to their primary email address, but they can release only spam. SFOS scans a released message again before delivering it. For alias addresses and other quarantine reasons, use the administrative path under Email > SMTP quarantine. There, filtered messages can be released or deleted; for Spam or Probable spam, Release and report can also be used to report a false positive to SophosLabs. Virus-infected messages and emails that Zero-Day Protection identifies as malicious can’t be released, even by an administrator.

Troubleshoot systematically

Filter the administrative quarantine precisely

For alias messages or administrative review, open Email > SMTP quarantine. Narrow the processing period with Start and end dates and enter suitable keywords under Sender/Recipient/Subject. Check the recipient, subject, and quarantine reason before applying Release, Release and report, or Delete to the filtered messages. An overly broad filter can unintentionally include other messages.

Filter by differs by mail mode:

MTA mode: Blocked by RBL, Spam, Analyzed by Zero-day protection, Infected, Unscannable content or protected attachment, DKIM verification, Other.
Legacy mode: Blocked source IP, Blocked destination IP, Unscannable content or protected attachment, Oversized message, Blocked header, Blocked by RBL, Blocked by data protection, Spam, Infected, Other.

A filter reason isn’t permission to release: virus-infected messages and messages identified as malicious by Zero-Day Protection remain non-releasable. Deleting messages quarantined through Zero-Day Protection analysis requires read-write permission for Zero-day protection activity in the administrator profile. If an action is missing, check the reason and profile first instead of disabling protection. After an eligible release, verify actual delivery; Delete isn’t a reversible test.

The test email doesn’t arrive

Check Administration > Notification settings first. Send test email fails before the actual quarantine function when DNS, route, mail server, authentication, TLS, sender, or recipient is incorrect. Don’t change user assignments or quarantine size while the mail transport itself is failing.

The test email arrives, but no user digest does

Check that Enable quarantine digest is on, the change was saved with Apply, the schedule and time zone are correct, and the affected account is enabled under Groups, Users, or Change user’s quarantine digest settings. A user setting can override the group selection. The user must have authenticated with the firewall at least once. There must also be a matching quarantined spam message for this recipient in the selected period.

The release link points to the wrong address

Compare Release link settings, the selected interface, the user portal port, and Admin console and end-user interaction. Then test DNS resolution, certificate name, and reachability from the real user network. Repeatedly sending the test email won’t correct the address; fix the underlying portal reference first.

Released messages remain in the mail spool

Release does not prove delivery. Correlate the message and timestamp under Email > Mail spool and Email > Mail logs. If a new rule above the intended SMTP rule already matches SMTP traffic, SFOS no longer evaluates the rule below it. Automatically created IPsec or hotspot rules and manual rules with Rule position: Top can cause this.

Before changing anything, record the rule order and affected connections. Under Rules and policies > Firewall rules, move only the new overlapping rule confirmed as the cause far enough down for the intended SMTP rule to be evaluated again; do not edit the automatic MTA rule. Then track a controlled message through to actual delivery, check the spool, and test other affected connections. Restore the recorded order if there are side effects. Without a confirmed SMTP match, do not move rules blindly; check the destination server, DNS, route, and TLS using the linked MTA runbook and escalate the findings to support if the failure persists.

Alias messages are missing from the portal

This isn’t automatically a digest failure. Sophos explicitly documents that quarantined messages sent to aliases don’t appear in the user portal. Check the primary address, alias assignment, digest contents, and administrative SMTP quarantine separately.

Operations and rollback

Digest emails contain communication metadata and may persist outside the firewall in mailboxes, archives, or tickets. Keep the recipient group small, align mailbox retention with the protection requirement, and include shared aliases in reports only deliberately.

Before rollback, document the global digest status, schedule, release link, user and group assignments, and shared portal and notification settings. For verification, send one controlled spam message to the pilot user and another to a control user whose digest remains enabled, then confirm both under Email > SMTP quarantine. Next, either turn off Enable quarantine digest or remove the pilot user’s assignment, saving each change with Apply (Email) / Save (Authentication).

After the next scheduled digest run, the pilot user must not receive a report. If only that user’s assignment was removed, the control user’s digest confirms that the run took place. Roll back portal or notification settings only if no other service uses them. The quarantine remains independent of the digest and isn’t deleted as part of the rollback.