← Blog

Why You Should Use a Subdomain for Sending Email

by Mailer To Go
Your root domain is often a CNAME to your host — and a CNAME can't carry SPF. Sending from a subdomain fixes deliverability, keeps DMARC aligned, and protects your domain reputation.

Send your email from a subdomain like mail.yourdomain.com or notifications.yourdomain.com — not from your root domain, and not from any hostname that is already a CNAME. This one decision avoids a DNS dead-end that quietly wrecks deliverability, and it gives you a cleaner, safer sending setup. Here is why, and how to do it.

Understanding the problem

Why can’t I use my root domain if it’s a CNAME?

Lots of hosting providers (Heroku, Build.io, Cloudflare, Netlify, and friends) ask you to point your domain at them with a CNAME record so they can terminate SSL and route traffic. That works great for your website. But it creates a hard conflict for email.

DNS has a rule, defined in RFC 1034 §3.6.2: if a name has a CNAME record, it can have no other records of any other type. A CNAME means “this name is just an alias for that other name — go look there for everything.” There is no room left for the TXT record that holds your SPF policy, or for MX records, at that same name.

So if yourdomain.com is a CNAME pointing at your host, you literally cannot add SPF to it. The DNS won’t allow it.

What is the CNAME conflict, and why does DNS work this way?

A CNAME is a redirect at the DNS layer. When a resolver looks up yourdomain.com and finds a CNAME, it abandons the original name and chases the target. Allowing other records alongside a CNAME would be ambiguous — which answer wins? The spec resolves the ambiguity by forbidding the combination outright. It’s not a provider limitation; it’s how DNS is defined.

My site works fine at my domain — why would email be different?

Web traffic only needs the CNAME: a browser asks “where is yourdomain.com?”, follows the alias, and connects. Email needs additional records at the domain — SPF (a TXT record) and often DKIM and a DMARC policy — so receiving servers can verify the mail is authorized. The CNAME that makes your website work is exactly what blocks those records. Same name, different requirements.

What actually breaks if I send without SPF?

SPF is one of the main signals inbox providers use to decide you are who you say you are. With no SPF record:

The mail might still send, but a meaningful slice of it won’t arrive.

The subdomain solution

What subdomain should I use? Does the name matter?

Use a dedicated subdomain such as mail.yourdomain.com, email.yourdomain.com, or notifications.yourdomain.com. The exact label doesn’t affect deliverability — pick something clear. What matters is that it’s a name you control directly (not itself a CNAME to a third party), so you can add SPF, DKIM, and the sending records it needs.

If I send from mail.example.com, will recipients see that instead of example.com?

Almost certainly not — and this is the point that trips people up. There are two different “from” addresses on every email:

So you can send through mail.example.com (envelope-from) while your recipients see hello@example.com or Acme Support <support@example.com> in the From: line. The subdomain does its authentication job behind the scenes; your brand address stays on display.

Will replies go to the subdomain or my real address?

Replies follow the From: header (or an explicit Reply-To: you set) — not the envelope-from. Set From: or Reply-To: to your real, monitored mailbox (e.g. support@example.com) and replies land there as expected. The subdomain never has to receive mail.

Does using a subdomain affect my domain reputation?

Yes — in your favor. Sending from a subdomain isolates the reputation of your transactional/marketing mail from your root domain. If a campaign ever has a rough patch, it’s contained to mail.example.com rather than dragging down example.com (and your employees’ day-to-day email). Reputation isolation is a feature, not a side effect.

Can I use the same subdomain for transactional and marketing email?

You can, but it’s usually better to separate them — e.g. mail.example.com for transactional (receipts, password resets) and news.example.com for marketing. Transactional mail is high-trust and low-complaint; marketing mail naturally draws more complaints and unsubscribes. Splitting them keeps your critical receipts and resets insulated from marketing reputation swings.

Setting it up

How do I configure MailerToGo to use a subdomain?

Add the subdomain (not your root domain) as your sending domain in the MailerToGo dashboard, then publish the DNS records it gives you. MailerToGo will show the exact records for your subdomain.

What DNS records do I need?

At the subdomain you’ll add SPF and DKIM (and we recommend a DMARC policy at the root). A typical set looks like:

; SPF — authorizes MailerToGo to send for the subdomain
mail.yourdomain.com.   TXT    "v=spf1 include:mailertogo.com ~all"

; DKIM — published exactly as MailerToGo provides it
mtg._domainkey.mail.yourdomain.com.   CNAME   mtg.dkim.mailertogo.com.

; DMARC — a policy at the organizational domain
_dmarc.yourdomain.com.   TXT    "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

Use the precise values from your dashboard — the SPF include: and DKIM target are specific to your account.

Do I need to change anything in my application code?

Usually just one thing: point your mailer’s SMTP host (or API endpoint) at MailerToGo, using the credentials for the subdomain. Your From: address can stay as your normal brand address. For example, with Rails:

# config/environments/production.rb
config.action_mailer.smtp_settings = {
  address:         ENV["MAILERTOGO_SMTP_HOST"],
  port:            587,
  user_name:       ENV["MAILERTOGO_SMTP_USER"],
  password:        ENV["MAILERTOGO_SMTP_PASSWORD"],
  authentication:  :plain,
  enable_starttls: true
}
# From: can still be "support@yourdomain.com" — only the sending path changes.

How do I verify the subdomain is working?

Advanced and trust signals

Does DMARC alignment work with a subdomain?

Yes. DMARC supports organizational alignment by default: a message sent from mail.example.com aligns with a DMARC policy published at example.com, because they share the same organizational domain. You publish DMARC once at the root and your subdomain inherits alignment — no separate policy needed.

Does DKIM sign with the subdomain or the root domain?

DKIM signs with whatever domain you publish the key under — here, the subdomain (mail.yourdomain.com). That’s exactly what you want: the DKIM signature, the envelope-from, and the subdomain all line up, and that combination aligns with your root DMARC policy.

I already have SPF on my root for Google Workspace / Microsoft 365 — do I still need a subdomain?

Yes, and the subdomain keeps things clean. SPF has a hard limit of 10 DNS lookups; piling every sender (Google, Microsoft, your ESP, MailerToGo) into one root SPF record risks blowing past it and breaking SPF for everything. Sending bulk and transactional mail from a subdomain with its own SPF record sidesteps the limit and keeps your corporate mail (Google/Microsoft) and your app mail independent.

The short version

Use a subdomain for sending. It’s how the big senders do it — GitHub, Stripe, and AWS all send transactional mail from subdomains — because it sidesteps the CNAME conflict, keeps SPF/DKIM/DMARC clean, and protects your root domain’s reputation. Your recipients still see your real address; the subdomain just does the authentication work behind the scenes.