Website and Email at Different Providers: How to Set the DNS Records Correctly

Your website is at one company and your email is at another, typically Google Workspace or Microsoft 365, and something broke. Maybe mail stopped arriving right after you moved the website. Maybe the contact form sends notifications that never reach the office, while email from outside arrives fine. Maybe Outlook keeps asking for a password, or bounces say 550 5.1.1 recipient rejected or No such user here.

The internet uses different DNS records to find your website and your mail, so the two can happily live at different providers. Problems happen when the records get mixed up: a new web host takes over the DNS and replaces the mail records with its own, or the web server still believes it is responsible for your mail and delivers messages to a forgotten mailbox on itself. Small businesses that move their site, and designers who set up hosting for a client whose mail already lives elsewhere, hit this all the time.

What is happening

Each record type has one owner. Get the owner right and both services work independently.

Record	Example name	Belongs to	Purpose
A / AAAA	example.com, www	Web host	Where browsers connect for the site
CNAME	www, shop, blog	Web host or site platform	Alias to the host’s hostname
MX	example.com	Mail provider	Where other servers deliver your incoming mail
TXT (SPF)	example.com	Shared	Lists every server allowed to send as your domain
TXT or CNAME (DKIM)	SELECTOR._domainkey	Each sending service	Public key that proves messages were signed by that service
TXT (DMARC)	_dmarc	You	Policy for failed SPF and DKIM checks
CNAME	autodiscover, autoconfig	Mail provider	Lets mail apps configure themselves
SRV	_autodiscover._tcp and others	Mail provider	Service locations for some mail and calling setups
TXT (verification)	example.com	Mail provider and other services	Proves you own the domain

When a server wants to send mail to you@example.com, it looks up the MX record for example.com and connects to the hosts listed there. It never looks at the A record. So the website can move freely without touching mail, provided nobody changes the MX and related records.

Before you start

You need access to the DNS host (whoever your nameservers belong to), the web hosting panel, and the admin console of your mail provider, which lists the exact records it expects. Take a copy of the current DNS zone before editing anything, either as an export or as the output of the dig commands below saved to a file.

How to run the commands. The dig commands run on your own computer: built in on macOS, from the dnsutils or bind-utils package on Linux, and through WSL on Windows (or PowerShell’s Resolve-DnsName -Name example.com -Type MX). Server commands in Step 4 run over SSH on the web server, and the WordPress command runs in the site folder (the one with wp-config.php) using wp or wp-cli depending on your host.

Step 1: See what the world sees now

dig +short NS example.com
dig +short MX example.com
dig +short TXT example.com
dig +short CNAME autodiscover.example.com

example.com is your domain. +short prints only the answers. Read them like this:

• NS tells you which provider’s DNS editor actually counts. Edit records there and nowhere else.
• MX should name your mail provider, for example a Google host such as smtp.google.com or the older aspmx.l.google.com set, or a Microsoft host ending in mail.protection.outlook.com. If it shows mail.example.com or example.com and that resolves to your web server, incoming mail is going to the web host.
• TXT should include one line starting v=spf1 and your mail provider’s verification value.
• autodiscover should point at your mail provider if you use Outlook with Microsoft 365. A CNAME to the web host makes Outlook try to log in to the wrong server.

Compare every value with the record list in your mail provider’s admin console. Copy values from there rather than from memory or old tutorials, because providers change their recommended records over time.

Step 2: Fix the zone after a nameserver change

The most common way mail breaks is a well meaning instruction from a new web host: “point your nameservers at us”. When you do, the new host’s DNS becomes the whole truth for the domain. Its zone is usually generated automatically, with an MX record pointing at its own mail server and no trace of your Google or Microsoft records. Mail starts flowing to an empty mailbox on the web server, or bounces, as caches expire over the following hours.

Confirm this is your cause

If dig +short NS example.com shows the new web host’s nameservers and the MX points at the web host, this is it. Check what the old zone had by querying the previous nameservers directly, if they still answer:

dig @OLD_NS example.com MX +noall +answer
dig @OLD_NS example.com TXT +noall +answer

OLD_NS is one of your previous nameservers (from the old provider’s documentation or your notes). The @ sends the question directly to it, bypassing caches, and +noall +answer shows only answer lines. If they still return your mail provider’s records, you have a ready list of what to restore.

Two ways to fix it

1. Keep the new nameservers and repair the zone: in the new host’s DNS editor, delete its MX record and add your mail provider’s MX records, SPF, DKIM, DMARC, autodiscover and verification records exactly as the provider’s console lists them.
2. Put DNS back where it was: change the nameservers back to the old DNS host and simply update the website’s A record (and www) there to the new host’s IP. This keeps all mail records untouched, and it is often the cleaner option.

Either way, remove the old values from the server side too (Step 4), or the web server keeps capturing your own outgoing notifications.

Step 3: Build one SPF record that covers both providers

If the website sends mail (contact forms, order emails, password resets) as an address on your domain, receivers check whether the sending server is listed in SPF. Your mail provider’s SPF include covers only its own servers, so mail sent directly from the web server fails SPF unless you add it.

v=spf1 include:MAIL_PROVIDER_SPF ip4:WEB_SERVER_IPV4 ~all

This is the value of a TXT record at the bare domain, edited in your DNS host. MAIL_PROVIDER_SPF is the include domain from your mail provider’s setup guide (Google Workspace uses _spf.google.com, Microsoft 365 uses spf.protection.outlook.com). WEB_SERVER_IPV4 is the outgoing IP of your web server; your host can confirm it, or you can read it from the Received headers of a message the site sent. ~all asks receivers to treat unlisted senders with suspicion.

Rules that catch people out:

• Exactly one TXT record may start with v=spf1. Two separate SPF records is an error that makes SPF fail entirely. Merge them into one.
• SPF allows at most 10 DNS lookups in total, and every include, a and mx counts, including the ones inside other includes. Use ip4 for your web server rather than a, which also breaks if the site is later proxied through a CDN.
• Better still, have WordPress send through your mail provider or a transactional mail service over authenticated SMTP, so the web server does not send as your domain at all. Our WordPress not sending email guide covers SMTP setup, and our sender requirements guide covers DKIM and DMARC alignment.

Step 4: Stop the web server delivering your mail locally

This is the sneaky one. Outside mail arrives fine, but messages sent from the website to info@example.com vanish. The DNS is perfect. The problem is inside the web server.

Most hosting control panels create a mail domain for every website automatically. The server’s mail software then considers itself the final destination for example.com. When WordPress on that same server sends a form notification to info@example.com, the mail software never looks up MX at all: it delivers the message into a local mailbox that nobody reads, or rejects it because that mailbox does not exist. External senders are unaffected because they follow MX to Google or Microsoft.

Confirm it

• Send a test from the website’s form to an address on the domain, and a second test to an outside address such as a personal Gmail. If only the outside one arrives, local delivery is likely.
• Look in the hosting panel’s mailbox list or webmail for the domain. Missing messages sitting in a local mailbox, or bounces in the panel’s delivery report, confirm it.
• On servers with Exim, test the routing decision over SSH as root:

exim -bt info@example.com

-bt runs Exim’s address test mode: it shows how Exim would route the address without sending anything. info@example.com is any address on your domain. Good output for remote mail names a remote SMTP transport and lists your mail provider’s hosts. Bad output names a local or virtual delivery router or transport, or a mailbox path on the server, meaning Exim will keep the mail locally. If you are on shared hosting without root, ask your host to run it.

On servers with Postfix, check which domains it treats as its own:

postconf mydestination virtual_mailbox_domains virtual_alias_domains

This prints those three settings. If your domain appears in any of them, Postfix delivers locally. Remove it there, or in the panel that generates these settings, and reload Postfix.

Fix it

Look in the panel for the domain’s mail routing setting. It is usually called something like email routing, mail exchanger or mail service, with choices along the lines of local, backup, remote, or automatic detection. Set it to remote so the server always delivers by MX lookup. Some panels instead have a switch to turn the mail service off for the domain, which has the same effect. Some panels keep this in plain lists, for example separate local domain and remote domain files under /etc; editing those by hand is overwritten by the panel, so use the panel setting.

Be careful with automatic detection. It decides based on whether the MX records point at the server, so it can flip back to local if you ever add a backup MX that resolves to the web server, or if the DNS hosted on the server still lists a local MX. Remote is the explicit, safe choice.

Also delete any mailboxes, forwarders or autoresponders that were created on the web host for the domain, so nobody keeps using them by mistake.

Step 5: Test both services end to end

1. Incoming mail: send from an outside account to a mailbox on the domain and confirm it arrives at the real provider.
2. Website mail: submit the contact form and a password reset, and confirm both arrive in the real mailbox.
3. Authentication: open the original source of a form message and read the Authentication-Results header. You want spf=pass, dkim=pass and dmarc=pass.
4. Mail apps: add the account to Outlook or a phone mail app from scratch and confirm automatic setup finds the right provider.
5. Website: load the site in a private window to confirm the A record change did not affect it.

To find the WordPress side of a failing notification, list recent mail activity if you use an SMTP plugin with logging, or confirm which address WordPress sends to:

wp option get admin_email

This runs over SSH in the WordPress folder and prints the site’s admin email address, which receives core notifications. If it is an address on your own domain, it is affected by local delivery until Step 4 is fixed.

Our diagnostic tools can check MX, SPF and DKIM records from outside your network.

Advanced: Planning a split setup that survives future moves

If you manage sites for clients, set up every split hosting arrangement so that a web host change can never touch mail:

• Host DNS independently of both the web host and the mail provider, for example at the registrar or a dedicated DNS service. Moving the site then means changing one or two A records, never nameservers.
• Point www at the host with a CNAME where the host supports it, so their IP changes do not need your involvement.
• Give every sending service its own DKIM selector and document them. Mail provider, newsletter tool, helpdesk and transactional service each publish a key under a different selector name, and each needs to be copied if DNS ever moves.
• Use DMARC reports to spot senders you forgot. A rua tag in the DMARC record sends you aggregate reports listing every IP sending as your domain; an unknown web server IP failing SPF tells you a site is sending directly.
• Keep the web host’s mail service off from day one for domains whose mail lives elsewhere.

Check your SPF lookup count whenever you add a service:

dig +short TXT example.com | grep spf1
dig +short TXT MAIL_PROVIDER_SPF

The first line shows your SPF record. The second expands one include (replace MAIL_PROVIDER_SPF with an include domain from your record) so you can see whether it contains further includes. Count every include, a, mx, ptr, exists and redirect across the whole tree; above 10, receivers return a permanent error and treat SPF as failed.

When to contact your host

Contact your web host if local delivery continues after you set routing to remote, or if you cannot change the setting. Contact your mail provider if mail does not reach them even though MX is correct. Include:

• The domain, your mail provider and your web host.
• Output of dig +short NS, MX and TXT for the domain.
• A test message’s UTC send time, sender and recipient, and any bounce with full headers.
• For the web host: the result of the Exim or Postfix check, or a request that they run it, and the panel’s current mail routing setting.
• What changed recently: nameservers, hosting move, new plugin or new mail provider.

If the website is down as well as the mail, start with the Emergency Room.