Cover Image for Why internal email in Exchange never reaches a gateway

Why internal email in Exchange never reaches a gateway

Mail between two mailboxes on the same Exchange Server never leaves the server. Why no connector and no transport rule changes that, and the three paths to encrypted internal mail.

4 minExchange

Almost every environment with its own Exchange has a gateway in front of the server. It filters, encrypts, signs and logs. What many only notice in an audit: none of that applies to mail between two colleagues. The message never reaches the gateway.

What Exchange does with an internal message

Outlook hands the message to the mailbox server. The transport service accepts it, and the categorizer resolves the recipients in Active Directory. If a recipient belongs to the organisation, the destination is their mailbox database. The message is delivered directly.

A send connector never comes into play. It is only chosen for address spaces outside the organisation. That is not a misconfiguration, it is how Exchange is built.

Why the usual levers do not work

Accepted domain set to internal relay. With the type InternalRelay, Exchange delivers locally to every recipient that exists in the directory. Only unknown recipients go to the connector. Nothing changes for internal mail.

Transport rules. On your own Exchange, rules can redirect messages, send copies, set headers and apply rights management. The action that routes a message through a specific outbound connector exists only in Exchange Online. Redirecting to an external address changes the recipient, not the path.

Journaling. A journal rule captures internal mail for the archive. Nothing gets encrypted or protected, it only creates a copy.

The consequences

  • Internal messages with HR data, health data or contracts sit unencrypted in mailboxes.
  • Data loss rules at the gateway do not see internal forwarding.
  • The gateway's message tracing knows nothing about internal mail.

Three paths to encrypted internal mail

1. S/MIME per person

Every mailbox gets a certificate, deployed through group policy or software distribution. It works without a gateway. The price is upkeep: certificates on every device, regular renewal, a process for new staff, and in the end the person still decides whether to encrypt.

2. Helper domain

A second domain such as secure.company.com is set up in Exchange as external relay, a send connector routes it to the gateway, which rewrites the address back and delivers. Technically clean. In daily life, though, everyone writes to the usual address. Without contacts in the address book and training, the path stays empty.

3. Transport agent

An agent in the transport service sees every message, including internal ones. It hands internal mail to the gateway over SMTP, the gateway applies the rules and returns the message to Exchange. The agent recognises its own marker and lets it be delivered locally.

This path changes neither addresses nor mailboxes. It needs care in three places:

  • Gateway failure. The message has to be deferred, not delivered unprotected. Clear text cannot be recalled.
  • Outlook format. Outlook sends internally in its own TNEF format. Meetings and tasks do not survive a conversion, ordinary messages still have to be captured.
  • Stability. An agent that fails to load must not stop the transport service.

Details are in the article on the Exchange transport agent.

How Conbool solves it

Conbool ships the third path as a ready-made Exchange agent. It starts in observe mode, then routes internal mail through SecureMail and defers when the gateway is unavailable. More on the page encrypt internal email in Exchange, setup is described in the Exchange agent documentation.

Set Conbool as a preferred source on Google

Google shows content from preferred sources more often in Search, in AI Overviews and in AI Mode. The selection can be changed at any time.

Set as preferred source

More articles

The latest posts from our blog.