Creating a subdomain in GoDaddy is a DNS change, not a hosting change - you're adding records under your existing domain, and for email purposes those records need to point at your email platform, not at a web server.
Why use a subdomain for sending at all
If a sending subdomain's reputation takes a hit - complaints climb, a batch of addresses bounces hard - it is isolated from your root domain and your other subdomains, because mailbox providers track reputation per sending domain. A company's notifications@mail.example.com having a bad week doesn't drag down billing@example.com or the corporate site's reputation, provided they're on genuinely separate subdomains with separate authentication.
Creating the subdomain in GoDaddy
- Log into GoDaddy and go to My Products > Domains, then select the domain and open DNS > Manage Zones.
- Click Add New Record.
- For a subdomain that will send email through a third-party platform (an ESP, cold email tool, or your own mail server), you typically need:
- A CNAME or A record for the subdomain itself if the platform requires it to resolve (many transactional platforms ask for a CNAME pointing at a platform-provided hostname for domain verification).
- A separate TXT record at
mail._domainkey.mail.yourdomain.com(or whatever selector your platform specifies) for DKIM. - An SPF TXT record at the subdomain itself - SPF does not inherit from the root domain, so
mail.yourdomain.comneeds its ownv=spf1 include:... ~allrecord even if the root domain already has one. - Save the record. GoDaddy's DNS changes typically propagate within minutes but can take up to 24-48 hours globally, so verify from your sending platform's side before assuming a failed check means a misconfiguration.
- If the subdomain will also be reachable over HTTPS for any reason (a tracking domain, for instance), add SSL separately - DNS creation alone doesn't provision a certificate.
Checking it worked
Use dig TXT mail.yourdomain.com or an online DNS lookup tool to confirm the SPF and DKIM TXT records resolve publicly before sending any real mail through the new subdomain. A record that looks correct in GoDaddy's dashboard but hasn't finished propagating will fail every authentication check until it does.
What not to do
- Don't assume SPF or DMARC inherit automatically from the root domain to the subdomain - SPF never does, and DMARC's subdomain policy (
sp=) needs to be set explicitly if you want different enforcement than the root. - Don't start sending volume through the new subdomain immediately after DNS propagates - it still has zero sending history and needs its own warm-up period, same as a brand-new domain would.
- Don't reuse the exact same subdomain across unrelated sending purposes (marketing and transactional, for instance) if you want their reputations to stay independent - that defeats the isolation a subdomain is meant to provide.
Example records for a sending subdomain
For a subdomain mail.example.com sending through a typical third-party platform, the DNS records in GoDaddy's zone editor usually look close to this:
Type: TXT Host: mail Value: v=spf1 include:platform-spf.example-esp.com ~all Type: TXT Host: s1._domainkey.mail Value: v=DKIM1; k=rsa; p=MIGfMA0GCSq... Type: CNAME Host: mail Value: verify.example-esp.com
The exact selector (s1 above), host values, and whether a CNAME is required at all depend entirely on which platform you're pointing the subdomain at - always use the exact values your sending platform's domain-verification page gives you rather than guessing at a generic pattern.
Checking propagation status before trusting a failed check
| Check source | What it tells you |
|---|---|
| GoDaddy's own DNS management page | Whether the record saved correctly on GoDaddy's side |
| A public DNS lookup tool, queried from outside your network | Whether the record has actually propagated to public resolvers |
| Your sending platform's "verify domain" button | Whether that platform's specific resolver sees the record yet |
A record that looks correct in GoDaddy but fails your sending platform's verification within the first hour is very likely a propagation delay, not a misconfiguration - wait and recheck before changing anything.
Benefits of using subdomains that go beyond email specifically
Subdomains are useful for more than isolating sending reputation - they let a business run a staging environment, a support portal, or a regional site under the same root domain without any of those services' DNS or hosting choices affecting the others. For email specifically, this same isolation principle is what protects a root domain's reputation from a subdomain's sending mistakes, but the underlying DNS mechanism (a new entry in the zone file, its own records) is identical whether the subdomain is used for email, a web app, or anything else pointed at it.
Once a sending subdomain is live, MailPilot can warm it against a real seed-inbox network and track its SPF, DKIM, DMARC status and per-mailbox reputation separately from your root domain, so you see the new subdomain's standing on its own.
Ready to reach the inbox every time?
Automated email warmup across real peer mailboxes. Live inbox placement monitoring. Free 7-day trial - no credit card required.
Start free trial