Why MailerToGo sends from mtg.yourdomain.com

When you connect a workspace, MailerToGo pre-adds mtg.yourdomain.com as your first sending domain — a subdomain of the domain you already own, not your root domain and not a brand-new one. That default is deliberate. It gives you the best deliverability, keeps your existing email untouched, and lets us do almost all of the DNS work for you. Here’s the reasoning, and how to change it if your setup calls for something else.

Your recipients still see your root domain. Sending from mtg.yourdomain.com changes nothing in the inbox — the From: address your customers see stays you@yourdomain.com. The subdomain only does its work at the authentication layer that inbox providers inspect. For the full mechanics (envelope-from vs. From:, SPF/DKIM/DMARC), see the deep dive: Why you should use a subdomain for sending email.

Why a subdomain, not your root domain

Your root domain’s reputation stays isolated. Deliverability is a reputation game, and reputation attaches to the sending domain. Put your app’s transactional mail on mtg.yourdomain.com and any rough patch — a bad batch, a spike in complaints — is contained to that subdomain. It can never taint yourdomain.com or your team’s day-to-day email.

Zero conflict with your existing mail. If you run Google Workspace or Microsoft 365, your root domain already has MX, SPF, and DMARC records that make corporate email work. Adding an app sender to that same root SPF record is risky: SPF has a hard limit of 10 DNS lookups, and piling every provider into one record can blow past it and break authentication for everything. A dedicated subdomain gets its own SPF, DKIM, and DMARC alignment, so your Workspace/365 setup is never touched and never at risk.

It’s how the big senders do it. GitHub, Stripe, and AWS all send transactional mail from subdomains for exactly these reasons.

Quick Setup: one NS record, and we manage the rest

The reason we can pre-add mtg.yourdomain.com and have it just work is delegation. Instead of asking you to publish and maintain a handful of SPF, DKIM, and DMARC records by hand, we ask for one record that hands us a subdomain to manage:

; Delegate the mtg subdomain to MailerToGo's nameservers
mtg.yourdomain.com.   NS   ns1.mailertogo.net.
mtg.yourdomain.com.   NS   ns2.mailertogo.net.

That’s it. Once the delegation resolves, MailerToGo publishes everything the subdomain needs and keeps it current automatically:

• We create and publish your SPF, DKIM, and DMARC records.
• We auto-rotate DKIM keys on a schedule and re-publish them for you.
• If our sending IPs or keys ever change, the records update themselves — no action from you.

Delegation stays scoped to the subdomain only. Your root domain and every other name under it are untouched — we can only see and manage records at mtg.yourdomain.com. No more DNS tickets, ever.

Instantly revocable

Because the whole thing hangs off a single NS record, you stay in control. Delete the NS record and the delegation is gone — instantly, and entirely on your side. There’s no support request and no waiting: pull the record and MailerToGo can no longer manage or send from that subdomain. Control of your DNS never leaves your hands.

When the root or another subdomain makes sense (Advanced setup)

Quick Setup fits most people, but not everyone can (or wants to) delegate a subdomain:

• You need to manage the records yourself — for change control, or because your DNS is centrally governed.
• You want a different label — email.yourdomain.com or notifications.yourdomain.com work exactly as well; the specific name doesn’t affect deliverability.
• You’re separating streams — e.g. mtg.yourdomain.com for transactional mail and news.yourdomain.com for marketing, so a marketing complaint spike never touches your receipts and password resets.

In any of these cases, use Advanced setup: add the subdomain (or, if you truly must, the root — as long as it isn’t already a CNAME) as a sending domain in the dashboard, and publish the exact SPF/DKIM/DMARC records it shows you by hand. The step-by-step records, application config, and verification checks are covered in Why you should use a subdomain for sending email, and the general deliverability case is in Subdomain emails: should I use a subdomain to send email?.

The short version

We pre-add mtg.yourdomain.com because a sending subdomain protects your root domain’s reputation, stays clear of your existing corporate email, and — via a single delegated NS record — lets us publish and auto-maintain every authentication record for you. Your customers still see your brand; you get better deliverability; and you can revoke the whole thing anytime by deleting one DNS record.