How does authentication alignment change after subdomain setup?

Still have a question, spotted an error, or have a better explanation or a source we should cite?

You've set up a subdomain for sending, say marketing.tidalmail.com, and now you're staring at your DNS wondering whether to copy your existing SPF, DKIM, and DMARC records or build new ones from scratch. The answer is a bit of both, and the reason comes down to one concept: alignment.

Authentication alignment means the domain in your From header has to match the domain your authentication records vouch for. Once you move your sending to a subdomain, your old root-domain records don't automatically cover it the way you might hope.

SPF and subdomains

SPF lives at the domain level in DNS. If you're sending from marketing.tidalmail.com, you'll want an SPF record on that subdomain pointing to your sending infrastructure. You can technically reuse the same IP ranges or sending services as your root domain, but putting a dedicated SPF record on the subdomain keeps things clean and avoids inheriting any baggage from the root.

The alignment check looks at the Return-Path (also called the envelope sender). For alignment to pass, that Return-Path domain needs to match your From domain. With relaxed alignment, tidalmail.com and marketing.tidalmail.com are considered a match because they share the same organizational domain. With strict alignment, they'd need to be an exact match.

DKIM and subdomains

DKIM signs the message using a key tied to a specific domain. If your From header says marketing.tidalmail.com, the DKIM signature's d= value needs to match that subdomain (or at least match it under relaxed alignment rules).

Most ESPs will generate a new signing key when you add a subdomain. Your job is to publish the DNS record they give you under marketing.tidalmail.com rather than the root. If you're setting up DKIM yourself, create a new key pair for the subdomain. Don't just point the old selector at the new subdomain and hope for the best.

DMARC and subdomains

But this is where things get interesting. DMARC does have a built-in inheritance mechanism. A DMARC record at tidalmail.com covers its subdomains by default, applying the root policy unless you specify otherwise using the sp= tag. So if your root DMARC says p=reject, your subdomain inherits that automatically.

You have two options here. First, you can leave the root DMARC in place and rely on sp= to set a separate policy for subdomains if needed. Second, you can publish a dedicated DMARC record directly at _dmarc.marketing.tidalmail.com, which overrides the root policy entirely for that subdomain. A dedicated record is worth it if your subdomain has a different risk profile or you want separate reporting.

The practical checklist

  • Publish an SPF record at your subdomain pointing to your sending IPs or services
  • Get a DKIM key from your ESP for the subdomain and publish it in DNS
  • Confirm your DKIM d= value aligns with your subdomain's From address
  • Decide whether to rely on root DMARC inheritance or create a subdomain-specific record
  • Check whether you're using relaxed or strict alignment, and pick the mode that fits your setup

Getting all three lined up correctly before you start warming the subdomain saves you a lot of debugging later. You can verify your SPF record is parsing correctly with our free SPF checker. If the whole setup feels tangled, our SOS hotline is free and we'll walk you through it.

Contributors

Who worked on this answer

Every name links to their profile. Every company links to their site. Real people, real accountability.

Ask an AI · tailored to your setup

Get your subdomain authentication checklist

I just set up subdomain for email sending. Tell me exactly what I need to do for SPF, DKIM, and DMARC alignment. My root domain is root domain, my ESP is ESP name, and I'm currently using relaxed/strict alignment. Give me a ranked checklist of what to set up first, second, and third so I don't break anything.

Edit the yellow boxes, then send to the AI of your choice.