Sophos Email Security SPF, DKIM and DMARC setup, step by step

For outbound Sophos Email Gateway mail, use the SPF include for your account's data-center region and generate a DKIM key for the correct domain in Gateway Domains. Publish the generated TXT record, run Test record, then activate the key and save. A published key is not an active signer, and an active signer is not proof of aligned DKIM on delivered mail. Sophos DKIM workflow

This guide covers the hosted Sophos Email Gateway outbound route. It does not reuse Sophos Firewall, UTM, legacy appliance or inbound-only authentication settings. Sophos Mailflow is a distinct integration with its own connection information. Current documentation uses the Sophos Fusion administration name and Global Settings navigation. Current product and region distinctions

Confirm that outbound messages actually use Sophos Gateway

Inventory the From domains, envelope sender domains, account region and message categories. Include employee mail, application notifications, aliases, replies and direct-sending services. Buying Sophos protection or routing inbound mail through it does not mean every outbound application uses the gateway.

The domain must be added and ownership verified. In Global Settings → Products and Services → Email → Gateway Domains, inspect the selected domain's direction and outbound configuration. The documented choices distinguish Inbound Only from Inbound and Outbound; outbound options include Microsoft Office 365, Google Apps Gmail and Custom Gateway. Use the integration appropriate to your actual mail platform. Do not enable overlapping Gateway and Mailflow paths to troubleshoot a DNS problem. Gateway domain prerequisites and route settings

SPF does not route SMTP traffic. A custom Exchange integration requires its supported connector and regional outbound relay; publishing an include alone cannot establish that route. Review Configure External Dependencies → Outbound Settings and the platform-specific guide with the mail-flow owner. Existing connector changes need their own migration and recovery plan. Exchange and other outbound-client integration

Before editing DNS, save the current zone records, applicable DMARC policy, existing selectors and approved sending paths. Retain other senders until their retirement is verified, not merely because the main mailbox route now uses Sophos.

For an application that sends through SMTP2GO instead of Sophos Gateway, use the SMTP2GO sender-domain and application-route guide. That separate route needs its own generated records and delivered-message evidence.

Select the regional SPF domain

Use the region chosen for the Sophos account, not the user's physical location. The current official Gateway table lists these SPF include mechanisms:

Sophos warns that the older shared _spf.prod.hydra.sophos.com domain can contribute to excessive SPF DNS lookups and directs customers to their regional value. Confirm the table against your current account and the official domain-information page before a change.

Merge authorizations without replacing other legitimate senders

The following is a hypothetical US East example for a transition in which both Microsoft 365 and Sophos are still authorized:

Before: v=spf1 include:spf.protection.outlook.com -all
After: v=spf1 include:spf.protection.outlook.com include:_spf_useast2.prod.hydra.sophos.com -all

The labels are explanatory, not part of the TXT value. If all authorized outbound traffic truly uses Sophos, a Sophos-only policy may be appropriate after inventory and testing. Do not remove Microsoft, Google or third-party permissions while a direct route still needs them. Sophos's outbound SPF guidance distinguishes a complete move from simultaneous sending.

Keep one v=spf1 TXT policy per owner. Put new mechanisms before its terminal all, preserve the agreed -all or ~all, and evaluate nested lookup-causing terms against the limit of ten. Do not use +all, add every region or insert an unmaintained static-IP snapshot. A softfail is not an SPF pass, and neither ~all nor -all determines a receiver's final delivery decision by itself. SPF result and processing rules

If the existing policy uses redirect=, remember that any all mechanism makes that redirect ignored, regardless of order. Before adding an ending or changing this design, identify and preserve the legitimate authorizations supplied by the redirected policy and the approved qualifier. Review the complete resulting evaluation, not just the new include. SPF all and redirect precedence.

Verify the envelope identity, not just the visible From

SPF authenticates the SMTP MAIL FROM domain for the connection that reaches the receiver. The visible From address is a different identity. Record the actual smtp.mailfrom and connecting IP in a delivered sample; for an empty reverse-path, SPF uses HELO. A provider-domain SPF pass may be unaligned with your brand even when the configuration is syntactically valid.

The Gateway documentation here does not establish a universal customer-configurable Return-Path feature. Do not invent a bounce CNAME or assume a rewritten envelope aligns. Measure the route, and rely on a verified branded DKIM signature where SPF alignment is unavailable.

Generate, publish, test and activate the Sophos DKIM key

Use an authorized Sophos administrator and the verified domain selected for this outbound route:

1. Open Global Settings → Products and Services → Email → Gateway Domains.
2. Select the exact domain and choose Add key.
3. Copy the generated public DKIM record, including its owner and full TXT value. Sophos generates a 2048-bit pair and retains the private key in its service.
4. Publish the public TXT record in authoritative DNS. Do not use a generic online private-key generator or a selector copied from another tenant.
5. After the record is visible, choose Test record. Investigate and correct discrepancies if it fails.
6. Activate the intended key and click Save.

Activating a key deactivates any other active key for that domain. Plan this as a signing-key change. Keep the previous public selector available for in-flight mail until the mail administrator confirms it can be retired. The provider's propagation estimate of up to an hour is not a promise that an incorrectly placed record will become valid. Sophos key generation, testing and activation

The record's shape is shown below, but both uppercase placeholders must come from your account. This is not a publishable record:

Type: TXT
Owner: GENERATED_SELECTOR._domainkey.SIGNING_DOMAIN
Value: COMPLETE_PUBLIC_DKIM_VALUE_FROM_SOPHOS

Do not alter a functioning key just to match an example. The service's generated selector and the s= value on the new delivered message should identify the same configuration.

Avoid apex, subdomain and selector-placement errors

Confirm the full DNS owner before saving. For these examples, SELECTOR represents the actual generated selector:

A DNS host that appends the zone name may turn a full name into SELECTOR._domainkey.example.com.example.com. Check the saved owner. If a child domain is delegated, edit its authoritative zone, not the parent-zone copy.

If _domainkey.alerts.example.com itself is delegated, publish the full owner SELECTOR._domainkey.alerts.example.com in that delegated namespace with relative name SELECTOR, not SELECTOR._domainkey. For a delegated _domainkey.example.com namespace, SELECTOR._domainkey.example.com likewise uses relative name SELECTOR. Confirm its authoritative service, preserve the NS delegation and do not edit a shadow record in the parent. These names illustrate placement only; retain the Sophos-issued selector. DNS zone authority.

Preserve MX routing, unrelated verification TXT records and other services' selectors. If a CNAME already occupies the required owner, do not place a TXT record alongside it or delete it without identifying its service owner. Resolve the conflict through a supported selector or coordinated migration. DNS owner and CNAME rules

The complete public key belongs in one logical TXT record. Multiple quoted character strings inside that record can be valid; several independent TXT records containing fragments are not equivalent. Never put the private key in DNS or an ordinary support ticket. DKIM key representation

Validate public DNS and the Sophos state separately

Replace the uppercase placeholders in these read-only patterns:

dig +short NS DNS_ZONE
dig @AUTHORITATIVE_NS TXT ENVELOPE_DOMAIN +noall +answer
dig +short TXT ENVELOPE_DOMAIN
dig @AUTHORITATIVE_NS TXT SELECTOR._domainkey.SIGNING_DOMAIN +noall +answer
dig +short TXT SELECTOR._domainkey.SIGNING_DOMAIN
dig +short TXT _dmarc.FROM_DOMAIN

Choose the authoritative server for each queried zone; a separately delegated signing domain may have different nameservers. SPF should return one policy containing the approved regional authorization and all retained senders. DKIM should return the complete generated public record, not an old selector's value. Check for truncation, duplicate policies and conflicting aliases.

Compare authoritative and recursive results. Different answers may reflect caching; no authoritative record means placement or publication still needs correction. SERVFAIL needs DNS troubleshooting, including DNSSEC where applicable. Record query time and resolver rather than labeling all delays “propagation.”

In Sophos, retain the Test record result and the active/saved key state as separate observations. Neither proves that a particular application traversed the gateway or received a valid signature.

Test the delivered outbound message

Use an authorized external recipient and retain the received original. Test each important route, especially normal mail, replies, application senders and downstream gateways. Sophos specifically warns that removing smart banners on outbound replies changes message content and recommends DKIM signing. Include that reply path in testing when used. Smart-banner signing warning

Inspect the receiving system's trusted Authentication-Results, the visible From, envelope identity, connecting IP and all DKIM d= and s= values. Do not accept an arbitrary sender-provided authentication header as evidence. Authentication-Results trust boundary

Establish the actual receiving service’s known authentication-processing boundary using its documentation or mail administrator. Confirm how it removes, ignores or distinguishes externally supplied Authentication-Results before relying on its own results; ignore attacker-supplied fields. A matching authserv-id or header position alone proves nothing. If that boundary cannot be established, leave acceptance unverified and obtain receiver-controlled diagnostics or an administrator-confirmed trace. Forged-header safeguards.

Require both a pass and alignment for the intended branded DKIM signature before closing this DKIM deployment. A generic dmarc=pass carried only by SPF is not enough. Equally, do not ignore genuine SPF fail, softfail, permerror, temperror or none results just because DKIM carries DMARC.

Also require trusted receiver dmarc=pass for the unchanged intended visible From. Reconcile the observed Sophos signature’s d= and s= with the domain and active key issued in the account; an unrelated added signature or an unnoticed provider-domain From rewrite is not successful completion.

DMARC itself needs either aligned SPF pass or aligned DKIM pass. Strict alignment requires exact domain equality; relaxed alignment permits the same organizational domain. A signature with d=example.com can exactly align with From: user@example.com; d=unrelated-provider.example cannot. Confirm the actual adkim and aspf modes. DMARC alignment

Keep DMARC policy and reports intact

Preserve the existing applicable DMARC policy and reporting recipients. Check parent-policy inheritance before adding a child policy. Do not replace established quarantine or reject protection with a monitoring example to conceal one route's failure.

Where no applicable policy exists, an owner-approved monitoring record can start from this pattern:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Use a real authorized reporting mailbox, not the example address. External reporting destinations may require authorization by the recipient domain. External reporting authorization Review reports by source, not just the overall pass percentage: a small direct-sending application can fail while the main gateway stream passes. Aggregate reporting

For aggregate-report authorization, compare the Organizational Domain of the report URI’s destination host with the Organizational Domain of the domain where the DMARC policy was discovered. If they differ, the receiver generating the report must check the destination’s DNS authorization; a destination within the same Organizational Domain is excepted from that external-authorization check. A different hostname alone is not enough. Separately obtain the domain owner’s approval for the recipient, data sharing and retention: protocol DNS authorization is not privacy approval. RFC 9990 section 4.

Do not move to enforcement solely because one message passed. Inventory legitimate sources and confirm reliable branded DKIM, including indirect-mail risks, before a separately approved policy change. RFC 9989 is the current DMARC specification and removes pct; do not build a new rollout around percentage sampling. Current DMARC policy considerations

Troubleshoot by observed failure

Test record fails: Compare the generated owner and full value with authoritative DNS. Check a repeated domain suffix, wrong zone, occupied CNAME, truncated key or multiple records. Do not generate successive keys while the original publication error remains unresolved.

Test record passes but DKIM is absent: Check activation and Save, the selected domain, direction and actual SMTP route. An inbound-only setup or bypassing application will not be fixed by adding another regional SPF include.

DKIM fails after a successful test: Compare the delivered selector and public key. Inspect changes after signing, including later gateways. If the active key changed, distinguish new messages from queued messages using the previous selector.

SPF permerror: Find duplicate policies, syntax errors, a broken include or excessive nested lookup terms. Check whether the legacy shared Sophos include remains. Do not approve every region as a workaround.

SPF fail or softfail: Confirm the connecting IP belongs to the intended route, the envelope owner is correct and no legitimate direct sender was removed. Temperror calls for DNS-resolution investigation; none means the evaluated identity lacks a usable SPF policy.

DMARC fails despite DKIM pass: Compare the passing d= with the visible From and alignment mode. A domain verification token, SPF syntax check or unrelated DKIM signature cannot substitute for alignment.

Only a helpdesk or invoice stream fails: Establish whether it actually sends through Sophos. Authenticate its real provider separately if it bypasses the gateway. Do not broaden relay permissions or disable inbound security controls to repair outbound identity.

Record the outcome and recovery plan

Keep the account region, selected domain, generated selector, previous key, DNS diff, Test record result, activation time and delivered-message evidence together. Assign a recovery owner before changing routing or active keys. On failure, pause the affected source or restore the previously approved configuration through the supported process, then retest. Keep public keys needed by in-flight mail.

This article is based on documentation, not a live implementation. No account setting, connector, DNS record, key or message was created or changed. Authentication does not guarantee delivery, inbox placement or safe message content.