Skip to content
Avanet

Sophos Email: configure Gateway domains, DKIM and SMTP routing

Sophos Email

A Gateway domain is ready for production only when ownership, the inbound destination, outbound source and DNS dependencies all agree. The safest sequence is to record the original state, verify the domain, configure internal destinations, copy the MX and SPF data shown for your Sophos Fusion region, test both mail directions, and only then enable BATV, DKIM or a custom outbound route.

Quick path: Under Products and Services > Email > Gateway Domains, add the domain and verify the displayed ownership TXT record. Set destinations, gateways and the port, save, and complete Configure External Dependencies. For DKIM, generate a 2048-bit key, publish the generated selector TXT record, check it with Test record, and only then activate it. Configure a route to a downstream SMTP system separately under Custom SMTP Routing and test it with an outbound message.

Scope and safe preparation

This guide applies only to Sophos Email Gateway in Sophos Fusion. Do not use Gateway and Mailflow for the same domain at the same time, as this can create duplicate entries in Message History. Custom SMTP Routing processes outbound Gateway messages only, isn’t available when EMS mode is enabled, and must be configured in Microsoft 365 for Sophos Email Mailflow. On-box Mail Protection on a Sophos Firewall is another product too.

If the architecture hasn’t been selected conclusively, first use Sophos Email: choose an architecture and plan onboarding. Before making changes, record for each domain:

  • current MX, SPF and DKIM records, including TTLs;
  • the current inbound destination, outbound gateways, authorized source networks and SMTP ports;
  • every system that sends directly as the domain, plus forwarding paths and relays;
  • owners for Sophos Fusion, DNS, the firewall and the downstream mail server;
  • test recipients, the change window, abort criterion and approved rollback path.

Lower a high DNS TTL early enough under your change procedure. Don’t remove an old path until inbound and outbound tests over the new path succeed.

Add a Gateway domain and verify ownership

  1. In Sophos Fusion, open Global Settings and go to Products and Services > Email > Gateway Domains.
  2. Click Add Domain and enter your domain under Email Domain.
  3. Open Verify Domain Ownership. Copy the host or name and complete TXT value shown in this dialog exactly into the authoritative DNS zone. This record proves ownership only; it doesn’t alter mail flow.
  4. Allow DNS to propagate and click Verify. Sophos states that this ownership record can take up to ten minutes. An unverified domain can’t be saved; correct DNS instead of bypassing the check.
  5. Close the dialog after successful verification and choose Inbound Only or Inbound and Outbound. Outbound scanning, reporting and features such as smart banners require Inbound and Outbound.

Verify every domain separately. A TXT value from another domain or tenant isn’t interchangeable, even if its hostname looks similar.

Set destinations, gateways and ports

Under Inbound destination, select Mail Host for one publicly reachable destination, or MX when Sophos should deliver using a mail-exchange name. Multiple destinations require MX. For Mail Host, enter the public IP address or FQDN of the router, firewall or front-end mail server; for MX, enter the mail exchange FQDN. Private addresses and names that resolve only internally aren’t suitable cloud delivery targets.

With Inbound and Outbound, select one or more outbound sources: Microsoft Office 365, Google Apps Gmail or Custom Gateway. For Custom Gateway, enter at least one public source IP or appropriate CIDR range and click Add. Include only systems that are genuinely permitted to send this domain through Sophos; unnecessarily broad networks increase relay risk. The mail server or service can submit messages to Sophos on port 25 or 587. Match this selection to the firewall, provider and TLS configuration.

These outbound gateways authorize a source to Sophos. They aren’t the same as Custom SMTP Routing, which selects a destination away from Sophos after processing.

Copy regional DNS and relay values

After Save, Configure External Dependencies displays the tenant-specific data. Inbound Settings contains MX values and Sophos delivery IP addresses; Outbound Settings shows a relay host when one is needed. These values depend on the region and can change, so this article doesn’t copy them. Compare the Sophos Fusion data region and copy values directly from the current Sophos email domain information.

Apply four rules during cutover:

  • public MX records point to both Sophos MX targets for your region and retain their priorities;
  • the downstream mail host accepts delivery only from the published Sophos Gateway IPs for your region;
  • merge the existing SPF TXT data into one syntactically valid SPF record and add only the regional Sophos include value;
  • configure a Sophos relay host only where the provider procedure requires it; according to Sophos, Microsoft 365 and Google Workspace don’t require an additional outbound relay host.

Don’t newly deploy the broad legacy include _spf.prod.hydra.sophos.com. It can produce SPF PermError: too many DNS lookups. Don’t add other regions as a precaution either: that consumes DNS lookups and can break mail flow. Before changing MX, test the authoritative DNS response and internal destination reachability; afterward, check external resolvers and actual delivery.

Enable BATV under control

Bounce Address Tag Validation (BATV) tags outbound envelope senders and detects inbound delivery reports without a valid tag. Sophos treats a message with no SMTP envelope sender and content-type: multipart/report; report-type=delivery-status as a bounce. BATV is reliable only when all outbound mail for the domain passes through Sophos Email.

When adding or editing the domain, enable BATV enabled and choose the failure action. Use Quarantine, not Delete, for the first week. This also applies after re-enabling BATV: bounces for messages sent before activation don’t yet have a tag and may be legitimate. During that week, inspect normal non-delivery reports, release legitimate matches carefully, and tighten the action only after a documented review. The optional Apply BATV to a message marked bounce by SophosLabs heuristics setting expands detection to automatically generated responses, so test it with representative mail as well.

Configure DKIM with a 2048-bit key

  1. Under Products and Services > Email > Gateway Domains, open the domain whose outbound mail passes through Sophos and click Add key.
  2. Sophos generates a 2048-bit key pair. The private key remains in Sophos Email; copy the displayed selector or DNS name and the full public-key TXT value exactly to the DNS provider.
  3. Allow DNS to propagate. Sophos states this can take up to one hour. Then click Test record. If it fails, keep the key inactive until the name and value are corrected and the test passes.
  4. Only after a successful test, activate the key and click Save. Activation deactivates any other active DKIM key for that domain. Keep the previous public selector during the transition so messages already in transit can still be verified.
  5. Send a new outbound message through Sophos and inspect its received headers for DKIM=pass and the expected signing domain.

The d= value in DKIM-Signature must align with the sender domain for Sophos evaluation. If the signing domain differs and no signature meets this alignment, Sophos can report dkim=none. Resolve conflicts between multiple signing providers first; this procedure configures Sophos Email outbound signing only.

Test and revert custom SMTP routing

Use a custom route when outbound messages from a domain, after Sophos processing, must go to a particular downstream gateway, archive or other SMTP system.

  1. Record the old destination and port, then confirm reachability of the new destination and its relay permission for Sophos.
  2. Open Global Settings > Products and Services > Email > Custom SMTP Routing and click Add.
  3. Select the domain, enter the destination IP or FQDN and the SMTP port actually offered by the destination, then click Add.
  4. Send a message from that domain to a controlled external recipient. Check the connection and handoff in Message History, and independently confirm final delivery at the destination system and recipient.
  5. If the test fails, don’t stack DNS, policy and routing changes. Revert the new route from the recorded baseline or restore the former destination, test again, and only then investigate DNS, port, firewall, relay permission and TLS negotiation one at a time.

A Message History entry proves Sophos processing but not final mailbox acceptance by itself. Acceptance therefore requires a destination-server trace or log and recipient confirmation.

Edit and delete without breaking dependencies

To edit a domain, click its name in Gateway Domains, change the values and save. Before changing a destination, port, gateway, BATV or DKIM, capture the current state and change only one dependency per test cycle.

Don’t delete a domain as a quick rollback. First inventory and remove or move every dependent MX and SPF record, provider connector, smart host, authorized relay source, custom SMTP route, DKIM signing setting and downstream restriction. Test the replacement path in both directions. Only when no message or system depends on the Gateway domain should you use the Delete icon next to it. If dependencies remain uncertain, keep the domain and coordinate removal with Sophos or the provider.

Validate and troubleshoot by layer

Acceptance is complete only when all of these checks pass:

  • the ownership TXT is authoritatively visible and the domain is verified in Gateway Domains;
  • MX and the regional SPF include match Sophos’s current display for the tenant region;
  • one inbound and one outbound test message can be traced in Message History and reached the final recipient;
  • a legitimate delivery-status notification was handled correctly by the chosen BATV action;
  • a new outbound message contains the Sophos DKIM signature, returns DKIM=pass, and uses the expected d= domain;
  • a custom SMTP route shows both successful Sophos handoff and destination-system acceptance.

When a check fails, isolate the layer instead of disabling protection:

  • Ownership or DKIM test fails: Check the authoritative zone, exact host or selector, TXT value, quoting or splitting of long TXT values, duplicate records and propagation.
  • SPF PermError: too many DNS lookups: Confirm there is one SPF record, inspect its lookup tree, and replace the broad Sophos include with the current regional value.
  • Inbound mail is missing: Check public MX answers, the correct region, Sophos Gateway IP allowlisting, destination FQDN and port, and provider or mail-server logs.
  • Outbound mail is missing: Check the authorized source IP or CIDR, port 25 or 587, firewall, smart host, relay permission and TLS negotiation.
  • BATV catches legitimate bounces: Stay on Quarantine, confirm all outbound traffic crosses Sophos, and account for messages sent before activation.
  • dkim=none despite a signature: Compare d= in DKIM-Signature with the visible sender domain and investigate additional provider signatures or modifications after signing.

For escalation, collect the domain, tenant region, timestamps, Message-ID, sender and recipient, authoritative DNS responses, and events from Sophos Message History and the downstream system. Never include passwords, private keys or complete confidential message bodies in a support ticket.