how-to · sourced answer

Email for a Subdomain: DNS Setup for Sending and Receiving

TL;DR: An email subdomain (like mail.example.com) needs its own DNS records: DKIM for the subdomain, SPF on its return-path domain, and MX records if it should receive mail, because none of these are inherited from example.com. DMARC is the exception: without a _dmarc record on the subdomain, receivers use the parent's policy, with sp= setting the subdomain policy. Use separate subdomains for transactional and marketing mail.

What is an email subdomain used for?

An email subdomain is a domain under your main domain, such as mail.example.com, news.example.com, or support.example.com, that is used in email addresses or as the authenticated sending domain instead of example.com itself. It can play three roles, and it helps to keep them separate. A sending subdomain appears in the From address (receipts@mail.example.com) and carries its own SPF, DKIM, and DMARC results. A return-path (MAIL FROM) subdomain, such as bounce.mail.example.com, receives bounces and is used for SPF, while the visible From can stay on the root domain. A receiving subdomain has its own MX records, so mail to anything@support.example.com can go to a different system, such as a help desk or an inbound email API, than mail to the root. Each subdomain is a separate name in DNS, so it needs its own records: nothing about SPF or MX is inherited from the parent, while DMARC is the one standard that does fall back to the parent domain.

Does a separate sending name protect reputation?

Teams use a subdomain for email for four reasons: to separate reputation between mail streams, to delegate a stream to a different provider without touching the main domain's records, to give each system its own DNS records, and to receive mail into a different system. The common setup is transactional mail (password resets, receipts) on one subdomain and marketing campaigns on another, so a campaign that draws complaints does not slow down password resets. That separation is real but partial. Many marketing pages claim mailbox providers treat subdomains as entirely separate entities; Gmail's own tooling suggests otherwise. Google Postmaster Tools lets you add subdomains to see their dashboards individually, but its Compliance status dashboard reports at the primary domain and uses data from all subdomains, and DMARC's relaxed alignment ties every subdomain back to the organizational domain. Treat a subdomain as a firewall for day-to-day reputation swings, not as a way to escape the consequences of bad sending.

Which DNS records does a sending subdomain need?

A sending subdomain needs DKIM, SPF on its return-path domain, and DMARC coverage; a typical setup with Amazon SES has six or seven records. DKIM: SES publishes three CNAME records under the subdomain, named <token>._domainkey.mail.example.com and pointing to <token>.dkim.amazonses.com, so the signature's d= is mail.example.com. SPF: SPF is evaluated against the exact envelope sender domain (RFC 7208), so the root's SPF record does not cover a subdomain. If you use a custom MAIL FROM domain such as bounce.mail.example.com, it needs its own TXT record, v=spf1 include:amazonses.com ~all, plus an MX record pointing to feedback-smtp.<region>.amazonses.com so bounces can be received. AWS requires that MAIL FROM subdomain to be used for nothing else. DMARC: publish _dmarc.mail.example.com if the subdomain needs a policy different from the parent; otherwise the parent's record applies. SendHQ provisions the three DKIM CNAMEs, an SPF TXT, a DMARC TXT, and an SES verification TXT for each domain you add.

; Sending subdomain mail.example.com with Amazon SES (us-east-1)
abc123._domainkey.mail.example.com.  CNAME  abc123.dkim.amazonses.com.
def456._domainkey.mail.example.com.  CNAME  def456.dkim.amazonses.com.
ghi789._domainkey.mail.example.com.  CNAME  ghi789.dkim.amazonses.com.

; custom MAIL FROM (return-path) under the sending subdomain
bounce.mail.example.com.  MX   10 feedback-smtp.us-east-1.amazonses.com.
bounce.mail.example.com.  TXT  "v=spf1 include:amazonses.com ~all"

; optional subdomain-specific DMARC policy
_dmarc.mail.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

How does DMARC apply to subdomains?

DMARC applies to subdomains through a lookup fallback and the sp= tag defined in RFC 7489. When Gmail receives a message from receipts@mail.example.com, it first looks for a TXT record at _dmarc.mail.example.com. If none exists, it falls back to the organizational domain's record at _dmarc.example.com. In that parent record, the p= tag sets the policy for example.com itself, and the optional sp= tag sets the policy for all subdomains; if sp= is absent, subdomains get the same policy as p=. So v=DMARC1; p=reject; sp=quarantine rejects failing mail from the root but only quarantines failing mail from subdomains. A subdomain's own _dmarc record overrides the parent for that subdomain only. Alignment also uses the organizational domain by default: in relaxed mode, a DKIM signature from mail.example.com aligns with a From address at example.com, which is why many products sign with a subdomain while showing the root domain in From. Strict alignment (adkim=s, aspf=s) requires an exact match.

How do you route inbound mail with MX records?

To receive email on a subdomain, publish MX records for that exact subdomain pointing to the server that should accept its mail. MX records are not inherited, so mail to help@support.example.com does not use example.com's MX. If the subdomain has no MX record, RFC 5321 treats its A or AAAA record as an implicit MX, which usually means mail goes to a web server that refuses it, so always publish an explicit MX or a null MX (MX 0 .) for subdomains that should not receive mail. This lets you route subdomains to different systems: example.com to Google Workspace, support.example.com to Zendesk or Freshdesk, and replies.example.com to an inbound email API that parses messages for your application or AI agent. In Microsoft 365, the same approach routes a subdomain to a different tenant: the subdomain is added as an accepted domain in that tenant and its MX points to that tenant's mail endpoint. For a subdomain that sends and receives, keep the return-path subdomain separate, as AWS SES requires.

; route support.example.com to a help desk, replies.example.com to an API
support.example.com.   MX  10 mx.helpdesk-provider.example.
replies.example.com.   MX  10 route1.mx.cloudflare.net.
replies.example.com.   MX  20 route2.mx.cloudflare.net.

; a subdomain that should never receive mail
assets.example.com.    MX  0 .

Should transactional and marketing streams be split?

Yes, for most products transactional and marketing email should use different subdomains, because their risk profiles differ. Transactional messages are expected, low-complaint, and urgent; marketing messages draw more complaints and unsubscribes. A common naming scheme is mail.example.com or notify.example.com for transactional, news.example.com or m.example.com for marketing, and the root example.com for people's own mailboxes in Google Workspace or Microsoft 365. Use distinct DKIM keys per stream, and if you use separate providers, give each its own subdomain so neither needs to edit the other's records or SPF include list, which also keeps you under SPF's limit of 10 DNS lookups. Add each sending subdomain to Google Postmaster Tools separately so you can see each stream's spam rate. Keep the From display name consistent across streams so recipients recognize you, and keep the subdomain stable once it has history: switching to a new, unknown subdomain resets its reputation and needs warming up.

How do you set up a subdomain in SendHQ?

In SendHQ, you add the subdomain itself as a domain, for example mail.example.com, and SendHQ generates the DNS plan for it: three Amazon SES DKIM CNAMEs, an SPF TXT, a DMARC TXT, and an SES verification TXT. If the parent zone is on Cloudflare, the dashboard can request temporary dns.read and dns.write access and add the records in one step; setup is add-only, stops if it finds a conflicting SPF or DMARC policy, and does not keep the token. The domain then moves through pending (a required value is missing), checking (a resolver result is unavailable), propagating (records were added but public resolvers disagree), and verified. POST /domains/:id/verify forces an authoritative refresh. Once verified, any address on mail.example.com can be used as a From identity, and you can create inboxes on the same subdomain to receive replies, which thread with the original outbound messages.

Questions teams ask

Can I have an email address on a subdomain?

Yes. Any subdomain can host addresses such as help@support.example.com once it has MX records pointing to a mail server that accepts mail for it. To send from it, add DKIM and SPF records for that subdomain with your sending provider.

Does a subdomain inherit the root domain's SPF record?

No. SPF is checked against the exact domain in the envelope sender (RFC 7208), so a subdomain needs its own TXT record starting with v=spf1 if it is used as a return-path or HELO domain.

Does a subdomain need its own DMARC record?

Not necessarily. If _dmarc.sub.example.com does not exist, receivers use the record at _dmarc.example.com, applying its sp= policy, or p= when sp= is absent. Publish a subdomain record only when it needs a different policy or reporting address.

Will a subdomain protect my main domain's reputation?

Partly. Mailbox providers track subdomain reputation, so a bad marketing stream on news.example.com affects transactional mail on mail.example.com less. But reputation and DMARC still connect to the organizational domain, so persistent bad sending on any subdomain can hurt the whole domain.

What is the best subdomain name for email?

Short, descriptive names work best: mail, notify, or send for transactional mail, and news or m for marketing. Avoid random strings, which look suspicious in headers, and keep the name stable once it has sending history.

Primary sources

Continue learning

email domain verificationemail dkim spf dmarcspf record syntaxdkim setupreceive email with api