MX Records for Subdomains: The Complete Guide to Routing Email Like a Pro

So you want to set up email on a subdomain. Maybe you’re trying to route support@help.yourdomain.com to your helpdesk, or you want newsletters@mail.yourdomain.com to run through your ESP without torching your main domain’s reputation. Whatever the reason, you’ve landed on the right page.

MX records for subdomains are one of those DNS topics that seem simple until they’re not. DNS doesn’t do inheritance the way you might expect, there are authentication records to worry about, and one wrong CNAME can silently break everything. Let’s untangle all of it.

What’s an MX Record, Really?

Quick Answer: An MX (Mail Exchanger) record is a DNS entry that tells the internet which mail server handles incoming email for a domain or subdomain.

When someone sends an email to you@example.com, their mail server doesn’t just guess where to deliver it. It looks up the MX records for example.com in DNS, gets back a list of mail servers with priority numbers, and connects to the highest-priority one. Simple enough. The structure of an MX record looks like this:

Each record has four key pieces:

• Name — the domain or subdomain this record applies to
• Priority — lower number = higher priority; mail goes there first
• Mail server — the hostname of the server that accepts the mail (must be an A record, never a raw IP)
• TTL — how long other DNS servers cache this record

Multiple MX records at the same priority create load balancing — mail servers pick randomly between them. Different priorities create failover — if the top server is down, mail falls through to the next one.

The Big DNS Myth: Subdomains Don’t Inherit MX Records

Quick Answer: Subdomains do NOT inherit MX records from the root domain. Every subdomain needs its own MX record if you want it to receive email.

This catches people out all the time. You’ve got example.com pointed at Google Workspace, everything works great, and then you add a subdomain and expect user@support.example.com to magically work. It won’t. DNS doesn’t do parent-to-child inheritance for MX records.

Each subdomain is its own zone as far as mail routing is concerned. If there’s no MX record for support.example.com, one of two things happens:

• If there’s no MX record AND no null MX, sending mail servers may try falling back to the subdomain’s A record (your web server). That’s bad — your web server is probably not running an SMTP daemon on port 25.
• If the subdomain has a null MX record (more on that shortly), the sending server gets a clean rejection instead of an awkward timeout.

So: if a subdomain needs to receive email, give it MX records. If it doesn’t, explicitly tell the world with a null MX.

Why Would You Even Want Subdomain MX Records?

Good question. Here are the real-world scenarios where this actually makes sense.

1. Protecting Your Main Domain’s Reputation

This is the big one. If you send marketing blasts or cold outreach from example.com, and those campaigns get spam complaints, your main domain’s reputation takes the hit. That means even your transactional emails — password resets, order confirmations, receipts — start landing in junk.

The fix: blast from mail.example.com or marketing.example.com. Give that subdomain its own MX records, its own SPF, its own DKIM. If reputation tanks, it’s isolated. Your main domain keeps delivering.

A 2025 study by Mailgun found that senders who split marketing and transactional traffic across separate subdomains saw a 24% lower spam folder rate over six months compared to senders using a single domain. That’s not nothing.

2. Routing Different Teams to Different Inboxes

Maybe your company runs Google Workspace for internal email, but your support team uses Zendesk or Freshdesk for customer email. You can give help.example.com its own MX record pointing at your helpdesk’s inbound mail processor, completely independent from the rest of your email setup.

3. Email Service Provider (ESP) Sending Streams

Services like Mailgun, SendGrid, Brevo, and Amazon SES typically ask you to verify a sending domain. You can delegate a subdomain like send.example.com entirely to your ESP, give it the ESP’s MX records for bounce processing, and keep your root domain clean.

4. Migration Scenarios (Google ↔ Microsoft 365)

When you’re migrating between email providers and can’t flip the switch for everyone at once, subdomain routing is the standard workaround. Microsoft’s official migration guide even recommends creating a subdomain specifically to route mail between old and new platforms during the transition period.

5. Securing Unused Subdomains

If you have subdomains that legitimately don’t send or receive email — say dev.example.com, staging.example.com, cdn.example.com — those are potential phishing surfaces. We’ll cover how to lock them down with null MX records below.

How to Set Up MX Records for a Subdomain

The mechanics are the same at every major DNS provider, just with different UIs. Here’s the universal approach.

Step 1: Log Into Your DNS Provider

Go to wherever you manage DNS. Common options include Cloudflare, Namecheap, GoDaddy, AWS Route 53, or your domain registrar’s built-in DNS manager.

Step 2: Create a New MX Record

Add a new DNS record with these fields:

Field	Value	Notes
Type	MX	Always MX, never A or CNAME
Name / Host	subdomain (e.g. mail or help)	Just the subdomain label, not the full FQDN
Value / Mail Server	The FQDN of the mail server (e.g. aspmx.l.google.com)	Must end in a dot if your provider requires FQDN notation
Priority	10 (or whatever your provider specifies)	Lower = higher priority
TTL	3600 for stable setups; 300 when making changes	In seconds; lower TTL = faster propagation

Using Cloudflare? Here’s what the raw DNS record looks like:

Step 3: Wait for Propagation

DNS changes can take anywhere from a few minutes to 48 hours to propagate globally, though in practice it’s usually under an hour with most modern providers. You can check propagation status with whatsmydns.net or the command-line tools covered later in this guide.

Provider-Specific Setup for Common Mail Platforms

Google Workspace

For a subdomain hosted on Google Workspace, use the same five MX records as your root domain:

You’ll also need to add the subdomain as a secondary domain or alias in your Google Admin console for addresses at that subdomain to actually work.

Microsoft 365

Microsoft 365 uses a unique MX hostname per domain. The format is your domain name with dots replaced by hyphens, followed by .mail.protection.outlook.com:

The exact hostname is shown in your Microsoft 365 admin center under Domains. You’ll also need to add the subdomain as an accepted domain in Exchange Online.

Cloudflare Email Routing

Cloudflare Email Routing is a surprisingly solid free option for forwarding subdomain email to an existing inbox. Add your subdomain in the Email Routing section and Cloudflare will handle the MX records automatically:

Email Authentication for Subdomains: SPF, DKIM, and DMARC

Here’s where a lot of people drop the ball. Setting up MX records lets you receive email on a subdomain. But if you’re also sending from that subdomain, you need authentication records too — and the inheritance rules are all over the place.

SPF — No Inheritance, Full Stop

SPF (Sender Policy Framework) does NOT inherit from the parent domain. If you send mail from mail.example.com and there’s no SPF record for mail.example.com, SPF returns none — not a pass, not a fail, just nothing. That hurts your deliverability.

Each subdomain needs its own SPF record:

DKIM — Also No Inheritance

DKIM (DomainKeys Identified Mail) records are placed at specific selector subdomains, so by nature they’re already subdomain-specific. Your ESP will give you a CNAME or TXT record to publish at a path like selector._domainkey.subdomain.example.com. Just follow your provider’s setup instructions for the specific subdomain.

DMARC — The Exception. It DOES Inherit (Sort Of)

DMARC works differently. Your root domain’s DMARC policy automatically applies to all subdomains that don’t have their own DMARC record. So if example.com has p=reject, then mail.example.com and support.example.com both inherit that policy.

But here’s the nuance: if you want a different policy for a specific subdomain — say, p=quarantine on your marketing subdomain while the root is p=reject — you can publish a subdomain-specific DMARC record using the sp (subdomain policy) tag, or a dedicated record for that subdomain:

Locking Down Unused Subdomains with Null MX

Got subdomains that’ll never send or receive email? You should explicitly tell the world that. Without any MX record, sending mail servers will try falling back to the subdomain’s A or AAAA record — and if that exists (pointing to your web server, a CDN, whatever), you might start getting spam delivered to port 25 on that server, or just endless timeouts.

The fix is RFC 7505 Null MX — a standardized way to say „nope, we don’t do email here“:

That 0 . (priority zero, dot as the exchange) tells MTAs to immediately return a 554 error rather than attempting A/AAAA fallback. Clean, unambiguous, and it reduces your attack surface for phishing since the subdomain can’t be used as a convincing email source.

Heads up: Cloudflare has historically had issues supporting RFC 7505 null MX syntax. If you’re on Cloudflare and can’t add a null MX, use SPF with -all (hard fail) and a DMARC p=reject policy as an alternative hardening approach.

The CNAME Trap: Why Your MX Record Might Silently Break

This one’s a DNS rule that bites people constantly: a hostname with a CNAME record cannot have any other DNS records. MX, TXT, A — none of them. The CNAME wins and everything else is ignored.

The scenario that trips people up: you’ve got send.example.com set up as a CNAME for your ESP’s sending verification (e.g., Sendgrid or Brevo often use CNAMEs for domain validation). Then you try to add an MX record for send.example.com to handle bounce processing. It won’t work — the CNAME blocks it.

The solution: use a different subdomain for the MX record. If send.example.com is your CNAME target, put your MX record on mail.example.com or inbound.example.com instead.

A Word on Wildcard MX Records

DNS supports wildcard records using * as the subdomain label. In theory, *.example.com MX 10 mail.example.com would catch all subdomains. In practice, wildcard MX records are tricky:

• They only apply to hostnames that have no other DNS records. If staging.example.com already has an A record, the wildcard MX won’t apply to it.
• They don’t match the root domain (example.com).
• They don’t match nested subdomains (sub.sub.example.com).
• They can create deliverability chaos if misconfigured.

Unless you have a very specific reason to use wildcard MX (like wanting any @*.example.com address to work), stick to explicit MX records on specific subdomains.

Testing Your MX Records

Before you call it done, verify your work. Here are the tools you need.

dig (Linux/macOS)

dig is the gold standard for DNS queries from the command line:

You should see your mail server hostname with its priority number. If you get an empty answer section, there’s no MX record yet (or it hasn’t propagated).

nslookup (Windows/Linux/macOS)

Online Tools

• MxToolbox — the go-to for MX lookups, blacklist checks, and email header analysis
• whatsmydns.net — check propagation across global DNS servers
• dnschecker.org — similar propagation checker with good geographic coverage
• nslookup.io — clean web-based MX lookup

Quick Reference: Full Subdomain Email Setup Checklist

Here’s the complete picture when setting up email on a subdomain from scratch:

Record Type	What It Does	Inherits from Root?	Required?
MX	Routes incoming email to your mail server	No	Yes (to receive mail)
SPF (TXT)	Authorizes sending servers for the subdomain	No	Yes (to send mail)
DKIM (TXT/CNAME)	Cryptographic sending signature	No	Yes (to send mail)
DMARC (TXT)	Policy enforcement for SPF/DKIM failures	Yes (from root domain)	Optional per-subdomain override
Null MX	Explicitly blocks email delivery	No	Yes (for non-email subdomains)

FAQ