Scope the Sophos Email gateway before changing authentication
This guide covers outbound domain authentication in Sophos Email, using the Gateway Domains workflow documented on September 14, 2026. It does not configure Sophos Firewall, legacy UTM, endpoint protection, or every Mailflow integration. Similar product names are not evidence that their controls, selectors or relay requirements are interchangeable. Record the actual service, region, domain and outbound route before proposing changes. An inbound filtering deployment alone does not establish that outgoing messages pass through Sophos or receive its signatures. The Sophos domain-information guide expressly distinguishes Gateway and Mailflow information.
A useful starting inventory lists human mailbox messages, application-generated notices, automatic replies and services that send directly to recipients. For each class, identify the system that makes the final outbound SMTP connection. Do not add Sophos authorization to an unrelated application's domain merely because the organization buys Sophos security products. Equally, do not assume a direct-sending application becomes covered when the main mailbox connector changes. These are proposed review steps, not observations about an actual deployment.
Generate the public record in the correct domain context
The DKIM keys guide describes Global Settings, Products and Services, Email, Gateway Domains. Select the intended domain and choose Add key. Sophos generates the key pair, displaying public information for a DNS TXT record while retaining the private key in the service. The documented key size is 2048 bits. Copy the generated public record rather than constructing a selector or borrowing another domain's key. No private key is needed in the DNS change request or this article's worksheet.
Before publication, have the DNS owner check the complete owner name, record type and value. A DNS editor may append the zone name to an entered label, so compare the resulting fully qualified name rather than relying on how the input box looks. Confirm that the proposed owner does not overwrite another active selector. Record the intended signing domain separately from the visible author domain; they need an alignment assessment, not an assumption based on a matching business name.
Separate publication, testing and activation
Sophos documents Test record after the TXT record is published. The check compares the DNS record with the information in Sophos Email. If it fails, investigate the name, value and authoritative DNS location before repeating the check. The provider's stated propagation estimate is planning guidance, not a promise that a wrongly placed record will repair itself with time. Keep the requested change, actual public answer and provider status as separate evidence items.
The next documented steps are to activate the key and click Save. Critically, activation deactivates any other active DKIM key for that domain. This is a rotation-impact decision, not just a cosmetic switch. Identify the previous selector, outstanding messages and rollback owner before changing the active signer. Do not immediately delete the previous public record merely because the console now shows a new active key. The appropriate overlap depends on actual message transit and verification requirements, which have not been measured here.
Use regional SPF authorization without confusing it with routing
The domain-information guide lists region-specific Sophos SPF domains and warns that the legacy shared domain can contribute to excessive DNS lookups. Choose the entry for the actual account region and review it within the domain's existing SPF policy. Do not paste an entire example that removes other legitimate senders. The guide's routing-oriented wording should not be read literally as a property of SPF: an SPF record authorizes an identity's sending hosts; it does not create an SMTP connector or redirect mail through a gateway.
RFC 7208, sections 2.4 and 4.6.4 define the MAIL FROM identity and limits on evaluated DNS-dependent terms. Count the relevant evaluation path, including nested dependencies, rather than only the number of visible include strings. Preserve one coherent SPF policy at the relevant owner. The Sophos guide also distinguishes regional outbound relay hosts and notes that Microsoft 365 and Google Workspace integrations do not need an outbound relay host entered through that particular instruction. Confirm the integration's own workflow rather than importing a generic Exchange recipe.
Verify identity and message modification together
A published key and successful provider check do not prove that a representative message carries a passing signature. A separately authorized acceptance exercise should examine trusted receiver results, the signature's signing domain and selector, the author domain, the envelope identity and the actual route. RFC 6376, section 3.5 defines DKIM signature fields. RFC 9989, section 4.4 explains alignment; a passing signature for an unrelated domain is not automatically a DMARC pass for the author domain.
Sophos specifically recommends signing when smart banners are enabled because it removes banners from outbound replies, modifying the message. That is a reason to inspect the final signed message path, not a guarantee that every modification or forwarding arrangement preserves an earlier signature. Keep receipt, authentication and inbox placement separate. Neither this document nor a green configuration status establishes that a recipient read a message, accepted its business request or considers its content safe.
Fictional diagnosis: the correct record for the wrong route
A fictional organization, Harbour Workshop, publishes a generated key for its main domain and records a successful Test record result. Its helpdesk application still sends directly through another service. A reviewer initially treats the main-domain configuration as evidence for all outgoing mail. The acceptance inventory exposes the gap: the helpdesk route never traverses the gateway whose key was activated.
The proposed correction is to label the helpdesk route unresolved, identify its actual sending service and obtain route-specific evidence before changing DNS. It is not to add more Sophos records blindly or disable a receiver's checks. This scenario contains no real headers, DNS observations, tenant access or executed tests. Its purpose is to demonstrate why product, domain and transport must appear together in the acceptance record.
Blank acceptance worksheet and release boundary
Complete this worksheet only with authorized observations. Leave unknown fields open rather than turning a planned action into a completed check.
- Product, mode, account region and domain: ______
- Message categories and actual outbound routes: ______
- Generated public owner, TXT value reference and existing selector dependencies: ______
- DNS change owner, approval and rollback reference: ______
- Regional SPF entry and complete-policy evaluation evidence: ______
- Test record result, time and actual published-answer reference: ______
- Activation decision, previous key and public-record retention plan: ______
- Trusted received-message evidence and alignment result by route: ______
- Unresolved exceptions, reviewer and release decision: ______
This is a documentary configuration guide. Original implementation evidence, human subject-matter review, current source applicability, production-route testing, visual accessibility and owner release remain open. No key was generated, DNS changed, message sent or tenant inspected for this manuscript. The broader catalogue acceptance requirement must be satisfied separately before publication readiness can be asserted.