There are good reasons to host a domain’s website in one place and its email in another. The website may be on a platform-as-a-service that does not do mail at all. The mail may be on Microsoft 365 while the site sits on your own infrastructure. An agency may want its client sites on its own reseller platform whilst the client’s mailboxes stay with a specialist provider.
All of these are reasonable. The problem is that DNS makes the split possible without making it obvious what else needs to change, and the parts that get forgotten are exactly the parts that produce a bad first impression: mail clients that will not configure themselves, mail that lands in spam, and Outlook hanging on the setup screen for ninety seconds.
This article covers the complete DNS picture for a split setup.
The part everyone gets right: MX
Mail routing is decided entirely by the MX records for the domain. The A record for the domain — the one pointing at the website — plays no part in it, so long as MX records exist.
example.com. IN MX 10 mx1.mailhost.net.
example.com. IN MX 20 mx2.mailhost.net.
Lower preference numbers are tried first. Two records with the same preference are load-balanced.
Two rules that are worth stating because breaking either causes real problems. MX targets must be hostnames, never IP addresses — an IP in an MX record is invalid and some senders will refuse it outright. And MX targets must not be CNAMEs; the target must resolve directly to an A or AAAA record.
The failure mode when MX records are missing entirely is subtle: senders fall back to the domain’s A record and attempt delivery to your web server, which is not listening on port 25. Mail queues, then bounces after a few days.
The part people get wrong: SPF still belongs to the mail host
SPF authorises the IP addresses that send mail for your domain. When you move mail to a separate provider, the SPF record must describe that provider — not your web host.
example.com. IN TXT "v=spf1 include:_spf.mailhost.net -all"
But there is a catch that split hosting makes more likely. Your website almost certainly sends mail too: contact form notifications, password resets, order confirmations, WordPress admin alerts. That mail leaves from your web server’s IP, which the mail provider’s include: does not cover.
You have two options, and only one of them is good.
The bad option is to add the web server’s IP to your SPF record. It works, but it means a shared web server’s IP is now an authorised sender for your domain, and its reputation is not yours to control.
The good option is to have the website send through the mail provider’s authenticated submission service, on port 587 with credentials, exactly as a mail client would. In WordPress that means an SMTP plugin rather than PHP’s mail(). In Laravel it means the smtp mail transport rather than sendmail. The mail then originates from the mail provider’s IP, is covered by the existing SPF record, and gets DKIM-signed on the way out.
That second option also fixes DMARC alignment, which the first does not — mail sent directly from the web server is unsigned, so it depends entirely on SPF, and if you ever move to p=reject it becomes fragile.
DKIM and DMARC in a split setup
DKIM selectors are published in DNS by you, using key material supplied by whoever signs the mail. In a split setup that is the mail provider, and they will normally give you either a TXT record to publish or a CNAME pointing into their infrastructure:
sel1._domainkey.example.com. IN CNAME sel1.dkim.mailhost.net.
The CNAME form is worth preferring where it is offered, because it lets the provider rotate keys without you touching DNS. DMARC is unaffected by the split — one record, at _dmarc.example.com, regardless of where anything is hosted.
The part nearly everyone forgets: client autoconfiguration
Here is where split hosting produces its most visible symptom. A user types their email address and password into Outlook, Apple Mail or Thunderbird and expects it to work out the rest. When it does not, they conclude the mail service is broken.
Mail clients discover settings by probing hostnames derived from the domain in the email address. That domain is yours, so the probes hit your DNS and your web server — not the mail provider’s, however good their own autodiscovery is.
There are three mechanisms, and which one fires depends on the client.
SRV records (RFC 6186)
The lightest-touch option, honoured by Thunderbird, Apple Mail and a number of mobile clients. Publish where each service actually lives:
_imaps._tcp.example.com. IN SRV 0 1 993 mail.mailhost.net.
_submission._tcp.example.com. IN SRV 0 1 587 mail.mailhost.net.
The four numbers are priority, weight, port and target. Use _imaps._tcp on port 993 for implicit TLS, and _submission._tcp on port 587 for authenticated submission with STARTTLS. If your provider offers implicit TLS submission on port 465, the record name for that is _submissions._tcp — note the second "s". Getting that name wrong is a common and confusing mistake.
Do not publish _imap._tcp on port 143 unless you genuinely want clients defaulting to a plaintext-capable port.
Thunderbird-style autoconfig
Thunderbird and clients derived from it fetch an XML document over HTTPS, trying https://autoconfig.example.com/mail/config-v1.1.xml and https://example.com/.well-known/autoconfig/mail/config-v1.1.xml.
The document is straightforward:
<?xml version="1.0" encoding="UTF-8"?>
<clientConfig version="1.1">
<emailProvider id="example.com">
<domain>example.com</domain>
<displayName>Example Ltd Mail</displayName>
<incomingServer type="imap">
<hostname>mail.mailhost.net</hostname>
<port>993</port>
<socketType>SSL</socketType>
<authentication>password-cleartext</authentication>
<username>%EMAILADDRESS%</username>
</incomingServer>
<outgoingServer type="smtp">
<hostname>mail.mailhost.net</hostname>
<port>587</port>
<socketType>STARTTLS</socketType>
<authentication>password-cleartext</authentication>
<username>%EMAILADDRESS%</username>
</outgoingServer>
</emailProvider>
</clientConfig>
password-cleartext looks alarming and is not: it means the password is sent as plaintext inside the TLS session, which is how essentially all IMAP and submission authentication works. The alternative, password-encrypted, means CRAM-MD5 or similar, which is now rarely used and worse in practice.
%EMAILADDRESS% is substituted by the client. If your provider uses the local part alone as the username, use %EMAILLOCALPART% instead.
Since the .well-known path lives on your web server, this is one you can serve as a static file from the website — which is convenient precisely because the website is the thing you control.
Outlook autodiscover
Outlook uses a different mechanism, and it is the fussiest of the three. It tries, roughly in order: https://example.com/autodiscover/autodiscover.xml, then https://autodiscover.example.com/autodiscover/autodiscover.xml, then an SRV lookup on _autodiscover._tcp.example.com.
The SRV route is by far the simplest to operate in a split setup, because it hands the whole problem to the mail provider:
_autodiscover._tcp.example.com. IN SRV 0 0 443 autodiscover.mailhost.net.
A CNAME works too, and is what Microsoft 365 asks for:
autodiscover.example.com. IN CNAME autodiscover.outlook.com.
What you must not do is leave autodiscover.example.com pointing at your web server with nothing serving that path. Outlook will connect, wait, get a 404 or a redirect to your homepage, and take a noticeable amount of time to give up before falling through to the next method. The ninety-second hang that users report during account setup is almost always this.
If you do want to serve autodiscover yourself, note that Outlook sends an HTTP POST with an XML body, not a GET, and expects a response in the .../responseschema/2006a namespace. Serving a static file works because most web servers will return it for a POST, but it is worth confirming rather than assuming.
A worked example
Domain example.com. Website on your own hosting at 203.0.113.20. Mail with a separate provider whose infrastructure lives under mailhost.net.
; Website
example.com. IN A 203.0.113.20
www.example.com. IN CNAME example.com.
; Mail routing
example.com. IN MX 10 mx1.mailhost.net.
example.com. IN MX 20 mx2.mailhost.net.
; Authentication
example.com. IN TXT "v=spf1 include:_spf.mailhost.net -all"
sel1._domainkey.example.com. IN CNAME sel1.dkim.mailhost.net.
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
; Client autoconfiguration
_imaps._tcp.example.com. IN SRV 0 1 993 mail.mailhost.net.
_submission._tcp.example.com. IN SRV 0 1 587 mail.mailhost.net.
_autodiscover._tcp.example.com. IN SRV 0 0 443 autodiscover.mailhost.net.
autoconfig.example.com. IN CNAME autoconfig.mailhost.net.
Note what is not there: no mail.example.com A record pointing at the web server, and no leftover MX from the previous host. Both are common residue from a partial migration, and both cause problems — the first sends clients to a server with no IMAP daemon, the second silently routes a fraction of inbound mail to a mailbox nobody reads.
Verifying it
# Where does mail go?
dig +short MX example.com
# Are the autoconfiguration records visible?
dig +short SRV _imaps._tcp.example.com
dig +short SRV _autodiscover._tcp.example.com
# Does the autoconfig document actually serve?
curl -sI https://autoconfig.example.com/mail/config-v1.1.xml
# Does the mail server answer on submission, with TLS?
openssl s_client -starttls smtp -connect mail.mailhost.net:587 -crlf
Then do the test that matters: set up a brand-new mailbox on a clean device, in each of Outlook, Apple Mail and one mobile client, using only the email address and password. If any of them asks for a server name, autoconfiguration is not working for that client, and every user you onboard will hit the same wall.
FXRM hosts UK email independently of where your website lives, with autoconfiguration, DKIM and PTR configured from the start. See our email hosting →
