Sophos EMS: Configure policies and interpret findings

Sophos Email Monitoring System (EMS) uses Email Security and Data Control policies to show how Sophos Email would have assessed a message. In EMS mode, however, the configured actions are reporting results only: Quarantine, Reject, Deliver, or any other selected action does not change actual delivery.

The most important configuration principle is therefore to mirror the email security environment currently used in production as closely as possible. Only then do the EMS findings provide a meaningful comparison. Particularly for DKIM and DMARC, bear in mind that an upstream security solution may modify messages.

Quick path: Under My Products > Email Security > Policies > Email Security, create or edit a tightly scoped policy, assign users, groups, or domains, and align the inbound and outbound settings with the existing environment. Within the open policy, the relative path is Email Security policy > Settings > Inbound > Authentication. For content rules, select My Products > Email Security > Policies > Add Policy > Data Control. Then check the saved settings and assignments and initially evaluate findings with a limited scope.

Important: An action configured in EMS is not evidence that the production message was blocked, rejected, delivered, or quarantined. EMS simulates the Sophos Email verdict for reporting purposes.

Scope of this EMS guide

This page is the primary workflow for the EMS-specific combined view: it shows how to reproduce previously defined Email Security and Data Control rules as an observation-only model and how to interpret the resulting simulated findings together. It is deliberately not a fourth general policy manual.

Scope, priority, assignment, cloning, enforcement, and production rollback of an Email Security Policy belong in the guide Sophos Email Security: Create and assign policies.
Design, actions, exceptions, test cases, and production operation of Data Control rules belong in Sophos Email Data Control: Configure DLP rules safely.
Failure types, actions, order, and production validation of DMARC, SPF, DKIM, and Sender Checks belong in Sophos Email: Configure sender authentication and Smart Banners.

The following steps therefore repeat only the fields needed for a comparable EMS assessment model. If a policy needs to be newly designed, enforced in production, or fundamentally repaired, follow the relevant specialist article named above and then transfer its approved target values to EMS.

Prerequisites, licensing, and roles

For this workflow, EMS must already be able to assess messages from the intended email environment. You also need access to My Products > Email Security > Policies and a documented reference for the protection policies currently used in production. This must include at least the affected user, group, or domain scope and the current inbound, outbound, authentication, and content rules.

Neither a separate role nor an additional license tier is documented for editing these policies. If Policies is missing or a setting cannot be changed, do not adjust roles or licenses based on guesswork. Instead, clarify the intended access with the responsible Sophos Fusion administrator or partner.

Before making changes, record:

the name, priority, status, and assignments of the existing policies;
the actions currently used in production for the same checks;
the affected internal and external users, groups, or domains;
the required inbound and outbound settings;
a small pilot scope, such as a test group or a single domain;
the previous configuration as a rollback point.

For external users and domains, remember that Sophos uses the sender and recipient SMTP envelope addresses for assignment, not the visible From and To headers. A sender that appears to match can therefore fall outside the expected policy scope.

Align the Email Security policy with the existing environment

This section does not define a new protection strategy. The already approved policy is the reference; EMS reproduces its scope and settings for comparison. General policy assignment, including priority, cloning, and enforcement, remains in the policy article named above.

Open My Products > Email Security > Policies > Email Security.
Edit the existing Email Security policy or use Add Policy to create a custom policy.
Enter an unambiguous policy name, for example EMS - Pilot - existing protection rules. The name is freely selectable and should make the scope and purpose clear.
Under internal assignments, select the intended users, groups, or domains. The pilot scope should be small enough to associate its messages and findings unambiguously.
If the existing environment uses rules for external senders or recipients, add the relevant addresses or domains on the External tab and include or exclude them deliberately.
Configure the inbound settings and outbound settings to match the protection rules currently used in production.
Verify that the policy is enforced and not Policy Bypassed, then select Save.

By default, custom policies do not apply to Distribution Lists, Shared Mailboxes, and Public Folders. If such objects are part of the intended scope, the tenant-wide Apply custom policy to DL and shared mailbox setting must already be set appropriately. Do not change this setting incidentally for an EMS test; first assess its effect on other policies separately.

Most Email Security policy settings apply to inbound messages. Individual documented exceptions may also apply outbound, such as Enhanced content and file property scan, S/MIME, or an Outbound Disclaimer. Do not apply the same values to both directions indiscriminately; compare each field with the production reference.

Configure DMARC, SPF, DKIM, and Sender Checks

The full path is My Products > Email Security > Policies > Email Security > Settings > Inbound > Authentication; relative to the policy already open, it is Email Security policy > Settings > Inbound > Authentication. The checks always run; the policy controls the failure action. In EMS mode, this action also remains a simulation. General selection and prioritization of failure actions belongs to the sender-authentication guide named above; here, those target values are only transferred to EMS, and their findings are interpreted within the EMS-specific message-mutation boundary.

Set DMARC check, SPF check, and DKIM check according to the documented reference.
Use Add Rule to enter the required failure types and associated action.
Put the conditions in the intended order. Sophos evaluates them from top to bottom and uses the first match.
Save the policy.

The documented default for DMARC is DMARC check: on with Hard failure: Conform to sender policy. Do not change this value merely because a stricter action sounds safer. For a meaningful EMS comparison, the selection must match the current email environment.

The results mean:

SPF compares the sending IP address with the authorized hosts, IP addresses, or networks in the SPF record.
DKIM validates the digital signature using the public key published in DNS and compares the calculated hash.
DMARC requires a valid DMARC record and a successful, aligned SPF or DKIM path. For SPF, the Envelope-From domain is compared with the visible From domain; for DKIM, the signature’s d= domain is compared with the visible From domain.
Header anomaly detects messages that use your own domain as the sender but originate from an external domain.
Domain anomaly detects sender domains without an MX or A record.

Depending on the check, configurable failure classes include Hard failure, Soft failure, Neutral, Unsupported, Temporary failure, and Permanent failure. Not every class applies to every check or operating mode. A Temporary failure may resolve without intervention; a Permanent failure, by contrast, indicates a DNS record that cannot be interpreted correctly and must be corrected by the domain owner.

The interface offers actions such as Conform to sender policy, Tag subject line, Quarantine, Reject, and Deliver. In EMS, these describe only what Sophos Email would have done under the modeled policy. They do not perform that delivery action.

To manage the DNS side of DMARC and the legitimate senders for your own domain, follow the separate workflow in Set up Sophos Email DMARC Manager. This article instead covers the assessment of inbound messages in EMS and does not duplicate DNS setup.

Configure a Data Control policy as an observation model

Data Control checks the content of inbound or outbound emails. Here too, selected actions in EMS are for reporting only. The rules should therefore mirror the active email environment rather than be planned as new production enforcement. The Data Control guide named above determines which detection, action, exception, and test matrix is suitable; this section transfers only the approved result into the EMS observation model.

Open My Products > Email Security > Policies > Add Policy > Data Control and select Continue.
Enter an unambiguous policy name.
Assign internal users, groups, or domains. Add external users or domains as needed.
Open Settings. A new Data Control policy initially contains no rules.
Create rules with the required rule conditions and actions. You can use Sophos templates or custom conditions based on Content Control Lists, keywords, and phrases.
Check the order and status of the rules. Sophos evaluates them from top to bottom and uses the first matching rule.
Save the policy and ensure that it is not Policy Bypassed.

A Data Control policy can contain up to 25 rules; a custom keyword or phrase list can contain up to 200 entries, without case sensitivity. These limits are not a reason to make the pilot unnecessarily broad. For initial acceptance, a small, clearly identifiable test condition matching the existing environment is sufficient.

Sophos also analyzes SMTP envelope addresses for Data Control. A rule for external recipients should therefore be planned against the actual envelope recipient, not only the visible To line.

Validate and interpret findings

First, check the configuration itself:

the correct policy name and intended status;
the correct assigned users/groups/domains;
appropriately configured inbound and outbound settings;
the expected order of authentication or Data Control rules;
DMARC check, SPF check, DKIM check, Header anomaly, and Domain anomaly enabled only where they belong in the reference environment;
the intended simulated action for each condition.

Then send representative messages within the limited pilot scope. For authentication, use legitimate external senders with known SPF, DKIM, and DMARC characteristics. For Data Control, use an approved test message that matches exactly one clearly attributable rule. Do not use real confidential, financial, or personal data in the test.

The expected result is that EMS assesses the message according to the assigned policy and presents the configured action as a finding. The production message remains unaffected by this EMS action. If no matching finding is visible, next check the policy assignment, envelope sender and recipient, rule order, and policy status. No dedicated menu path to findings is documented for this policy step. Validation is therefore limited to the EMS findings available in the tenant.

A single DKIM fail or missing DMARC alignment behind an upstream email security solution is not yet proof of a dangerous message. For interpretation, consider at least the visible From domain, Envelope-From, DKIM d= domain, signature verification result, and any upstream processing step together.

Troubleshooting by symptom

DKIM fails for legitimate messages

Check whether the primary email security solution changed headers or signed message parts before the journal copy reached EMS. DKIM compares the hash calculated from the received message with the decrypted signature. After a change, these values can differ. Compare the finding with an unmodified reference message and the known delivery path instead of classifying the message as malicious solely because of the EMS result.

DMARC alignment is missing despite a known domain

Check the Envelope-From, visible From domain, and DKIM d= domain separately. DMARC passes when SPF or DKIM both validates and aligns with the visible From domain. An upstream modification can particularly affect DKIM and therefore the DMARC path. For your own domains, investigate the exact DNS and sender state using the linked DMARC Manager workflow.

The wrong policy, or no policy, appears to apply

Check the assigned users/groups/domains, external inclusions or exclusions, and SMTP envelope addresses. Then check policy priority and status. For Data Control, also consider the order: the first matching rule applies. For a cloned policy, check whether assignments were added and Policy Bypassed was changed to the enforced state.

An expected authentication check is missing

The checks run in their displayed order. If a message fails the first message-authentication check, subsequent authentication checks are no longer performed. The missing later check is therefore not evidence of a configuration issue; explain the preceding finding first.

Data Control produces unexpected matches

First check the pilot scope, envelope sender and recipient, and the highest matching rule. Then compare the template, Content Control List, keywords, or phrases with the test message. If multiple rules could match, their order is decisive. Do not broaden rules until the specific match has been explained.

Safe rollback and decommissioning

A complete EMS deactivation process and a separate deletion workflow for these policies are not documented. Therefore, do not delete policies based on guesswork.

For a safe rollback:

Before making the change, record the previous status, assignments, rule order, conditions, and actions.
If findings are unexpected, do not broaden the scope or make the simulated action stricter.
Reopen the policy, restore the documented previous values, and save it.
Use the same pilot case to verify that the original assessment reappears.
If the policy is to be permanently decommissioned, first clarify its assignments and possible dependencies. The actual deactivation or deletion step follows the change process approved for your tenant. Without a documented workflow, do not perform any additional deactivation or deletion steps.

Because EMS does not apply the actions to delivery, this rollback restores the assessment model. It does not remove journaling or change the production mail flow.

Operations, review, and lifecycle

Regularly compare policies and findings with the production email security environment. A review is particularly necessary after changes to upstream filters, sender domains, SPF, DKIM, or DMARC configurations, user and group assignments, or Data Control rules. Repeat the same limited pilot after each adjustment.

For operations, document the policy owners, scope, rule order, reference configuration, and known legitimate deviations caused by upstream message processing. This makes it possible to identify whether an EMS finding changed because of an actual sender change, a policy deviation, or a mutation in the delivery path.

The current help pages for this workflow do not specify a dedicated EOL, migration, or shutdown date. Do not infer such dates from older announcements. When the product changes, compare the visible fields and simulated behavior with the current Sophos help again before adjusting policies or evaluation rules.