Email Subdomains: What a Sending Subdomain Inherits, and What It Does Not
A sending subdomain inherits your DMARC policy and neither SPF nor DKIM. The specifications settle that much; reputation separation is the part nobody publishes.
A sending subdomain inherits its parent domain DMARC policy through policy discovery, and inherits neither SPF nor DKIM, both of which must be published under the sending name itself. Relaxed DMARC alignment lets a subdomain send carry the parent brand and pass. Reputation separation between subdomain and parent is not published by any receiver.
Key takeaways
- RFC 7208 requires an SPF declaration to be repeated for subdomains, so a subdomain with no record of its own is unauthenticated for SPF regardless of what the root publishes.
- RFC 7489 section 6.6.3 makes DMARC the exception: a receiver falls back to the Organizational Domain record when the subdomain has none, and the parent steers that with the sp tag.
- Relaxed alignment compares Organizational Domains, so news.example.com aligns with a d=example.com signature; strict alignment requires an exact match and breaks that setup.
- No mailbox provider publishes how subdomain sending history rolls up to the parent, so treat reputation separation as an assumption and use a separate domain where the separation has to hold.
Reviewed and updated August 16, 2026
The advice arrives in one sentence: send marketing from a subdomain so your main domain is protected. It is repeated on vendor help pages, in deliverability threads and by consultants, and about half of what it implies is true.
The half that is true is specific and checkable, because it is written into the authentication specifications. The half that is not true is the part people actually rely on, which is the idea that a subdomain is a clean room with its own reputation and no line back to the parent. Nobody who operates a receiving mail system has published that line, and the specifications say something more interesting: your subdomain inherits one of the three authentication mechanisms and neither of the other two.
What a subdomain inherits, mechanism by mechanism
Three records govern authentication, and they behave differently under a subdomain. This is the part where the answer is settled rather than debated.
SPF inherits nothing. RFC 7208 is explicit that a declaration has to be repeated for any host that has records at all, and for subdomains of it, discussing wildcards precisely because publication does not cascade downward. So send.example.com with no SPF record of its own has no SPF record, whatever sits at example.com. A sender who publishes SPF at the root and sends from a subdomain has published nothing that applies to their mail.
DKIM inherits nothing. A DKIM signature carries a d= value naming the signing domain, and the public key lives at a selector under that domain. A subdomain that signs its own mail publishes its own selector record. There is no fallback to the parent.
DMARC does inherit, and it is the exception. RFC 7489 section 6.6.3 sets out policy discovery: a receiver queries the DMARC record at the domain in the From header, and if that returns nothing usable, it queries the record at the Organizational Domain instead. So a subdomain with no DMARC record of its own is governed by the parent's, and the parent can direct that inheritance with the sp tag, which requests a policy for all subdomains and applies only to subdomains rather than to the domain itself. If sp is absent, the parent's p policy applies to subdomains too.
- No: SPF: inherited from the parent domain
- No: DKIM: inherited from the parent domain
- Yes: DMARC policy: inherited when the subdomain has no record of its own
- Yes: DMARC alignment in relaxed mode: subdomain aligns with the parent
- No: DMARC alignment in strict mode: subdomain aligns with the parent
- No: Sending reputation at the mailbox providers: published anywhere
The Organizational Domain, and why relaxed alignment matters here
The mechanism behind that inheritance is worth understanding, because it is also what decides whether a subdomain send passes DMARC at all.
RFC 7489 section 3.2 defines the Organizational Domain by an algorithm over a public suffix list: take the domain, find the longest matching public suffix, and add one more label. So a.b.c.d.example.com has an Organizational Domain of example.com, and so does news.example.com.
Alignment then comes in two modes. In relaxed mode, the Organizational Domains of the DKIM signing domain and the From domain have to be equal. In strict mode, only an exact match of the fully qualified names counts. The specification's own illustration is the case at hand: a validated signature with d=example.com and a From address at alerts@news.example.com are in alignment under relaxed mode, and fail under strict.
That is the practical hinge. Relaxed alignment, which is the default, is what lets a subdomain send carry the parent's brand in the From address and still pass. Turning alignment strict is a real hardening step, and it is also the step that breaks a subdomain setup that was working the day before.
- Step 1Query the From domain
A TXT lookup at _dmarc.send.example.com. Records without a current v= tag are discarded.
- Step 2If nothing usable, query the Organizational Domain
A TXT lookup at _dmarc.example.com, found by the public suffix algorithm in section 3.2.
- Step 3Apply p, or sp if present
The parent's sp tag requests the policy for subdomains. Absent sp, the parent's p applies to them.
- Step 4Check alignment
Relaxed mode compares Organizational Domains, so the subdomain aligns with the parent. Strict mode requires an exact match.
The part no specification governs
Reputation is where the confident advice runs out of evidence.
Mailbox providers judge sending on history attached to domains and IP addresses, and none of the major ones publishes how a subdomain's history rolls up to its parent, how much of a parent's standing a new subdomain starts with, or whether damage flows upward. Every categorical claim in circulation on this point, in either direction, is inference presented as fact.
What can be said honestly is narrower and still useful. A brand-new subdomain is a name with no sending history, and it has to build one the same way any new sending name does. Filtering is not decided by a single lookup on one name, so treating a subdomain as a firewall between two sending programmes is an assumption you cannot verify from outside. And the more separation you want between two programmes, the further apart the names have to be, which is the argument that ends at a separate domain rather than a subdomain. Email domain reputation covers what is actually observable, and warming a cold email domain covers the ramp any new sending name needs.
Subdomain or separate domain
The two options answer different questions, and the choice usually follows from what the mail is.
A subdomain keeps the Organizational Domain, so it keeps relaxed DMARC alignment with the brand, it keeps the brand visible in the From address, and it stays inside one policy the parent can steer with sp. That is exactly right for marketing and transactional mail from a recognised brand, where recipients have a relationship with the name and you want them to see it.
A separate domain gives up all of that on purpose. Different Organizational Domain, no shared alignment, no shared DMARC policy, a reputation that starts at zero and belongs to nobody else. That is the correct trade for cold outbound, where the recipient has no relationship with the sender, where volume patterns look nothing like opted-in mail, and where the point is that nothing arriving at the primary domain's reputation can touch it.
- Shares the Organizational Domain
- Relaxed DMARC alignment with the brand holds
- Parent can steer policy with the sp tag
- Brand recognition in the From address
- Separation from the parent is assumed, not published
- Different Organizational Domain entirely
- No shared alignment or inherited policy
- Reputation starts from nothing and is built
- Brand recognition has to be earned in the copy
- The separation is structural rather than assumed
That is our own operating choice and it is a policy rather than a finding: we run client campaigns from dedicated mailboxes on domains kept separate from the client's primary domain, warmed before they carry campaign traffic. The reason is the trade above. Cold outbound is the sending pattern most likely to attract a complaint, and the client's primary domain is the asset that must not be the one carrying it.
The records you actually publish
Whichever shape you pick, the sending name needs its own SPF and DKIM, because neither inherits. A minimal, valid set for a sending subdomain looks like this.
At send.example.com, a TXT record authorising your sending platform and refusing everything else:
v=spf1 include:_spf.provider.example -all
A DKIM public key at the selector your platform gives you, published under the sending name rather than the parent, so selector1._domainkey.send.example.com.
A DMARC record at _dmarc.send.example.com, starting in monitoring mode so the reports arrive before any policy bites:
v=DMARC1; p=none; rua=mailto:dmarc@example.com
And on the parent, if you want a strict posture at the root while a subdomain is still ramping, the sp tag makes that explicit rather than accidental:
v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@example.com
Two cautions on that last one. sp applies only to subdomains and never to the domain publishing it, and RFC 7489 notes that sp is ignored on DMARC records published on subdomains of Organizational Domains, because of how policy discovery works. So sp belongs on the Organizational Domain's record and nowhere else. The mechanics of each record are covered in DMARC record and Google Workspace SPF record, and the three together in SPF, DKIM and DMARC for cold email.
The subdomain that is not a sending domain
One more subdomain usually appears in the same setup and is not a sending name at all. Link tracking and open tracking are served from a host you point at your platform, and using the platform's shared hostname puts your links on a name whose reputation belongs to every other customer of that platform. A custom tracking domain is a subdomain used purely to serve redirects, so it needs a CNAME or an A record rather than SPF, DKIM or DMARC, because nothing is sent from it.
The two get conflated because they look alike in a DNS zone and are configured in the same sitting. Keep them apart in your head: the sending subdomain needs authentication records and a warm-up, and the tracking subdomain needs a hostname that resolves and a certificate that matches. Neither set of records helps the other job, and a missing tracking record produces links that fail to load rather than mail that fails to authenticate.
The short version
A sending subdomain inherits your DMARC policy and nothing else. SPF and DKIM have to be published under the sending name itself, and a subdomain without them is unauthenticated no matter what sits at the root. Relaxed DMARC alignment is what lets a subdomain send carry the parent brand and pass, and switching alignment to strict is what breaks it. Reputation separation between a subdomain and its parent is unpublished by every receiver that matters, so treat it as an assumption rather than a guarantee, and when the separation genuinely has to hold, use a separate domain. If you would rather see the whole setup run for your market than build it, you can see what a campaign would look like.
Specification behaviour verified against the RFC texts cited below as of August 2026. Mailbox-provider reputation handling is not published by the providers and is described here only where it can be stated without inference.
Frequently asked questions.
Frequently asked questions- Do I need a separate SPF record for my email subdomain?
- Yes. RFC 7208 discusses publication in terms that require the declaration to be repeated for any host with records and for subdomains of it, so nothing cascades down from the root. A subdomain sending mail without its own SPF record has no SPF policy at all, and the record at the parent domain does not cover it.
- Does a subdomain inherit the parent domain DMARC policy?
- Yes, and this is the one mechanism that does inherit. RFC 7489 policy discovery queries the DMARC record at the From domain first, then falls back to the Organizational Domain record when the first query returns nothing usable. The parent can set a different policy for subdomains with the sp tag, which applies only to subdomains.
- Should cold outbound go from a subdomain or a separate domain?
- A separate domain. A subdomain keeps the Organizational Domain, so it shares alignment and DMARC policy with the brand, which is right for marketing and transactional mail. Cold outbound is the pattern most likely to attract complaints, and the primary domain is the asset that should not be carrying it. We run client campaigns from separate domains for that reason.
- Is a tracking subdomain the same as a sending subdomain?
- No, and conflating them causes confusion because both appear in the same DNS zone on the same afternoon. A custom tracking domain serves link redirects and needs a hostname that resolves plus a matching certificate. A sending subdomain needs SPF, DKIM and DMARC. Neither set of records helps the other job.
About the author.
Tim Carden is CMO / CTO at RevenueFlow, which builds and operates outbound revenue engines for B2B companies. Studied at McGill University.
Tim Carden · CMO / CTO
Connect on LinkedIn →Explore more.
Ready to scale your outreach?
We build GTM engines that book real meetings. See the receipts.
Related articles.
How to Bypass a Spam Filter: The Only Method That Works, and Who Holds It
One reliable bypass exists and the recipient's administrator holds it. What the admin controls actually do, and why sender-side bypass tactics make placement worse.
Google Spam Filter for B2B Teams: Diagnosing Placement Without Guesswork
Google publishes what it wants from senders, and the list is short and checkable. What binds a B2B sender, which spam rate to watch, and what to do when placement drops.
Third-party Spam Filter: Diagnosing Placement Without Guesswork
A filter your recipient bought sits between you and their mailbox. It can break your DKIM signature, substitute its own address for yours, and quarantine in silence.
The GMass SMTP Test: What a Passing Connection Does Not Prove
GMass publishes a free SMTP connection tester that anyone can use. What its four stages separate, why the last one gets misdiagnosed, and where the tool's boundary is.
SMTP for Yahoo: The Settings Take a Minute, the Sender Requirements Do Not
Yahoo publishes its outgoing settings in six lines. It also publishes sender requirements enforced since February 2024, and refuses to name the volume that triggers them.
SMTP Ports: What 25, 465, 587 and 2525 Are Actually Registered For
Three of the four ports in circulation are registered to mail and one is not. What the IANA registry and the RFCs say, and why none of it moves placement.