How to set up email subdomains and what DNS records are required?
Michael Ko
Co-founder & CEO, Suped
Published 31 May 2025
Updated 15 May 2026
9 min read
Summarize with
To set up an email subdomain, create the subdomain in your DNS zone, then add the records your sending platform requires. For most sending subdomains, the required records are SPF, DKIM, DMARC, and one or more CNAME records for tracking or provider verification. Add MX only when the subdomain receives mail, handles bounces, or the provider asks for it. Add an A record only when something on that subdomain needs to resolve to a web server or IP address. An A record pointing at a sending IP is not what makes outbound email authenticate.
The shortest practical answer is this: choose a subdomain such as mail.example.com, publish the provider's DNS records exactly as supplied, verify SPF and DKIM pass for that subdomain, add DMARC reporting, then send a real test message and inspect the headers. I do not treat the subdomain as finished until the visible From domain, return-path domain, and DKIM signing domain have been checked together.
- Minimum setup: SPF, DKIM, and DMARC for the sending identity.
- Common provider setup: CNAME records for DKIM, link tracking, click tracking, open tracking, and verification.
- Only when needed: MX for inbound mail or bounces, A for hosted pages or custom tracking hosts.
The records you usually need
The exact DNS set depends on whether the subdomain only sends mail, receives mail too, or exists mainly as a branded provider hostname. A newsletter subdomain, a transactional subdomain, and a bounce subdomain can all need different records. The right method is to decide the job of the subdomain first, then publish only the records that support that job.
|
|
|
|---|---|---|
TXT SPF | Outbound mail | Authorizes sending hosts for the envelope sender. |
TXT DKIM | Outbound mail | Publishes public keys for message signatures. |
TXT DMARC | Policy or reporting | Tells receivers how to handle failed mail. |
MX | Inbound or bounces | Routes replies, bounces, or mailboxes. |
CNAME | Provider setup | Delegates DKIM, tracking, or verification hosts. |
A or AAAA | Web host needed | Maps a host to an IP address. |
Typical DNS records for email subdomains.
Do not confuse A records with email authentication
A record can make a hostname resolve, but it does not prove that a sender is allowed to send mail for that domain. SPF, DKIM, and DMARC do that work. If someone tells you the email subdomain is ready because an A record points to a sending IP, treat that as incomplete.
The same principle applies when a DNS control panel labels everything under the parent zone. In many interfaces, adding a TXT record named mail creates the record at mail.example.com. Adding _dmarc.mail creates the DMARC record for that subdomain. The control panel layout changes, but the DNS names do not.
Five DNS record types connected to one email subdomain.
A practical setup sequence
I start with the mailstream, not the DNS screen. A subdomain should map to a clear purpose: marketing, transactional, lifecycle, billing, support, or a specific platform. That makes later troubleshooting easier because reputation, DMARC reports, complaint patterns, and authentication failures are tied to one stream instead of being mixed with every other sender.
- Name the subdomain: Use a purpose-based name such as news, mail, or notify. Avoid disposable-looking names.
- Collect provider records: Copy SPF, DKIM, CNAME, MX, and verification values from the sending platform.
- Publish DNS records: Add each value at the exact host name the provider specifies.
- Add DMARC monitoring: Use reports to confirm which systems send as the subdomain and whether SPF or DKIM aligns.
- Send and inspect: Send a real message to a mailbox and check authentication results with an email tester.
Email subdomain setup flow from naming through DMARC monitoring.
Example DNS records for a sending subdomain
These examples show the shape of a clean setup for mail.example.com. Do not paste these values into production. Your sending provider supplies the real include, DKIM selector, target hostnames, MX values, and verification strings. The important part is where each record lives and what each record is meant to prove.
SPF, DKIM, DMARC, MX, and CNAME examplesDNS
mail.example.com. TXT "v=spf1 include:send.example.net -all" selector1._domainkey.mail.example.com. CNAME selector1.example.net. selector2._domainkey.mail.example.com. CNAME selector2.example.net. _dmarc.mail.example.com. TXT "v=DMARC1; p=none; rua=mailto:d@example.com" mail.example.com. MX 10 inbound.example.net. click.mail.example.com. CNAME tracking.example.net. verify.mail.example.com. TXT "provider-token"
For SPF, the record normally sits at the return-path or bounce domain used by the platform. Sometimes that is the same as the visible From subdomain, and sometimes it is a separate host such as bounce.example.com. SPF only helps DMARC when the authenticated SPF domain aligns with the visible From domain. That alignment detail is where many correct-looking DNS setups still fail DMARC.
For DKIM, providers usually give either TXT records containing public keys or CNAME records that point your selector to provider-managed keys. CNAME-based DKIM is common because the provider can rotate keys without asking you to change DNS again. The selector is part of the DNS name, so selector1 and selector2 are separate records.
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
After publishing records, run a broad domain health check before you send volume. That catches obvious DNS issues, missing records, syntax errors, and gaps across DMARC, SPF, and DKIM.
When the subdomain needs MX, A, or CNAME records
MX, A, and CNAME records cause the most confusion because they are not always required for sending. A subdomain can send authenticated email without an A record. A subdomain can also send without MX when replies and bounces are handled somewhere else. Providers often ask for CNAME records because they want to own a particular function, such as tracking or DKIM.
Usually required
- SPF: Needed for the envelope sender domain used by the platform.
- DKIM: Needed for signed mail and DMARC alignment.
- DMARC: Needed for reporting, policy, and spoofing protection.
Conditional
- MX: Use for replies, inbound mail, bounces, or provider routing.
- A record: Use for a web endpoint, landing page, or direct host mapping.
- CNAME: Use when a provider delegates DKIM, tracking, or verification.
There is one DNS rule that matters a lot: a CNAME cannot normally coexist with other records at the exact same hostname. If mail.example.com is a CNAME, do not also try to put SPF, MX, or DMARC records at that same name. Put CNAMEs on specific child hosts when possible, such as click.mail or selector._domainkey.mail.
If you are using a registrar walkthrough, keep that rule in mind. A step-by-step guide for GoDaddy subdomains helps with screen-by-screen mechanics, but the authentication logic stays the same across DNS hosts.
Cloudflare DNS records table for an email subdomain.
DMARC inheritance and subdomain policy
DMARC has a parent-domain inheritance model. If example.com publishes DMARC, receivers can apply that policy to mail.example.com unless the subdomain publishes its own DMARC record. The parent record can also include an sp tag that sets a specific policy for subdomains.
Parent DMARC policy with a subdomain policyDNS
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; sp=none; rua=mailto:d@ex.co"
I prefer explicit DMARC records on active sending subdomains when the mailstream matters. That gives you direct reporting and avoids surprises when the parent policy tightens. A parent policy with p=reject and no subdomain override can break a new sender if DKIM or SPF alignment is not finished.
How Suped fits the workflow
Suped's DMARC monitoring is useful once the subdomain starts sending because it shows which sources pass, which fail, and which records need attention. Hosted DMARC and hosted SPF are practical when you manage many domains or need policy staging without frequent DNS edits.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
The strongest practical setup is not just a valid DNS record. It is a verified path where the From domain matches your intended brand, DKIM aligns with that domain, SPF aligns where possible, and DMARC reports confirm the same behavior across real traffic.
How to verify the setup
DNS verification has two layers. The first layer checks whether the records exist and have valid syntax. The second layer checks whether actual mail uses those records correctly. You need both. A DKIM record can exist while the provider signs with a different selector. An SPF record can exist while the return-path uses a different domain. A DMARC record can exist while neither SPF nor DKIM aligns.
- Check DNS: Confirm each hostname resolves to the expected value after propagation.
- Send one message: Use the real platform, real From address, and a normal campaign or template.
- Inspect headers: Look for SPF pass, DKIM pass, DMARC pass, and alignment.
- Watch reports: Use aggregate DMARC data to spot unexpected sources and broken alignment.
- Check reputation: Watch for IP or domain blocklist and blacklist issues after volume starts.
Go-live checks
Use these thresholds before moving a new subdomain into regular sending.
Ready
Pass
SPF or DKIM aligns, DMARC passes, and reports show expected sources.
Needs review
Mixed
DNS is valid but message headers show a mismatch.
Do not launch
Fail
DMARC fails or the sender is not the source you expected.
For ongoing monitoring, I also check blocklist monitoring once sending volume begins. A new subdomain can authenticate correctly and still develop reputation problems if the list source, audience quality, complaint rate, or bounce handling is weak.
Common setup mistakes
Most subdomain setup problems are small DNS placement errors. The value is often correct, but the host name is wrong. I check the final fully qualified DNS name every time, especially when a DNS provider auto-appends the parent domain in the background.
|
|
|
|---|---|---|
SPF fails | Wrong return-path | Place SPF on the envelope domain. |
DKIM fails | Wrong selector | Match the selector in headers. |
DMARC fails | No alignment | Align SPF or DKIM with From. |
Provider fails verify | Record at wrong host | Check whether the zone appends domain. |
CNAME rejected | Existing records | Move CNAME to a child host. |
Fast diagnosis for common email subdomain issues.
A clean naming pattern
Use one visible From subdomain for the mailstream, one bounce or return-path host if the provider requires it, and separate child hosts for tracking and DKIM. That keeps CNAME conflicts away from the main sending identity.
Views from the trenches
Best practices
Map each subdomain to one clear mailstream before adding DNS records or policies.
Verify SPF, DKIM, and DMARC with real sent mail, not DNS lookups alone before launch.
Keep tracking and DKIM CNAME records on child hosts to avoid DNS conflicts later.
Common pitfalls
Treating an A record as the main sending setup leaves authentication unfinished.
Adding records at the parent domain instead of the subdomain breaks verification.
Skipping DMARC reports hides alignment failures until volume has already started.
Expert tips
Publish an explicit DMARC record on active subdomains when policies need separate control.
Use provider-supplied DKIM CNAMEs where possible to simplify key rotation later.
Check the fully qualified host name before saving records in any DNS control panel.
Marketer from Email Geeks says DNS control panels differ, so the first step is finding where the host lets you add and manage subdomain records.
2024-03-12 - Email Geeks
Marketer from Email Geeks says an A record alone is not enough for email sending because SPF, DKIM, DMARC, and sometimes MX records are still needed.
2024-03-13 - Email Geeks
The clean answer
To set up an email subdomain, add it in DNS, publish the sending provider's SPF and DKIM records, add DMARC for reporting and policy, add MX only if the subdomain receives replies or bounces, and add CNAME or A records only when a provider or web function needs them. Then send a real test email and confirm SPF, DKIM, and DMARC alignment in the message headers.
Suped is the stronger practical choice for most teams once more than one subdomain, sender, or DNS owner is involved. It brings DMARC, SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, real-time alerts, issue detection, and blocklist or blacklist monitoring into one workflow. That matters because the hard part is not adding one TXT record. The hard part is knowing when the records, sending source, and actual mail behavior all match.
