Sophos Email: configure sender authentication and Smart Banners

Sophos Email checks inbound messages with DMARC, SPF and DKIM, and can also detect header and domain anomalies. The checks alone don’t determine how a message is handled: the relevant Email Security policy defines failure types, their order and actions. Smart Banners make the result visible to recipients and can offer safe user actions.

Recommended quick path: Under My Products > Email Security > Policies, open the affected Email Security policy and configure the failure actions for DMARC, SPF and DKIM under Settings > Inbound > Authentication. Initially set critical failures to Quarantine rather than Reject, order conditions from top to bottom, then review Header anomaly, Domain anomaly and End-user message settings. Compare legitimate and failing test messages in Message History before allowing exceptions or enabling stricter actions.

Prepare the scope, test and way back

Before making changes, you need the protected domains and mailboxes, known legitimate sending services and a limited test group. Record:

the affected policy, its position and whether it is Enforced;
the Inbound direction and assigned users, groups and domains;
current DMARC, SPF, DKIM and sender-check rules in their current order;
existing allow entries and business-approved exceptions;
original actions, banner text and end-user options;
test senders, test recipients and expected results.

To revert, restore the recorded rule order, actions and banner options, or set a new pilot policy to Policy Bypassed. Change only one related set of rules during a pilot so that an unexpected result can be attributed clearly.

Warning: Never use an authentication exception as a reason to disable malware scanning. Even an allowed or correctly authenticated sender may use a compromised account or send malicious content. Restrict an exception to the proven authentication problem and the smallest necessary scope; keep all other protection checks active.

Understand DMARC, SPF and DKIM correctly

The three methods answer different questions:

SPF compares the sending mail server with the hosts, IP addresses and networks authorised in DNS by the owner of the envelope-from domain.
DKIM validates a message’s digital signature with the public key published in DNS by the signing domain.
DMARC assesses whether SPF or DKIM succeeds and whether its domain aligns with the visible domain in the From header. Without a valid DMARC record and an evaluable SPF or DKIM check, Sophos cannot fully evaluate DMARC.

The switch shown in the policy controls the failure action; the authentication checks themselves always run. This article concerns evaluation of inbound messages only. It neither creates nor hosts DNS records for your outbound domains and doesn’t enable outbound DKIM signing.

Configure Message Authentication

Open My Products > Email Security > Policies, select the correct Email Security policy, and verify its target group and position.
Open Settings > Inbound > Authentication.
Enable the required failure actions for DMARC, SPF and DKIM.
For each check, click Add Rule, then select a failure type and its action.
Order multiple conditions from the specific case to the more general one. Sophos checks them from top to bottom and applies the first match.
Save the policy and confirm that it is Enforced for the test recipients.

Sophos recommends Quarantine for each Message Authentication category. It is also a useful pilot setting because the message remains available for analysis and controlled release. Reject refuses it during processing; raw headers aren’t available in Sophos for rejected messages. Tag subject line marks the message and passes it to further processing. Deliver likewise means pass to the next scanning layer, not necessarily delivery to the mailbox. Include In End User Quarantine makes a quarantined message available in the user quarantine.

Grade failure types deliberately

For DMARC, Hard failure means that neither SPF nor DKIM passes with alignment. Its default is Conform to sender policy, so handling follows the sender’s DMARC policy. Other selectable cases are p=none, Unsupported, Temporary failure and Permanent failure. Unsupported applies only to Gateway mode here, while M365 bestguesspass applies only to M365 Mailflow mode. A separate p=none rule is mainly useful when Hard failure remains set to Conform to sender policy.

For SPF, the cases alongside Hard failure are Soft failure, Neutral, Unsupported, Temporary failure and Permanent failure. For DKIM, they are Unsupported, Temporary failure and Permanent failure alongside Hard failure. A temporary DNS error may resolve without intervention; a permanent failure indicates an uninterpretable published record. Don’t automatically treat either result as proven spoofing.

Processing order and Sender check

Message Authentication checks run in the order shown in the policy. To evaluate DMARC, Sophos runs the required SPF and DKIM checks regardless of their configured failure actions. DMARC fails if neither SPF nor DKIM passes with the necessary alignment. Where several failure rules exist, the first matching rule from the top always applies.

If a DMARC, SPF or DKIM rule matches with Quarantine or Reject, processing of that branch stops. If all three checks pass in a configuration using these actions, header-anomaly checks aren’t processed further and the message is delivered. The order therefore affects security behaviour; it isn’t merely visual ordering in the portal.

Under Sender check, Sophos adds two anomaly checks:

Header anomaly protects against external spoofing of your own domains. It triggers only when the domain in the visible From header matches any domain configured in the Sophos Fusion (formerly Sophos Central) account and that header address differs from the MAIL FROM address in the SMTP envelope. It checks every account domain, not only the recipient’s domain.
Domain anomaly detects sender domains that have neither an MX nor an A record.

For both checks, you can select Tag subject line, Quarantine, Reject or Deliver; Tag subject line is the documented default. During a pilot, use tagging or quarantine and inspect legitimate forwarding, CRM systems, ticketing platforms and external sending services before enabling Reject.

Configure Smart Banners

Under End-user message settings, enable each banner type separately, edit its predefined text and select the user actions to offer. The settings apply to inbound external HTML and plain-text messages. Sophos messages such as quarantine summaries don’t receive a Smart Banner.

The banner colour and statement are based on the allow list and DMARC result:

Trusted is green: the sender is on the allow list and the message passed DMARC.
External is yellow: the sender passed DMARC but isn’t on the allow list; or is on the allow list while Trusted is disabled; or has no DMARC record, so a pass or fail cannot be evaluated.
Untrusted is orange: a DMARC policy exists, but the message didn’t pass DMARC.

A banner is decision support, not proof that a message is harmless. Even a green banner doesn’t replace content scanning or care when opening links and attachments.

For each banner, you can offer Allow sender, Block sender and Report Spam messages to Sophos. Allow and Block open a confirmation page and update the user’s personal list; Report submits the message to SophosLabs as spam.

The guide to Inbound Allow/Block exceptions explains how personal and global entries interact and how to safeguard them with authentication, export, import, and rollback.

For Allow sender and Block sender to work in the HTML banner, open Global Settings > Products and Services > Email > User Settings, enable Release/Delete first and then Allow/Block List, and save. Allow and Block links aren’t available in plain-text banners.

Outbound email must be routed through Sophos Fusion when links in Smart Banners are used. Sophos recommends putting this routing in place before enabling End-user message settings; otherwise, external recipients may see the banner in replies or forwarded messages. In HTML it appears in colour at the top; in plain text it appears as text at the start of the body. An existing banner may remain visible when a message is replied to or forwarded internally.

Validate the outcome in Message History

For each relevant policy scope, send controlled inbound messages to a pilot recipient:

a legitimate message expected to authenticate successfully;
a legitimate message through a known forwarding or sending service;
where safely available, a message from your own test domain with a deliberately documented authentication failure.

Don’t forge production email or change someone else’s DNS records for a test. In Message History, search by sender, recipient and time range, open the message, and compare the applied policy, category, authentication or sender-check details, and actual action. For delivered messages, also check the banner’s type, text, colour and visible actions in HTML and plain text. Success means that good messages reach the expected next scan stage or mailbox, failures trigger the configured first matching action, and no unintended user actions appear.

Troubleshoot methodically

Unexpected DMARC or DKIM failure: Preserve the raw headers and sender-check details. Check whether an upstream gateway, disclaimer, mailing list or forwarding path changed the body or signed headers. Particularly with Sophos EMS behind another primary email-security system, modified messages can break DKIM and DMARC alignment; failure alone then doesn’t prove risk.
Wrong action despite a matching rule: Check policy scope, enforcement and policy order first, then read the failure rules from top to bottom. An earlier general match can hide a later specific rule.
Header anomaly for a legitimate service: Compare the visible From header with envelope MAIL FROM and identify which of your domains matched. Correct the sending configuration or alignment first; consider a narrowly scoped authentication exception only when that isn’t possible and the service is positively identified.
Domain anomaly for legitimate mail: Test MX and A resolution for the sender domain separately. Don’t answer temporary DNS trouble with a permanent global allow rule.
Banner is missing: Check that the correct policy and banner type are active, that the message was external and inbound, and that it isn’t a Sophos system message.
Allow/Block is missing or fails: Check Release/Delete and Allow/Block List in User Settings, HTML format and outbound routing through Sophos. Plain text doesn’t offer these links.

Only after this analysis should you adjust order, action or the narrowest necessary allow entry and repeat the same test. If the result remains unclear, collect the Message-ID, timestamp, sender, recipient, policy name, actual action and complete raw headers for escalation instead of broadly bypassing authentication or malware protection.