What is the step by step process to setup a subdomain in Godaddy for email?
Updated on 19 Oct 2026: We added subdomain mailbox setup steps and clarified DNS placement and DMARC verification.
To set up a subdomain in GoDaddy for email, create the subdomain by adding DNS records inside the parent domain's authoritative DNS zone. Then add the exact SPF, DKIM, bounce, and tracking records supplied by the email service provider, plus the DMARC policy and reporting record chosen for the subdomain. GoDaddy is where the records are saved only when its nameservers host the active DNS zone. The email service provider is the source of its required record names and values.
The important part is that a sending subdomain usually is not created as a separate website or hosting account. For email, the subdomain exists because DNS records exist for it. An A record is only needed when the provider gives you an IP address for a tracking host or another web-facing host. For DKIM, bounce handling, and tracking, CNAME records are common. For SPF and DMARC, TXT records are common.
- Get ESP values: Copy the exact host names, record types, and target values from your provider's setup screen or documentation.
- Choose one name: Use a clean sending subdomain such as send, mail, news, or em, then keep it dedicated to that mail stream.
- Add records: In GoDaddy DNS, create each TXT, CNAME, MX, or A record exactly as instructed, using the subdomain in the Host field.
- Verify mail: Wait for DNS to resolve, then send a real test message and check SPF, DKIM, DMARC, and return-path domain matching.
What you need before opening GoDaddy
Start in the email platform because DNS providers do not know what DKIM selector, CNAME target, SPF include, bounce host, or tracking host your provider expects. Add send.example.com as a sending domain or custom domain in the provider's account, then complete any ownership verification it requests. Copy the records generated for that exact subdomain.
|
|
|
|
|---|---|---|---|
SPF | TXT | Return-path host | Authorizes sending servers for the SMTP MAIL FROM domain. |
DKIM | CNAME or TXT | selector._domainkey.send | Publishes the signing key or key pointer. |
DMARC | TXT | _dmarc.send | Sets policy and reporting for the visible From domain. |
Bounce | CNAME, MX, or TXT | bounce.send | Controls return-path and bounce processing. |
Tracking | CNAME or A | click.send | Brands click and open tracking hosts. |
MX | MX | send | Needed only when a mail service accepts messages or bounces for the subdomain. |
Common DNS records for a sending subdomain
Do not guess the records
- Provider values: DKIM keys, CNAME targets, bounce hosts, and tracking hosts come from the email platform.
- GoDaddy placement: The Host or Name field decides whether the record applies to the parent domain or the subdomain.
- A record limits: An A record points a host to an IP address. An A record alone does not publish SPF or DKIM records.
Confirm GoDaddy controls the DNS zone
A domain registered at GoDaddy can use nameservers operated somewhere else. Check the parent domain's nameservers before adding records. If GoDaddy is not authoritative, changes in its DNS manager will not appear in public DNS. If the subdomain has its own NS delegation, add its records at the DNS host named by that delegation.
- Check nameservers: Compare the active nameservers with the DNS provider that currently hosts the zone.
- Use the active zone: Add the email records in GoDaddy only when the domain uses GoDaddy nameservers.
- Keep delegation stable: If another provider is authoritative, add the records there instead of changing nameservers for this task.
- Protect existing mail: Do not delete or replace existing MX, SPF, DKIM, or DMARC records unless the email provider's instructions require it.
Step-by-step GoDaddy email subdomain setup
The GoDaddy part is mechanical once the provider has given you the records and you have confirmed that GoDaddy hosts the active DNS zone. Use the parent domain's DNS page and add records with host names such as send, selector._domainkey.send, bounce.send, or click.send. GoDaddy automatically appends the parent domain behind the scenes.
GoDaddy DNS management screen for adding a subdomain record.
- Sign in: Open your GoDaddy account and go to the Domain Portfolio.
- Pick domain: Select the parent domain, such as example.com, to open its Domain Settings page.
- Open DNS: Select DNS to view and edit the zone records.
- Add record: Select Add New Record, then choose the type the provider gave you.
- Enter host: Put only the host part in the Name field, such as send or selector._domainkey.send.
- Enter value: Paste the provider's target, TXT value, IP address, or mail server exactly.
- Set TTL: Use the default one hour unless your provider gives a specific TTL.
- Save changes: Select Save, or Save All Records after adding several records, and complete any required identity verification.
- Wait for DNS: Most changes take effect within an hour, but allow up to 48 hours for caches to update globally.
- Run checks: Check DNS, run the email provider's Verify or Recheck DNS action, then send a real email test before moving production traffic.
GoDaddy's own help page explains the key DNS split: an A record points a subdomain to an IP address, and a CNAME connects it to another host name. The GoDaddy subdomain guide is useful for the DNS screen, but the email-specific values still come from your provider.
Set up a subdomain mailbox to receive email
To receive messages at info@send.example.com, the email provider must accept mail for send.example.com and have that mailbox or alias configured. Adding authentication records does not create an inbox. Confirm that your email plan supports subdomain addresses before changing DNS.
- Add the address: Register send.example.com in the receiving provider's account, verify ownership, and create the mailbox or alias.
- Publish MX records: In the example.com DNS zone, select Add New Record, choose MX, and set Name to send. Copy each mail-server hostname and Priority value from the provider. A lower priority number is preferred.
- Keep parent mail working: Leave MX records at @ in place. They handle addresses at example.com; records at send handle addresses at send.example.com. Parent MX records are not inherited by the subdomain.
- Test incoming mail: Complete provider verification, then send a message to the new address from an outside account. Confirm delivery and test a reply.
A custom return-path or bounce subdomain usually handles delivery errors for the sending provider. It does not automatically accept customer replies. Use a working From or Reply-To mailbox for replies.
Example records for a sending subdomain
This example uses send.example.com as the visible sending subdomain. Do not copy these values into production. They show where each class of record normally lives, but the SPF host must match the SMTP MAIL FROM or return-path domain used by your provider.
Example DNS records for send.example.comdns
# Example only. Use the exact values from your ESP. # Publish SPF at send only if send.example.com is the MAIL FROM domain. send TXT v=spf1 include:esp.example -all s1._domainkey.send CNAME s1.dkim.esp.example s2._domainkey.send CNAME s2.dkim.esp.example _dmarc.send TXT v=DMARC1; p=none; rua=mailto:dmarc@example.com bounce.send CNAME bounce.esp.example click.send CNAME tracking.esp.example
Read the host names literally
If the DKIM host is selector._domainkey.send.example.com, the GoDaddy Name field usually gets selector._domainkey.send because the zone already belongs to example.com. If you paste the full name and GoDaddy also appends the parent domain, you create the wrong record.
If the provider uses bounce.send.example.com as the MAIL FROM domain, SPF is checked there instead of at send.example.com. When that host is a CNAME, follow the provider's CNAME setup and do not add a conflicting SPF TXT record at the same host.
GoDaddy DNS Name field: @ and subdomain hosts
When the provider's setup screen is scoped to send.example.com, its @ means send in GoDaddy's example.com zone. Its _dmarc means _dmarc.send, and selector._domainkey means selector._domainkey.send. In GoDaddy's parent zone, @ still means example.com. Check which domain the provider's instructions describe before translating the Name field.
Parent zone
- Zone file: Stay inside the DNS zone for example.com when adding records for send.example.com.
- Host field: Use send for the subdomain itself and deeper labels for DKIM, bounce, and tracking.
- No new zone: Do not create a separate DNS zone for the subdomain unless your DNS architecture requires delegation.
Email records
- SPF host: Add the TXT record at the SMTP MAIL FROM domain when the provider tells you to publish SPF directly. SPF is not inherited from the parent domain.
- DKIM host: Add the selector record below the subdomain when the provider signs with that subdomain in the d= value.
- DMARC host: Add _dmarc under the subdomain when you need an explicit policy that overrides inherited policy.
Flowchart showing how provider DNS records map into a GoDaddy parent zone.
How to verify the setup
After saving the records, verify in two layers. First, check DNS to confirm the records exist at the right host names. Second, send a real message through the provider and inspect the receiving server's Authentication-Results header for spf=pass, dkim=pass, and dmarc=pass.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Start with a domain health check to catch obvious DNS problems across SPF, DKIM, and DMARC. Then send one real campaign or test message through the email tester and confirm that the visible From domain, DKIM d= domain, SPF return-path domain, and DMARC result match the setup you intended.
A DNS lookup alone does not prove that mail is signing correctly. DKIM can exist in DNS and still fail if the provider signs with a different selector or domain. DMARC needs either SPF or DKIM to pass with the required domain match to the visible From domain. Relaxed alignment uses the same organizational domain; strict alignment requires an exact domain match. The real message test catches these mismatches. Passing authentication does not guarantee inbox placement.
Domain health checker sample results showing DMARC, SPF, DKIM scorecards and detailed validation checks
Suped's domain health checker and email tester help review the DNS configuration and authentication results together. Use Suped's DMARC reporting platform to investigate failing senders after receivers return reports.
DMARC policy and ongoing monitoring
For a new sending subdomain without inherited enforcement, use p=none when you need reports before enforcement. Move to quarantine and then reject after legitimate traffic passes DMARC through SPF or DKIM with the required domain match. Before publishing an explicit subdomain record, check the organizational domain's DMARC policy. For an existing send.example.com without its own record, example.com's sp policy applies when present; otherwise its p policy applies. An explicit _dmarc record on the sending subdomain overrides that inherited policy, so adding p=none can weaken existing protection.
Starter DMARC record for the subdomaindns
_dmarc.send TXT v=DMARC1; p=none; rua=mailto:dmarc@example.com
For deeper subdomains, RFC 9989 uses a DNS tree walk to discover the applicable organizational-domain policy. Replace dmarc@example.com with a working report mailbox or the reporting address supplied by Suped. Under RFC 9990, an external reporting destination needs authorization in the destination's DNS. Aggregate reports usually arrive daily, so they do not provide immediate per-message alerts.
DMARC policy rollout
A practical enforcement path for a new email subdomain.
Monitor
p=none
Collect reports and find unauthenticated senders.
Restrict
p=quarantine
Ask receivers to quarantine failing mail.
Enforce
p=reject
Ask receivers to reject failing mail.
Use DMARC monitoring in Suped's platform to identify the subdomain's legitimate sending services and investigate SPF or DKIM failures before changing policy. Continue reviewing reports after enforcement to catch new senders or broken authentication.
Common mistakes to avoid
Most failed GoDaddy email subdomain setups come down to placement errors. The record type is often right, but the host name is one label too high, one label too low, or duplicated with the parent domain.
Mistakes that break authentication
- Wrong DKIM host: Publishing the key at a selector or domain that does not match the message's DKIM signature causes DKIM to fail.
- Guessed IP: Adding an A record that points to a sending IP does not create SPF, DKIM, or DMARC authentication.
- Duplicate SPF: Multiple SPF TXT records at the same host cause permanent SPF errors.
- SPF lookup limit: Keep SPF evaluation within 10 DNS-lookup-causing mechanisms and modifiers, counting nested includes. Exceeding that limit returns permerror.
- No alignment: SPF and DKIM can pass, but DMARC still fails when neither passing domain meets the required match to the visible From domain.
- CNAME conflict: A CNAME cannot share the same host name with TXT, MX, or other record data, so check existing records before adding it.
- Untested bounce: A custom return-path that is not verified can break bounce processing and SPF alignment.
A misplaced new TXT or CNAME often fails provider validation without affecting the parent domain. Changing existing MX, SPF, DMARC, or nameserver records can interrupt legitimate mail or change policy. Correct the exact host or value, leave unrelated records in place, and test again after DNS updates.
Views from the trenches
Best practices
Treat the email platform as the source of truth for record names and target values.
Create records in the active parent zone, then use the Host field to place the subdomain.
Verify with a sent message because DNS can look correct while signing still fails.
Common pitfalls
Do not convert every provider instruction into an A record for the sending IP address.
Avoid pasting the full domain when GoDaddy already appends the parent zone name for you.
Do not add multiple SPF TXT records at the same host because SPF checks will fail.
Expert tips
Use CNAME records for DKIM when the provider wants to rotate keys on its side cleanly.
Keep a dedicated subdomain for each major mail stream so diagnosis stays clean later.
Check inherited DMARC policy before using p=none, then enforce after legitimate mail passes.
Marketer view
Marketer from Email Geeks says the ESP provides the required values, while GoDaddy controls placement only when it hosts the active DNS zone.
2021-12-27 - Email Geeks
Marketer view
Marketer from Email Geeks says DKIM for a subdomain often uses a CNAME, so a TXT record is not always the correct choice.
2021-12-30 - Email Geeks
GoDaddy email subdomain checklist
The step-by-step process is: choose the sending subdomain, collect the exact records from the email provider, confirm where the authoritative DNS zone is hosted, open the parent domain in GoDaddy DNS when GoDaddy is authoritative, add each record with the right Host value, save, wait for DNS to resolve, then test a real email. Do not default to an A record unless the provider gives an IP address for a host that needs one.
For a normal sending setup, expect TXT for SPF, CNAME or TXT for DKIM, TXT for DMARC, CNAME or MX records for bounce handling, and CNAME or A records for tracking depending on the provider. Once mail is live, keep DMARC reporting on and watch for new senders, broken selectors, SPF lookup failures, and blocklist or blacklist changes that affect reputation.
Frequently asked questions
For email DNS, usually no. You create the subdomain by adding DNS records in the parent domain's authoritative zone, such as send, _dmarc.send, or selector._domainkey.send.
Only when the provider gives an IP address for a host that needs one, such as a tracking host. SPF, DKIM, and DMARC are not created with an A record.
Put DKIM at the selector host the provider gives you. For a sending subdomain, that often looks like selector._domainkey.send inside the parent domain's DNS zone.
Yes. For an existing send.example.com without its own DMARC record, example.com's sp policy applies when present; otherwise its p policy applies. RFC 9989 uses a DNS tree walk to discover policy for domains without their own record. An explicit _dmarc.send.example.com record takes precedence for that From domain.
Most changes take effect within an hour, but GoDaddy advises allowing up to 48 hours for global DNS caches to update. Test the exact host names before sending production mail.
No. Add the subdomain to the receiving provider's account and create a mailbox or alias there. Then publish its MX records at the subdomain host in GoDaddy, leave parent-domain MX records in place, and test incoming mail and replies.
