DirectAdmin External Mail: Google Workspace and M365 Without Problems

A common request from customers is to keep the website on the DirectAdmin server while their mailboxes live in Google Workspace or Microsoft 365. The DNS part is simple, but the part that catches people is Exim on the server: if it still believes the domain is local, a contact form on the website sends mail to a local mailbox that nobody reads, and the customer reports that “the website emails do not arrive”. Since 1.703 DirectAdmin’s Exim configuration performs a forced MX check that changes how these situations resolve, so the setup is worth doing carefully.

Short answer: Replace the domain’s MX records with the provider’s, add the SPF include and verification records, then untick the option to handle the domain’s email locally on the MX Records page so the domain leaves /etc/virtual/domains and Exim routes it by DNS. Since 1.703 the FORCED_MX_DNS_CHECK Exim setting delivers remotely even when that box is left ticked, provided the server’s resolver returns the correct MX.

Set the MX records

Change the MX records in User Level → DNS Management (or Admin Level → DNS Administration as admin). Delete the existing MX pointing at the server’s mail hostname and add the provider’s records.

For Google Workspace the current recommendation is a single record:

example.com.  MX  1  smtp.google.com.

Older Workspace tenants may still be set up with the five aspmx.l.google.com records; both work, so follow what the Workspace admin console shows for that tenant.

For Microsoft 365 the record is tenant-specific and shown in the Microsoft 365 admin centre under the domain’s DNS settings. It follows the pattern:

example.com.  MX  0  example-com.mail.protection.outlook.com.

Both providers also want a verification TXT record, an SPF include: (_spf.google.com or spf.protection.outlook.com) and, for Microsoft, an autodiscover CNAME. Add these in the same DNS page. If the domain’s DNS is not hosted on the DirectAdmin server, make the same changes at the external provider instead.

Tell DirectAdmin the mail is external

On the same MX Records page in the user’s panel there is a checkbox labelled to the effect of using this server to handle the domain’s email. Untick it. This is the step that matters more than the MX records themselves: it removes the domain from /etc/virtual/domains, so Exim stops treating it as local and routes mail for it by DNS like any other remote domain.

Confirm from the shell:

grep -c '^example.com$' /etc/virtual/domains      # expect 0
grep '^example.com:' /etc/virtual/domainowners    # still present, the domain is hosted here
exim -bt user@example.com

The exim -bt output should show the address routed via the lookuphost router to the provider’s MX hosts, not to a local mailbox.

The 1.703 forced MX check

DirectAdmin 1.703 introduced FORCED_MX_DNS_CHECK in the Exim configuration. When enabled, Exim looks up the MX for a locally hosted domain at delivery time and, if the MX does not point back at this server, delivers remotely even though the domain is still listed as local. In practice it protects against the mistake described above: a customer who changes MX at an external DNS provider but never unticks the local-mail box still gets their contact-form mail delivered to Google or Microsoft.

The behaviour is controlled from /etc/exim.variables.conf.custom, which survives ./build exim_conf:

grep FORCED_MX_DNS_CHECK /etc/exim.variables.conf /etc/exim.variables.conf.custom

Set it to 1 in the custom file to enable it if your build defaults it off, or to 0 if you have a deliberate split-delivery setup that the check would break, then rebuild:

cd /usr/local/directadmin/custombuild && ./build exim_conf

The check has a cost: an extra DNS query per local recipient, and a dependency on the resolver being correct. If the server’s resolver returns stale MX data (a caching resolver with a long TTL, or split-horizon DNS that returns the server’s own IP for everything), mail loops or lands locally. Servers with a local Unbound resolver built through CustomBuild are fine; servers pointed at a flaky upstream resolver should keep the check off and rely on unticking the local-mail box.

Mail sent by the website

Once the domain is external, PHP’s mail() and SMTP-sending plugins still hand mail to the local Exim, which now routes it to the provider. The provider will reject it unless the server is authorised in the domain’s SPF record, so add the server’s IP or its hostname’s A record to the SPF you built above:

v=spf1 include:_spf.google.com a:srv1.example-host.net ~all

Better still, have the website send through the provider’s SMTP with an app password, so the mail leaves from the provider’s IP space and inherits its reputation. DKIM signing for the domain on the DirectAdmin side is optional in that setup because the provider signs.

Common pitfall: the reverse case

The opposite mistake is just as common. A domain whose mailboxes were moved to the server from an external provider still has the box unticked, so Exim refuses local delivery and mail bounces with an “unrouteable address” or is sent out to the old provider. The fix is the same checkbox, in the other direction, followed by an exim -bt check.

Verify

Send a test from the website (a contact form or a one-line PHP script) and a test from an outside mailbox, and confirm both arrive in the Google or Microsoft mailbox. On the server:

grep 'example.com' /var/log/exim/mainlog | tail -n 20
exim -bp | grep -c example.com

Delivery lines should show R=lookuphost T=remote_smtp with the provider’s host, and the queue count for the domain should be zero. If messages are stuck, the Exim mail queue report shows the deferral reason, which for external domains is nearly always an SPF rejection from the provider.

DirectAdmin external mail at a glance

Official documentation: Microsoft 365 documentation, Google Workspace Admin Help, DirectAdmin documentation.

Related guides: Configuring DirectAdmin’s Exim to relay through MailBaby · Rspamd vs SpamAssassin, DKIM, SPF and DMARC on DirectAdmin · Setting a custom webmail URL and branding Roundcube 1.7 on DirectAdmin.

Frequently asked questions