Why You Should Use a Subdomain for Sending Email

by Mailer To Go

Worried a sending subdomain means your mail looks like it's from a different domain? It doesn't — recipients still see your root domain, and deliverability improves. Here's why, and how to set up mtg.yourdomain.com.

Send your transactional email from a subdomain like mtg.yourdomain.com — not from your root domain, and not from any hostname that is already a CNAME. It is a small DNS change, and it meaningfully improves deliverability.

“But won’t my email look like it’s coming from a different domain?”

This is the first thing everyone worries about, so let’s settle it up front: no, it won’t. Using a subdomain to send changes nothing about what your recipients see. The From: address in their inbox is still you@yourdomain.com — your root domain, your brand, exactly as it is today.

The subdomain does its work behind the scenes, at the authentication layer that inbox providers (not humans) inspect. What actually changes is that your mail starts passing SPF, DKIM, and DMARC cleanly, so more of it reaches the inbox instead of the spam folder. So the trade is simple: nothing visible changes for your customers, and more of your mail actually gets to them.

In short — your recipients still see your root domain, and your delivery gets better. That’s the whole story; the rest of this article is just the why and the how.

(The technical version: the subdomain is your envelope-from / Return-Path, which is the domain SPF checks. The From: header your recipient sees is set by your application and stays your root domain. More on that below.)

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:

Mailbox providers (Gmail, Outlook, Yahoo) are far more likely to send your mail to spam — or reject it.
You can’t pass DMARC, which increasingly gates the inbox.
Your messages look like the unauthenticated mail that spammers send.

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?

We recommend mtg.yourdomain.com. The exact label doesn’t affect deliverability — email. or notifications. would work too — but mtg.yourdomain.com is clear, easy to remember, and keeps your MailerToGo sending neatly namespaced. What matters is that it’s a name you control directly (not itself a CNAME to a third party), so you can add the SPF, DKIM, and sending records it needs.

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

No — and this is the worry we answered at the top, now with the mechanism. There are two different “from” addresses on every email:

Envelope-from (also called MAIL FROM or Return-Path): the address the sending infrastructure uses. This is the domain SPF checks, and it’s where your subdomain lives.
Header From:: the address the recipient actually sees in their inbox. This is set by your application, independently of the sending domain.

So you send through mtg.example.com (envelope-from) while your recipients see hello@example.com or Acme Support <support@example.com> in the From: line. The subdomain authenticates; 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 mtg.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. mtg.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
mtg.yourdomain.com.   TXT   "v=spf1 include:_spf.mailertogo.net ~all"

; MX — routes the subdomain's bounces/return-path to MailerToGo
mtg.yourdomain.com.   MX    10 smtp.us-west-1.mailertogo.net.

; DKIM + DMARC — publish the exact records shown in your MailerToGo dashboard
; (DKIM is a CNAME with a per-account selector; a subdomain DMARC policy is
;  provisioned for you, e.g. p=reject)

Use the precise values from your dashboard — the DKIM selector and SMTP region (smtp.<region>.mailertogo.net) are specific to your account.

Do I need to change anything in my application code?

Two small things. First, point your mailer at MailerToGo using the subdomain’s credentials. With Rails:

# config/environments/production.rb
config.action_mailer.delivery_method = :smtp
config.action_mailer.smtp_settings = {
  address:         ENV["MAILERTOGO_SMTP_HOST"],   # smtp.<region>.mailertogo.net
  port:            ENV.fetch("MAILERTOGO_SMTP_PORT", 587).to_i,
  user_name:       ENV["MAILERTOGO_SMTP_USER"],
  password:        ENV["MAILERTOGO_SMTP_PASSWORD"],
  authentication:  :plain,
  enable_starttls: true   # enforce TLS on port 587
}

Second — and this is the part that makes the subdomain work — set the envelope-from (return_path) to the subdomain while keeping the From: and Reply-To: your recipients see and reply to on your root domain:

class NotifierMailer < ApplicationMailer
  def welcome(user)
    mail(
      to:          user.email,
      from:        "Acme <hello@yourdomain.com>",   # what recipients see
      reply_to:    "support@yourdomain.com",        # where replies go
      return_path: "bounces@mtg.yourdomain.com"     # envelope-from: what SPF checks
    )
  end
end

Rails (via the Mail gem) uses return_path as the envelope-from, so SPF is validated against mtg.yourdomain.com — where your SPF record lives — while the From:/Reply-To stay on yourdomain.com. Same brand to your recipients, aligned DMARC, better deliverability.

How do I verify the subdomain is working?

Confirm the records resolve: dig TXT mtg.yourdomain.com (SPF), dig MX mtg.yourdomain.com, and the DKIM CNAME from your dashboard.
Send a test message to a Gmail account, open Show original, and check that SPF and DKIM both show PASS and that DMARC shows alignment.
Watch the domain status in the MailerToGo dashboard flip to verified.

Advanced and trust signals

Does DMARC alignment work with a subdomain?

Yes. DMARC supports organizational alignment by default: a message sent from mtg.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 (mtg.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 your app 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 like mtg.yourdomain.com for sending. Your recipients still see your root-domain address — nothing visible to them changes — and your deliverability goes up. It’s how the big senders do it (GitHub, Stripe, and AWS all send transactional mail from subdomains): it sidesteps the CNAME conflict, keeps SPF/DKIM/DMARC clean, and protects your root domain’s reputation.