Three months ago I watched a SaaS founder's password-reset emails land in spam for nine days straight. The cause? A marketing contractor had blasted a 40,000-email campaign from the same domain. Gmail flagged the domain, and suddenly "Reset your password" was sitting next to Nigerian prince offers. Nine days of support tickets. Nine days of users who couldn't log in. All because transactional and marketing email shared a reputation.

That's the problem a dedicated sending subdomain solves.

If you're sending transactional email — password resets, order confirmations, two-factor codes, anything your users actually need — you want that traffic isolated from everything else touching your domain. A subdomain like send.yourdomain.com or mail.yourdomain.com gets its own reputation, its own authentication records, and its own insulation from marketing mishaps.

Here's how to set one up.

What You'll Have When This Is Done

By the end: a working sending subdomain with dedicated SPF, DKIM, and DMARC records. Your transactional traffic isolated from everything else. Verification that Gmail, Outlook, and Yahoo actually recognize the authentication. (They're pickier than you'd think.)

We use this setup across every Velocity Digital Labs product — JustEmails, ClickzProtect, JustAnalytics, and the rest. Same pattern every time. I've probably set up thirty of these subdomains at this point. Still manage to typo at least one CNAME record every other time.

Prerequisites

Access to your domain's DNS (Cloudflare, Route 53, GoDaddy, wherever your nameservers point)
A transactional email provider account — JustEmails, SendGrid, Postmark, Amazon SES, Mailgun, or similar
SMTP credentials or API key from that provider
The domain you're setting up the subdomain under (already registered and verified)
10-15 minutes for DNS propagation

If your root domain doesn't have SPF, DKIM, and DMARC configured yet, start with our custom domain email setup guide first. You need the parent domain healthy before branching off subdomains. And if you're tracking email opens and clicks, make sure your analytics integration doesn't break authentication headers.

Step 1: Choose Your Sending Subdomain Name

Pick something clear and functional. Common patterns:

send.yourdomain.com — explicit, obvious
mail.yourdomain.com — slightly more generic
notifications.yourdomain.com — if you want to be specific about purpose
tx.yourdomain.com — short for transactional, but less readable

I prefer send. because it's unambiguous. When someone sees send.yourdomain.com in an email header, they know what it's for. Maybe that's just me being opinionated. But clarity in email infrastructure isn't optional — it's the difference between debugging for ten minutes and debugging for ten hours.

Don't use email. — that sounds like it might be for receiving. And avoid no-reply. as a subdomain. That's a mailbox convention, not a subdomain purpose.

One subdomain per use case. If you're running both transactional and marketing, you want send.yourdomain.com for transactional and marketing.yourdomain.com or news.yourdomain.com for campaigns. The whole point is separation.

Step 2: Create the SPF Record

SPF tells receiving servers which IP addresses are allowed to send on behalf of your subdomain. Your transactional email provider gives you an include: directive to add.

Create a TXT record at send.yourdomain.com:

send.yourdomain.com.  IN  TXT  "v=spf1 include:_spf.justemails.app ~all"

Substitute your provider's SPF include. SendGrid uses include:sendgrid.net. Postmark uses include:spf.mtasv.net. Amazon SES uses include:amazonses.com. Mailgun uses include:mailgun.org.

The ~all at the end means soft fail — non-matching senders get marked suspicious but not rejected. Once you're confident the record is complete, you can tighten to -all (hard fail). But start with ~all. You'll thank me when you discover a forgotten integration that wasn't in the documentation.

I've hardened SPF too early exactly once. Locked myself out of a client's billing notification system for two days. Never again.

Important: This is a new record for the subdomain, not a modification to your root domain's SPF. Your root domain keeps its own SPF record. Subdomains have their own.

Step 3: Add DKIM Records

DKIM signing proves the email wasn't modified in transit and that it came from an authorized sender. Your provider generates a public key that you publish in DNS.

Every provider handles this differently. JustEmails auto-generates DKIM records when you add a domain — you copy two CNAMEs to your DNS. SendGrid gives you three CNAMEs. Postmark gives you one or two TXT records depending on the key rotation.

Typical DKIM setup for a sending subdomain (example for JustEmails):

je1._domainkey.send.yourdomain.com.  IN  CNAME  je1._domainkey.justemails.app.
je2._domainkey.send.yourdomain.com.  IN  CNAME  je2._domainkey.justemails.app.

Or for SendGrid:

s1._domainkey.send.yourdomain.com.  IN  CNAME  s1.domainkey.u12345678.wl.sendgrid.net.
s2._domainkey.send.yourdomain.com.  IN  CNAME  s2.domainkey.u12345678.wl.sendgrid.net.

The exact values come from your provider's domain authentication dashboard. Don't guess — copy-paste from their UI. A typo in the subdomain or a missing period at the end will break authentication, and you won't notice until you check headers.

After adding the records, wait for DNS propagation (usually 5-15 minutes, sometimes up to 48 hours for slow registrars), then verify in your provider's dashboard. They all have a "Verify" button that checks your DNS.

Step 4: Set Up DMARC for the Subdomain

DMARC ties SPF and DKIM together and tells receivers what to do when authentication fails. Create a TXT record at _dmarc.send.yourdomain.com:

_dmarc.send.yourdomain.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; adkim=r; aspf=r"

Start with p=none to monitor without enforcement. You'll ramp to p=quarantine and eventually p=reject over 4-8 weeks, following the same pattern we outlined in our DMARC ramp guide.

The rua=mailto: address receives aggregate reports — daily XML summaries of who's sending mail using your subdomain and whether it passed authentication. Don't skip this. Without it, you're flying blind.

Note: Subdomains do NOT automatically inherit the parent domain's DMARC policy. If your root domain has p=reject but you don't set up DMARC for the subdomain, the subdomain defaults to no policy. Set it explicitly.

Step 5: (Optional) Add an MX Record

If your subdomain is send-only — no replies expected — you technically don't need an MX record. But some edge cases can bite you.

When a receiving server gets a bounce or an auto-reply, it may try to deliver to the Return-Path address. If that address is on a subdomain with no MX, some servers give up cleanly. Others return weird errors that can affect reputation. Doesn't happen often, but when it does, it's confusing to debug.

Add a low-priority MX pointing to your main mail server or a null handler:

send.yourdomain.com.  IN  MX  10  mail.yourdomain.com.

Or if you want to explicitly reject incoming mail:

send.yourdomain.com.  IN  MX  0  .

(The single period is the null MX, defined in RFC 7505. It tells other servers "don't deliver here.")

For most setups, just point it at your main mail server and let any stray replies land in a catch-all or get filtered.

Step 6: Configure Your Provider to Use the Subdomain

Now tell your transactional email provider to send from the subdomain.

In JustEmails, you add send.yourdomain.com as a domain in the dashboard, add the DNS records, verify, and then set your From address to use that subdomain:

From: noreply@send.yourdomain.com

SendGrid, Postmark, and others work similarly. Add the subdomain, authenticate, and configure your From addresses.

Real talk: The From address matters for recipient trust, but the real authentication happens on the Return-Path and DKIM signing. Make sure both are aligned to the subdomain. Send a test email and check headers — look for:

Return-Path: <bounce@send.yourdomain.com> (or similar)
DKIM-Signature: ... d=send.yourdomain.com; ...
Authentication-Results: ... dkim=pass ... spf=pass ...

If the Return-Path shows your provider's domain (like bounces.sendgrid.net) instead of yours, SPF won't align to your subdomain. DKIM alignment becomes critical in that case. Most providers let you customize the Return-Path — look for "Domain Authentication" or "Sender Authentication" settings.

Step 7: Verify Authentication

Send a test email to a Gmail account. Open the message, click the three dots, and select "Show original." Scroll to the Authentication-Results header.

You want to see:

dkim=pass header.d=send.yourdomain.com
spf=pass (google.com: domain of noreply@send.yourdomain.com designates ... as permitted sender)
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=send.yourdomain.com

If any of those show fail or softfail, something's misconfigured. Check:

DKIM fail: Verify the CNAME/TXT records are published correctly. Use dig +short CNAME je1._domainkey.send.yourdomain.com to check.
SPF fail: Verify the SPF TXT record exists at the subdomain. Use dig +short TXT send.yourdomain.com to check.
DMARC fail: Usually means SPF and DKIM both failed alignment. Fix those first.

Also send a test to Outlook.com and Yahoo. Different providers check differently — pass on Gmail doesn't guarantee pass everywhere. Honestly, Yahoo's authentication checks have tripped me up more than once. Their feedback loop is... opaque.

Common Errors and Fixes

DNS records not propagating

dig +short TXT send.yourdomain.com
(no output)

Wait longer — some registrars take hours. If it's been 24+ hours, check you added the record to the correct zone (subdomain records go under the parent domain's DNS, not a separate zone). Cloudflare users: make sure the record isn't proxied (orange cloud). DNS records should be DNS-only (gray cloud).

DKIM signature invalid after key rotation

Some providers rotate DKIM keys automatically. When they do, you need to update the CNAME or TXT in DNS to match the new key. If you see dkim=fail after months of working fine, check your provider's dashboard for updated DNS records.

SPF too many lookups error

permerror (too many DNS lookups)

SPF has a 10-lookup limit. Each include: counts, and nested includes count too. If your subdomain only sends through one provider, you should be fine. If you're including multiple providers, you may need to flatten your SPF record (replace nested includes with direct IP blocks). Tools like dmarcian's SPF surveyor help diagnose this.

DMARC reports not arriving

Check your rua=mailto: address. If it's on a different domain than the one being reported on, you need to publish an authorization record. Add this to the receiving domain:

send.yourdomain.com._report._dmarc.yourdomain.com.  IN  TXT  "v=DMARC1"

This tells receivers that yourdomain.com accepts DMARC reports for send.yourdomain.com. Yeah, it's confusing. Blame the RFC. I think I spent two hours on this exact issue the first time I encountered it — felt like an idiot when the fix was one TXT record.

Next Steps

Once your subdomain is authenticated and verified:

Ramp your DMARC policy from p=none to p=quarantine to p=reject over 4-8 weeks. Follow the DMARC ramp guide for the detailed process.
Monitor with Google Postmaster Tools — add send.yourdomain.com and watch reputation, spam rate, and authentication success rate. If you need deeper analytics on email engagement, JustAnalytics can track opens and clicks without breaking DKIM alignment.
Warm up gradually if you're new to sending. Start with a few hundred emails/day and increase over 2-3 weeks. Blasting 50,000 emails from a fresh subdomain gets flagged.
Set up webhooks to track bounces and complaints in real-time. When a user marks your password reset as spam (it happens — people are wild), you want to know immediately. Nothing humbles you quite like watching a user flag their own account recovery email.

For a deep dive into SMTP vs API integration patterns, check our transactional email integration guide. And if you're comparing transactional email providers, our Google Workspace alternatives roundup covers the landscape. For protecting your ad-driven traffic that triggers these transactional emails, ClickzProtect blocks click fraud before it burns budget.

Frequently Asked Questions

Why should transactional email use a separate subdomain?

Transactional mail (password resets, receipts, alerts) and marketing mail have different sending patterns and complaint profiles. If a marketing campaign triggers spam complaints, those complaints tank the reputation of the sending domain. A dedicated subdomain — send.yourdomain.com or mail.yourdomain.com — isolates transactional reputation. Your password resets keep landing in inboxes even when marketing has a rough week.

Does a subdomain inherit the parent domain's reputation?

Partially, but not fully. Gmail and other major receivers treat subdomains as related but distinct. A brand-new subdomain gets a small reputation boost from a healthy parent domain, but builds its own history over time. That's the point — isolation works both ways. Good transactional reputation doesn't drag down a misbehaving marketing subdomain, and vice versa.

Do I need a separate MX record for a sending-only subdomain?

Not strictly required if you're only sending, not receiving. But adding an MX pointing to a null handler or your main mail server prevents some edge-case bounces where a receiving server tries to reply to the Return-Path. We recommend setting up a basic MX even for send-only subdomains.

How long does it take for a new sending subdomain to build reputation?

Plan on 2-4 weeks of consistent sending before Gmail and Outlook fully trust a new subdomain. Start with low volume and ramp up gradually — don't flip the switch and blast 50,000 emails on day one. Use Google Postmaster Tools to watch reputation shift from 'Low' to 'Medium' to 'High' over that period.

Try JustEmails

Unlimited custom domain email hosting for $49/year flat — unlimited domains, unlimited email accounts, 10 GB storage, full IMAP/SMTP. Built for agencies, freelancers, and anyone managing email across more than one domain. Plus 1,000 transactional API emails/month included.

Start your 7-day free trial → · How it compares

How to Set Up a Dedicated Sending Subdomain for Transactional Email (2026)