Outbound: routing customer mail through Coldfeet

Pointing MX at Coldfeet covers inbound mail. Outbound is a separate decision, and it is the direction that needs configuration on the customer's side.

Why bother

Inbound scanning does not see anything a customer's users send. Route outbound through Coldfeet and you get:

• DLP on the way out — the only place it can stop a leak.
• DKIM signing and ARC sealing with the domain's Coldfeet key.
• Stationery and disclaimers applied consistently.
• Outbound rate limiting, which contains a compromised mailbox before the sending IP gets listed.
• Archiving of sent mail alongside received mail.

Skip it and outbound still works — it just goes straight from the customer's provider to the recipient, unscanned.

Two ways to send

1. SMTP submission (small senders, applications, devices)

Coldfeet issues per-tenant submission credentials. Anything that can speak authenticated SMTP — a scanner, a line-of-business app, a small mail client deployment — can use them directly.

1. Dashboard → Settings → SMTP credentials → Create credential.
2. Copy the password; it is shown once and stored hashed.
3. Configure the sender:

Mail submitted this way is scanned, signed, and delivered by the same egress path as everything else. The envelope sender must belong to a domain the tenant owns; anything else is rejected rather than relayed.

2. Smart host from the customer's mail platform

For a whole organisation, route the platform's outbound through Coldfeet.

Microsoft 365

This is the case where a connector is genuinely required — Exchange Online will not hand mail to a third party without one.

1. Exchange admin center → Mail flow → Connectors → Add a connector.
2. From Office 365, to Partner organization.
3. Route all mail through this connector, with the smart host set to your Coldfeet mail host.
4. Require TLS, and validate on the certificate's subject name if your Coldfeet host presents a publicly trusted certificate.
5. Create submission credentials as above and give them to the connector, or allow the tenant's egress IPs on the Coldfeet side.

Test with a single mailbox first: Exchange applies the connector tenant-wide the moment it is enabled, so a misconfigured smart host stops all outbound mail.

Google Workspace

1. Admin console → Apps → Google Workspace → Gmail → Hosts.
2. Add a host pointing at your Coldfeet mail host on port 587, with TLS and authentication required.
3. Routing → add an outbound rule sending all mail to that host.

Exchange on-premises, Postfix, Zimbra

Set Coldfeet as the smart host / relayhost with SASL authentication against the submission credentials. Coldfeet listens for submission on 587 with STARTTLS.

Ordering

Configure and test outbound before the inbound MX cutover where you can. An outbound problem discovered at the same moment inbound mail starts arriving is much harder to isolate, and outbound has no equivalent of the deferral window protecting you while you sort it out.

Verifying it works

• Send a message from a customer mailbox to an external address.
• Dashboard → Message trace, filtered to outbound: the message should appear with a delivery result.
• Check the received headers at the far end for the Coldfeet DKIM signature and ARC seal.
• Trigger a DLP rule deliberately and confirm the message is held.

If outbound mail does not appear in the trace at all, the customer's platform is still delivering directly and the connector or routing rule has not taken effect.