Domains & mail routing

A domain page (Organizations › organization › domain) controls where that domain's clean mail is delivered, whether it can send outbound through Obsidian, and shows the exact steps to connect it on its platform.

The line under the title shows the domain's current MX records and whether they already point at Obsidian.

Routing

Deliver clean mail to: The host that receives mail after scanning. Microsoft 365: <domain-with-dashes>.mail.protection.outlook.com. Google: aspmx.l.google.com. Exchange / other: the server's IP or name.
Port: Usually 25.
Look up MX records of the delivery host: Off (default): deliver straight to that host name. On: treat it as a domain and use its MX records (useful when delivering to a domain with several MX hosts).
Require TLS to the delivery host: Refuse to deliver unencrypted. Leave on for M365 / Google; untick only for an internal server without a certificate.
Accept inbound mail: Off = the gateway stops accepting mail for this domain (senders get "relay access denied").
Allow outbound relay: Lets relay clients send mail from this domain through the gateway. See Relay key.
Reject unknown recipients: Refuse mail to addresses that are not synced users or aliases (stops dictionary attacks and backscatter). Only turn on once a connector's user sync is complete; also requires Settings › Mail flow › Reject unknown recipients.

Save rebuilds the Postfix tables within seconds. Test delivery host opens an SMTP session to the host and reports whether it answered and whether it offers STARTTLS - run it after every change.

Mail-flow setup steps

The "Set up mail flow" card shows numbered steps for the organization's platform, filled in with your gateway host name and IPs. In summary:

Microsoft 365

Inbound connector in the Exchange admin center: from Partner organization to Office 365, identified by the gateway's IP(s), TLS required.
Enhanced Filtering for Connectors on that connector, skipping the gateway IPs - Microsoft then evaluates the real sender instead of the gateway.
Junk rule: mail flow rule "if header X-Obsidian-Spam matches Yes, set SCL to 6".
MX to the gateway.
Lock down after cut-over: reject inbound mail that did not arrive through the connector.
Outbound (optional): connector from Office 365 to Partner organization with the gateway as smart host, plus a transport rule adding X-Obsidian-Relay-Key; add Microsoft's outbound ranges to Outbound relay clients.
API connector for sync, sign-in and clawback.

Google Workspace

Gmail › Spam, phishing and malware › Inbound gateway: gateway IPs; after cut-over tick "Reject all mail not from gateway IPs"; spam header regexp X-Obsidian-Spam: Yes.
MX to the gateway.
Outbound (optional): Gmail › Routing › Outbound gateway = the gateway, with a routing rule adding the custom header X-Obsidian-Relay-Key; add Google's sending ranges (_spf.google.com) to Outbound relay clients.
API connector (service account).

Exchange Server

Delivery target = the Exchange server, port 25; its receive connector accepts anonymous mail from the gateway IP.
Junk rule: transport rule "header X-Obsidian-Spam is Yes → SCL 6".
Outbound: point the Send connector at the gateway as smart host and add the Exchange server's IP to Outbound relay clients.
MX to the gateway; forward TCP 25 on the firewall.
API connector (EWS + LDAP).

Other SMTP server

Set the delivery host, point MX at the gateway, allow the gateway on the server, and add the server to Outbound relay clients if it sends through the gateway.

If the gateway relays outbound mail, include its public IP in the domain's SPF record.

Outbound relay key

Microsoft 365 and Google send every customer's mail from the same IP ranges. Adding those ranges to Outbound relay clients would let any tenant on the platform relay "as" your domain through the gateway. The relay key closes that hole:

Generate key on the domain page and Copy it.
On the platform, make the outbound rule add a header X-Obsidian-Relay-Key: <key> to mail routed to the gateway.
From then on, relay-client mail from this domain without the correct header is refused with "Relaying denied". The header is removed before delivery, so the key never leaves.

Rotate key replaces it (outbound mail fails until the platform rule is updated - do both together). Remove drops the requirement. Senders authenticated with SMTP AUTH do not need a key.

DKIM signing (outbound)

Microsoft 365 and Google sign their own mail, so this is for Exchange / SMTP senders relaying through the gateway.

Enter a Selector (default obsidian) and Generate key (2048-bit RSA; the private key is stored encrypted).
Publish the TXT record shown (Name <selector>._domainkey.<domain>, Value copied with Copy value).
Outbound mail from the domain relayed through the gateway is signed from then on.

Regenerate creates a new key - update DNS first or signatures will fail to verify.

Remove domain

Stops accepting mail for the domain immediately. Its message history stays in the trace.