Sophos Email: Securely manage inbound allow/block exceptions

Inbound Allow/Block controls which senders Sophos Email allows or blocks for inbound messages. The admin list applies globally to all protected mailboxes; personal user lists apply to the respective user. If the lists conflict, the Admin list takes precedence.

Safe fast path: Under Global Settings > Protection and Remediation > Allow and Block > Email > Inbound Allow/Block, first export the existing list. Then add the narrowest possible sender value to the Admin list, enable Enforce Message Authentication for an allow entry, document the reason and owner, and verify it with matching and non-matching test messages. Broad domains, wildcards, and networks are no substitute for investigating a false positive.

Important: An allow entry does not disable protection completely. For a matching, sufficiently authenticated sender, Sophos skips only the checks documented below; malware scanning remains active. Without enforcement, a forged message using an allowed sender address can bypass the documented scans and reach the inbox. The Time-of-Click URL allow list is a separate feature and is not managed here.

Understand scope and matching

The lists apply only to inbound messages. For addresses and domains, Sophos compares both the SMTP envelope sender and the address in the visible From header. If either address matches, the configured allow or block action is triggered. Therefore, inspect both values in the raw headers or message details before creating an exception.

The admin list supports:

individual email addresses such as billing@example.com;
domains such as example.com;
IP addresses such as the documentation address 192.0.2.25;
IPv4 networks with prefixes from /16 through /32, for example 192.0.2.0/24;
wildcards at the beginning, middle, or end of an address or domain, such as *.example.com, name*@example.com, name@example*.com, or *.example;
wildcards for entire top-level domains, with *.example used here as a safe documentation form instead of a production TLD.

The user list, by contrast, supports only email addresses and domains, not IP addresses or wildcards. The documented maximum across all lists is 100,000 entries. A maximum of 500 entries per user can be added to their allow or block list; entries added from Smart Banners can take a user’s list beyond this limit.

A message from a blocked sender or blocked client IP is discarded without further scanning. Messages from addresses on a block list are normally rejected during SMTP, before the mail server accepts them. With multiple recipients whose personal block settings differ, however, the message is accepted first and then blocked only for recipients who have blocked the sender. In this special case, SMTP acceptance does not mean delivery to the recipient who blocked the sender. The test below shows how to verify this.

Prepare and narrowly scope the change

Before every change, record:

the ticket, business reason, owner, and an expiry or review date;
the exact list type: Admin list or End user list;
the allow or block action and the narrowest possible value;
affected users for an end-user rule;
a current export as a backup and the number of entries;
test sender, test recipient, and expected matching and non-matching results.

Sophos does not provide a documented automatic expiry date for each entry. Expiry must therefore be an operational process: schedule exceptions in the change system, review them regularly, and remove them when the reason no longer applies. A description should briefly state the reason and ticket without confidential data.

Configure the admin list

In Sophos Fusion (formerly Sophos Central), click Global Settings.
Open Protection and Remediation > Allow and Block > Email > Inbound Allow/Block.
Select Admin list and click Add.
Select Allow or Block and enter exactly one address, domain, IP address, supported CIDR network, or required wildcard value.
Add a short Description containing the reason and ticket. The description can contain no more than 250 characters.
For allow entries, enable Enforce Message Authentication. Do not turn it off to bypass failed sender authentication.
Save the entry and then find it in the list. Advanced Search can filter by Allow/Block, Message Authentication, and sender address or domain.

If the same value already exists, use Override duplicates only after comparing the existing entry. Sophos then uses the most recent selection. You can edit the description of multiple selected admin entries together and can also enable Message Authentication for selected allow entries. A bulk change must not silently combine entries with different reasons or owners.

The per-entry controls under Enforce Message Authentication mirror the authentication options in User Settings. For each allow entry, you can preserve or override individual options, including SPF checks and envelope domains. Compare and document these values rather than recording only the main switch. Global spoofing protection does not replace the per-entry switch: if Enforce Message Authentication is off for an admin allow entry, that entry can be abused by forged senders even when the global option is on.

Checks skipped by an authenticated allow match

For an admin allow entry with enforced authentication, at least one of DMARC, SPF, or DKIM must pass. The enabled Prevention of spoofing of allowed address option and the per-entry settings determine the detailed evaluation; in particular, a DMARC failure with a policy other than p=none can cause authentication to fail. An arbitrary SPF pass is therefore not sufficient evidence on its own. For a successfully authenticated allow match, Sophos skips:

Header anomalies;
Impersonation protection;
Anti-spam;
BATV (Bounce Address Tag Validation);
Country of origin;
Language;
Data control.

A successfully authenticated user allow match skips only Impersonation protection, Anti-spam, Country of origin, and Language. The next section explains the conflicting descriptions of user authentication. Malware scanning remains active in both cases. The guide to malware, attachment, and URL protection explains which content and URL checks apply independently.

User allow: conflicting authentication descriptions

The current descriptions of Inbound Allow/Block and allow-list processing state that user allow entries always enforce Message Authentication. In contrast, User Settings describes Prevention of spoofing of allowed address as an option that must be enabled for the user allow authentication explained there. It says the option is off by default for existing customers and might not yet be available in every tenant. These descriptions are not unambiguously consistent. They establish neither a reliable authentication bypass when the option is off nor proven protection in every tenant regardless of that option. The authentication conflict remains unresolved.

In operation, keep existing protection controls enabled and, where Prevention of spoofing of allowed address is available, plan its activation with controlled validation of legitimate sending paths. If the option is missing or its effect is unclear, do not base a new user allow exception on assumed authentication behavior. Instead, clarify the tenant’s state using sanitized message details and the current settings. Do not disable Enforce Message Authentication, spoofing protection, or other checks as a workaround.

For the documented check with Prevention of spoofing of allowed address enabled, an allowed address may bypass checks only if authentication passes the following evaluation. If it fails, Sophos disregards the allow status and performs all scans:

A DMARC pass is sufficient. If DMARC fails with a sender policy other than p=none, allow authentication fails in this enabled test configuration.
With p=none, or if DMARC cannot be performed, SPF and DKIM determine the result.
SPF checks the message’s envelope domain.
DKIM must pass for the domain in the allow entry.
SPF check for non-aligned address can accept an SPF pass even when the envelope domain of the sender address does not align with the allowed address. Sophos does not recommend enabling it: a forged header-from address could then match an address allowed by the user, increasing spoofing risk.
SPF check for envelope domain makes Sophos read the envelope domain for every header address allowed by the user so that SPF is applied to the message’s envelope domain. Use it only when that documented exceptional non-aligned SPF workflow is required.

This non-aligned exception path broadens trust and is not a default solution. Correct SPF, DKIM, or DMARC at the legitimate sending service first. The relationships and result checks are described in the sender authentication guide.

Administer user lists

User Settings cannot be configured in EMS mode. Outside EMS mode, users can maintain their personal list in Sophos Central Self Service Portal if Release/Delete and Allow/Block List are enabled as appropriate under Global Settings > Products and Services > Email > User Settings. Two security-critical dependencies apply:

If End-user message settings is on and the Allow sender and Block sender links are configured on Smart Banners, Allow/Block List must remain on.
If End-user message settings is off and either Release/Delete or Allow/Block List is turned off, Sophos bypasses users’ existing allow/block lists.

Administrators can view and modify the same lists centrally:

Open Global Settings > Protection and Remediation > Allow and Block > Email > Inbound Allow/Block.
Select End user list and click Add.
Assign the entry to the correct user, select Allow or Block, and use only an email address or domain.
Save the entry and use Advanced Search to verify it by action, sender, or user.

Here too, Override duplicates replaces an existing identical value with the most recent selection. Always check the global admin list before making a change because it overrides a conflicting user entry. The quarantine self-service guide covers enabling user actions and quarantine permissions.

Test multiple recipients correctly

For a message to multiple recipients, personal lists can differ for the same sender. If only person1@example.com has blocked the sender, person2@example.com still receives the message; it is blocked only for person1@example.com. A normal block is rejected before SMTP acceptance. In the mixed multi-recipient case, the message is accepted first and then blocked per recipient. Successful SMTP acceptance therefore does not prove delivery to the recipient who blocked the sender.

For a controlled pilot, use two test mailboxes and a test sender that you own; replace the example addresses with these authorized values. First check the global Admin list for overriding entries and the user-list permissions described in the preceding section. The pilot requires effective user lists. In particular, when End-user message settings is off, turning off Release/Delete or Allow/Block List can bypass existing user lists; this is not a workaround for an unexpected test result.

Record the original personal entries. Add a block for the test sender only for the first test recipient; the second must have no corresponding block.
Send a new, harmless message to both recipients in one send operation. Check each recipient’s action separately in Message History and inspect the test mailboxes: expect blocking without delivery for the first and delivery for the second, unless another check stops the message.
If SMTP access is explicitly authorized, also retain the log of this send operation and distinguish acceptance from rejection. Verify that both recipients belong to the same SMTP transaction; separate transactions do not demonstrate this mixed case. Compare the result with a separate single-recipient test to the blocking test mailbox, for which normal rejection before acceptance is expected. Do not infer an SMTP reply code or processing stage from delivery status alone.
After the pilot, restore the previously recorded personal entries and verify them again. If the result is unexpected, stop the change and check admin precedence, user assignment, matching, and permissions rather than creating a broader allow rule.

An SMTP test with only one recipient does not cover the mixed case. Without authorized SMTP access, you can verify recipient outcomes but cannot document the SMTP stage as independently proven.

Export and import CSV files safely

Before a bulk import, export the selected entries or the entire affected list as CSV. This export provides a backup and a comparison baseline. It contains additional columns and is therefore not suitable unchanged as an import file. For an import, download the current Sophos Fusion template and follow its exact format and columns; remove the additional export columns. Do not invent assumed column names.

Open the correct Admin list or End user list tab.
Export the existing list and preserve the file unchanged as a backup.
Select Add > Import allow/block list and download the template files.
Create the CSV in the template format. Check action, value, Description, and, for user lists, user assignment row by row.
Before completing the import, spot-check Allow and Block entries, special characters, domains, and user assignments in the import preview.
Import a small pilot file first. Find and test the new entries before processing further files.

Warning: Selecting Replace existing list with this import and adding the CSV permanently removes every current entry in the affected import list. Use this option only for an approved full replacement with a verified backup and a successful pilot. Never select it when merely adding entries.

Safeguard and roll back a full replacement

Before a full replacement, a named approver must sign off on the exact list tab, the unchanged complete backup and its recorded row count, the prepared recovery file, the pilot result, and the maintenance window. The pilot must use the same current Sophos template in a non-production tenant or a separate controlled test list. Never run a partial pilot file against the production list with Replace existing list with this import.

If entries are missing or wrong after the full replacement, stop all further imports and do not patch the list row by row. After incident or change approval, convert the previously exported, known-good complete list into a new file that follows the current Sophos template; keep the original export unchanged. Before importing, compare the row count and representative Allow and Block entries, plus user assignments for user lists and samples from the beginning and end. Then, in the correct tab and a controlled window, import this complete recovery file with Replace existing list with this import. Finally, require the entry count to equal the pre-change count, confirm the same samples, and repeat matching, non-matching, and authentication tests to prove the known-good state is restored. If anything differs, keep the change stopped and escalate; malware scanning and all other protection controls remain active.

Observe these separate documented import limits:

no more than 500,000 entries in the import list being created;
no more than 500 entries per user;
no more than 1 MB per CSV file;
no more than 250 characters per Description; longer text is truncated during import.

Split larger files and upload them in stages. Spreadsheet software can change delimiters, leading characters, or character encoding. If accented characters are corrupted or columns shift, cancel the import, rebuild the file from the unchanged Sophos template, and check the preview. Do not guess the encoding or edit the backup directly.

Validate the result

After an individual change or each import, perform a small, documented test:

Matching: A new message with an exactly matching envelope sender or From header must show the expected allow or block effect.
Non-matching: A similar address or neighboring domain outside the entry must undergo normal checks. Especially for wildcards and CIDR, this reveals whether the scope is too broad.
Authentication passes: Check a legitimate sender with a documented authentication result against the global and per-entry options actually enabled. Keep Enforce Message Authentication enabled for admin allow entries; for a controlled user allow test, use the available and enabled Prevention of spoofing of allowed address option. Only the documented checks for each case may be skipped; malware scanning remains active. A single SPF pass does not prove a successful allow match under stricter DMARC evaluation.
Authentication fails: In this protected test configuration, a controlled message for which all three checks fail must not benefit from allow status and must undergo all scans. Also check a DMARC failure with a policy other than p=none if that case is part of the authorized test. Without a verifiable user allow test configuration, its validation remains open; do not turn off a protection control to force delivery.
Block and multiple recipients: For personal block lists, test one affected and one unaffected pilot recipient in the same message and document both actions separately. Verify SMTP acceptance or rejection separately only with authorized access, not from delivery alone.
CSV: Compare count, action, value, Description, and user assignment with the source file and backup. Also spot-check the beginning and end of the list.

In Message History, record the time, envelope sender, visible From, client IP, recipient, authentication results, and action. Delivery alone does not prove that the allow entry matched; the message might have passed the normal scan path.

Troubleshoot and maintain exceptions

Allow does not take effect: Compare the envelope sender and From with the entry, then check admin precedence, per-entry options, and DMARC/SPF/DKIM. Normal scanning is intentional when enforced authentication fails. If user allow behavior is unclear, also record the actual spoofing-protection state; do not work around the documented source conflict by disabling protection controls.
Block affects only some recipients: Check user assignments and the documented multi-recipient case. A conflicting admin rule takes precedence.
Wildcard or CIDR matches incorrectly: Check syntax and prefix. Only /16 through /32 is documented; user lists support neither IP/CIDR nor wildcards. Remove the broad entry until the issue is resolved.
Import is missing or incorrect: Check the list tab, file size, per-user limit, template format, additional export columns, truncated descriptions, and visible character encoding. Do not retry with Replace existing list with this import until the cause is known and the backup is verified.
Legitimate mail remains blocked: First compare the global admin list, personal list, envelope/header address, and client IP. Then review authentication and Message History; do not create a second, broader allow entry as a shortcut.

At least quarterly and whenever an owner changes, compare the list, ticket, and business need. After approval, remove expired, ownerless, duplicate, or overly broad exceptions and repeat matching and non-matching tests. If the cause remains unclear, revert the new entry and escalate with the message ID, timestamp, list export, affected row, and authentication results—without disclosing confidential message content or complete production lists.