Transactional Email DNS Checklist: Subdomain, Return-Path, DKIM, Tracking

Password resets, receipts, shipping updates and login codes are the mail your customers actively wait for, and they deserve their own infrastructure. Most teams send them through a transactional email provider (an API or SMTP relay), and each provider asks you to add a handful of DNS records. This checklist explains what each record is for, how they fit together for DMARC alignment, and the mistakes that make otherwise "verified" setups fail in the wild.

The record names and targets below are placeholders. Every provider generates its own values, so copy them from your provider's domain setup screen. The shape is what this guide teaches.

The architecture in one picture

From address:        receipts@mail.example.com        (what the customer sees)
Return-path domain:  bounce.mail.example.com          (envelope sender, SPF checks this)
DKIM signing domain: mail.example.com                 (d= in the signature)
Tracking domain:     links.mail.example.com           (rewritten click/open links)
DMARC policy from:   _dmarc.example.com               (applies to subdomains unless overridden)

Everything sits under one subdomain so it aligns with itself, and so its reputation is separate from the rest of your company mail.

1. Use a dedicated subdomain

Do not send transactional mail from the same domain as your staff mailboxes. Use a subdomain such as mail.example.com, notify.example.com or tx.example.com.

Why:

• Reputation isolation. If marketing mail attracts complaints, it should not drag down password resets. Separate subdomains build separate reputations.
• Separate SPF budget. SPF is limited to ten DNS lookups per record. A subdomain gets its own record and its own budget; see fixing too many lookups.
• Safer experimentation. You can change providers or tighten policy on a subdomain without touching the root.
• DMARC alignment still works. Under relaxed alignment, mail.example.com and example.com share an organizational domain.

Keep one subdomain per stream: for example mail. for transactional and news. for marketing. Do not put it on a domain where people also read and answer mail unless you also publish an MX (see below).

2. Domain authentication records from your provider

Providers typically ask for some combination of the following.

DKIM

Either CNAMEs pointing to keys the provider hosts:

s1._domainkey.mail.example.com.   3600  IN  CNAME  s1.domainkey.u0000000.provider.example.
s2._domainkey.mail.example.com.   3600  IN  CNAME  s2.domainkey.u0000000.provider.example.

or a TXT record containing the public key:

provider1._domainkey.mail.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

What matters: the signature must use your domain (d=mail.example.com), not the provider's. If it signs as the provider's domain, DKIM passes but does not align with your From address. Details are in DKIM setup and troubleshooting.

Return-path (custom bounce domain)

The envelope sender, also called the return-path, MAIL FROM or bounce address, decides which domain SPF is checked against. By default providers use their domain, so SPF passes for them but does not align with you. A custom return-path fixes this:

bounce.mail.example.com.   3600  IN  CNAME  returns.provider.example.

Some providers instead ask for an MX and TXT pair on the bounce subdomain:

bounce.mail.example.com.   3600  IN  MX   10  feedback-smtp.provider.example.
bounce.mail.example.com.   3600  IN  TXT  "v=spf1 include:spf.provider.example ~all"

Either way, the result is that the envelope sender is something@bounce.mail.example.com, SPF is evaluated against your subdomain's records, and bounces return to the provider so it can suppress bad addresses.

SPF on the sending subdomain

If the provider asks for an SPF include on the From subdomain, publish a single record there:

mail.example.com.   3600  IN  TXT  "v=spf1 include:spf.provider.example -all"

Check it with the SPF रिकॉर्ड चेकर. If you also send from this subdomain through another system, merge into one record. Two SPF records at one name cause a permanent error.

3. DMARC and alignment

Your DMARC policy at the root covers subdomains by default:

_dmarc.example.com.   3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

You can also publish a more specific record for the transactional subdomain:

_dmarc.mail.example.com.   3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

DMARC passes when SPF or DKIM passes and aligns with the From domain. For transactional mail, aim for both aligned, with DKIM as the one you rely on. Roll out policies in stages as in the DMARC rollout guide.

4. Tracking domain (links and opens)

Providers that track clicks or opens rewrite links to a tracking host. By default that host is theirs, and every email in your template then contains a link to a shared domain that spammers on the same platform may also use. A custom tracking domain keeps links on your own brand:

links.mail.example.com.   3600  IN  CNAME  tracking.provider.example.

Considerations:

• The provider will normally need to issue a TLS certificate for the tracking hostname so that https://links.mail.example.com/... works. Until the certificate is ready, links may fail or warn. Verify with the SSL Checker.
• Do you need tracking at all? For password reset and security mail, many teams turn off click tracking. Rewritten links can break one-time URLs, look suspicious, and add a redirect hop. Consider tracking only where it brings value.
• If the provider's CNAME target changes, your links break, so keep the record in your documentation.

5. Inbound: should the subdomain receive mail?

If customers might reply to receipts@mail.example.com, you need somewhere for replies to go. Options:

• Set Reply-To to a monitored address on your main domain, such as support@example.com. This is the simplest and most common choice.
• Publish an MX for the subdomain pointing at a real inbox (see MX records explained).
• If the subdomain should never receive mail, publish a null MX:

mail.example.com.   3600  IN  MX  0  .

Be careful: the bounce. subdomain may legitimately need MX records for the provider's bounce handling, so do not put a null MX there if your provider asks for something else.

6. Optional: dedicated IPs and reverse DNS

On a shared IP pool the provider manages reverse DNS and reputation. If you buy a dedicated IP, ask what the PTR will be and whether you can set it to a hostname on your subdomain; see reverse DNS for email. Fresh dedicated IPs must be warmed gradually; see warming up a new domain.

Verification checklist

Work through it in order:

1. [ ] Sending subdomain chosen and separate from the corporate mail domain.
2. [ ] DKIM records published and shown as verified by the provider.
3. [ ] Return-path / bounce domain configured and verified.
4. [ ] Single SPF record on any name that needs one, under ten lookups.
5. [ ] DMARC record present at root (and subdomain if specific policy needed), with rua.
6. [ ] Custom tracking domain set up, with a valid certificate, or tracking disabled.
7. [ ] Reply-To or MX defined for replies.
8. [ ] Test message sent to the ईमेल डिलीवरेबिलिटी टेस्ट: spf=pass aligned with the From domain, dkim=pass with header.d=mail.example.com, dmarc=pass.
9. [ ] Sending IP checked in the Blacklist Checker.
10. [ ] Whole domain reviewed in the Email DNS Checker.

Common mistakes

• Provider's domain in the From address. Mail appears to come from the provider and gets no brand trust.
• Verified in the dashboard, unaligned in reality. The provider only checks that a record exists. Only a real test message proves alignment.
• CNAME records with proxying enabled. If your DNS host proxies records by default (as some do), turn proxying off for DKIM and return-path CNAMEs. These must be DNS-only.
• A trailing domain appended twice. Entering the full name in a panel that appends the zone creates s1._domainkey.mail.example.com.example.com.
• Leaving old provider records. Old DKIM keys and SPF includes accumulate. Remove those you no longer use.
• Ignoring bounces and complaints. Transactional mail still needs list hygiene: suppress addresses that hard bounce.

अगले कदम

• Check each record with the Email DNS Checker.
• Draft SPF and DMARC with the SPF & DMARC Generator.
• Send a live test through the ईमेल डिलीवरेबिलिटी टेस्ट.
• Read ecommerce order email deliverability for store-specific advice, or WordPress email not sending if your site's built-in mail is the problem.

सामान्य प्रश्न

Why use a subdomain instead of my main domain for transactional email?

It isolates reputation and SPF limits, so problems in one mail stream do not affect another. Under relaxed DMARC alignment, a subdomain still aligns with the organizational domain.

What is a return-path domain?

It is the domain in the envelope sender address, where bounces are sent and which SPF checks. Setting a custom one on your own subdomain makes SPF align with your From domain.

Do I need both SPF and DKIM for transactional mail?

DMARC needs only one to pass and align, but set up both. DKIM survives forwarding and is the more reliable one, while SPF provides a second path.

Should I use click tracking on password-reset emails?

Many teams do not. Link rewriting can break one-time links and looks less trustworthy for security mail. Turn it off for those messages if your provider allows it per message.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.