Connecting Exchange on-premises without switching the MX

An in-house Exchange can be connected without touching the MX record of the domain. The reason is simple: the MX only governs the inbound path. Signature, encryption, disclaimer and outbound rules however apply on the outbound path, and that is redirected on the Exchange itself, not in DNS.

For mailboxes in Exchange Online the path through Exchange connectors applies instead.

What this path does and what it does not

Outgoing messages leave the Exchange through a send connector to Conbool. Signature and disclaimer, S/MIME and PGP encryption, outbound rules and the DKIM signature apply there. Afterwards the message goes to the recipient.

Incoming messages continue to run straight to your own server. Everything that works at the entrance is therefore not involved: spam and malware defence, quarantine and the archiving of incoming mail through the mail path. Anyone who needs that as well switches the MX and runs both directions through Conbool.

Moving to both directions is possible at any time later and consists of a changed MX record and a changed operating mode in the portal. Nothing changes at the send connector.

Values you will need

example.com stands for your own mail domain, 203.0.113.20 for the public address from which your own Exchange sends to the outside.

Smart host and certificate name are shown in the portal under Settings, Domains, in the respective domain in the mail server field. In the cloud edition both read mail.conbool.com. Partner and on-premises installations show different values there.

Step 1: set up the domain in the portal

The domain is created through the setup wizard as usual. Three records are needed, the fourth is deliberately left out:

• TXT for verification under _verification.example.com, value from the wizard.
• DKIM under the displayed selector. Without it, outgoing mail is not signed.
• SPF with two components, see the next section.
• The MX stays unchanged. The wizard shows it as an open point in amber; verification does not depend on it and completes without it.

Step 2: set SPF correctly

In this mode the SPF record has to cover two sources, and both are required:

v=spf1 ip4:203.0.113.20 include:mail.conbool.com ~all

Your own address covers submission at the gateway. Messages with a tenant domain in the sender are only accepted if the submitting address is covered by the SPF of that domain. If it is missing, the gateway rejects with 550 5.7.1 The message failed the SPF check. This check is the protection against foreign messages under your own sender identity and is not suspended.

The include covers delivery from Conbool to the recipient.

A direct ip4: entry is moreover the precondition for outgoing messages to be signed with DKIM. An address covered only through a foreign include: is not sufficient for that, because shared sending pools would otherwise obtain valid signatures for foreign senders.

There may only be one SPF record per domain. An existing record is extended, not replaced.

Step 3: set the operating mode to outbound

In the portal under Settings, Domains, in the domain in the Mail path section, set the direction to Outbound only.

That removes the MX from the list of recommended records and from the health check. Without this setting the domain page permanently reports the missing MX as an open point, even though the setup is complete.

Step 4: send connector on the Exchange

In the Exchange admin console under Mail flow, Send connectors, create a new connector of the type Internet. Use * as the address space, Route mail through the following smart hosts as forwarding with the value mail.conbool.com and no authentication. As source servers, enter the transport servers that send to the outside.

The same state through the Exchange Management Shell:

New-SendConnector -Name "Conbool" `
  -AddressSpaces "*" `
  -DNSRoutingEnabled $false `
  -SmartHosts "mail.conbool.com" `
  -SmartHostAuthMechanism None `
  -RequireTLS $true `
  -TlsAuthLevel DomainValidation `
  -TlsDomain "mail.conbool.com" `
  -Port 25 `
  -SourceTransportServers "EXCH01"

TlsAuthLevel DomainValidation checks the name in the certificate of the remote server and thereby prevents an unnoticed redirection. The value under TlsDomain is the certificate name from the portal, in the cloud edition the same name as the smart host.

If a send connector with the address space * already exists, do not create a second one but change the existing one. Two connectors with the same address space and the same cost lead to unpredictable routing.

Step 5: verify

Send a message from a mailbox to an external address. Expected:

• The signature is attached.
• The headers of the message that arrived at the recipient show a DKIM signature of your own domain and the path through the Conbool host name.
• The message appears in the portal under Message tracing with the direction outbound.

If nothing appears there and the message stays in the Exchange queue, Get-Queue gives the reason. A rejection with 550 5.7.1 The message failed the SPF check. means the sending address is not in SPF, see step 2. A rejection with 550 5.7.1 The domain is not verified on this service. means the verification of the domain in the portal is not yet complete.

Signature through the Outlook add-in

The signature can alternatively be applied without any mail path, purely in the mailbox through the Outlook add-in. That path however requires mailboxes in Exchange Online: it relies on a sign-in token issued by Microsoft and on an event handler that does not exist in Exchange on-premises. For in-house mailboxes the send connector is the right path. On the add-in path see signature without mail flow.

In a hybrid environment the distinction applies per mailbox: mailboxes in Exchange Online can use the add-in, in-house mailboxes run through the send connector.