Subdomains and wildcards: what secondary names inherit (and what they do not)

A domain is more than its base name. The subdomains used for marketing mail (news.example.com), application notifications (app.example.com), bounces (bounce.example.com) or simply created by third-party tools each follow different inheritance rules depending on the mechanism. Understanding what propagates and what does not avoids two symmetrical mistakes: believing a subdomain is protected when it is not, and letting a DNS wildcard answer in place of records that were never published.

SPF: no inheritance#

An SPF record only applies to the exact name it is published on. If example.com publishes v=spf1 ... -all and a message leaves with MAIL FROM on news.example.com, the provider queries news.example.com and, finding no record, gets the result none. Every subdomain used in MAIL FROM or HELO therefore needs its own record. Conversely, a subdomain that never sends should publish v=spf1 -all to close the door explicitly.

news.example.com.    IN TXT  "v=spf1 include:_spf.esp.example.net -all"
bounce.example.com.  IN TXT  "v=spf1 include:_spf.esp.example.net -all"
intranet.example.com. IN TXT "v=spf1 -all"

DKIM: it all depends on d=#

A DKIM signature is verified with the key published under <selector>._domainkey.<d=>. A provider signing with d=news.example.com needs the key published under _domainkey.news.example.com, and that signature aligns with a From: on news.example.com or, in relaxed mode, on example.com. The t=s tag in the key record forbids using the key for a subdomain of d=; without it, a key published on example.com can be used to sign d=example.com on messages whose From: is on a subdomain.

DMARC: the policy propagates, with sp= and np=#

DMARC is the only one of the three mechanisms with built-in inheritance. A provider looks up _dmarc.news.example.com; if it does not exist, it applies the policy of the organisational domain example.com, using the value of sp= (subdomains) or, failing that, p=. DMARCbis adds np=, which applies to subdomains that do not exist in DNS, allowing for instance p=quarantine; sp=quarantine; np=reject.

_dmarc.example.com.       IN TXT  "v=DMARC1; p=reject; sp=quarantine; np=reject; rua=mailto:dmarc@example.com"
_dmarc.news.example.com.  IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-news@example.com"

A subdomain publishing its own policy overrides sp=. That is the right tool to isolate a stream: a marketing provider can have its own policy and reports without touching the main domain. Conversely, a domain at p=reject with no sp= already protects all its subdomains, existing or not.

DNS wildcards: an answer for every non-existent name#

A *.example.com record answers for any name that does not exist under example.com, at any depth, unless a closer enclosing name exists. The consequences for mail are often unintended:

• A *.example.com IN MX makes any made-up subdomain routable, and a * IN A does the same for the SPF a mechanism.
• A *.example.com IN TXT "v=spf1 -all" is sometimes used to close SPF on every subdomain: it works for non-existent names, but not for subdomains that already have a record of another type (an A without a TXT, say); those exist in DNS terms and the wildcard no longer applies.
• The same wildcard TXT also answers queries for _dmarc.anything.example.com and selector._domainkey.anything.example.com. DMARC and DKIM verifiers ignore records that do not start with the right version tag, but some diagnostic tools report an anomaly.
• A wildcard CNAME is even more invasive: it redirects every query, including _dmarc and _domainkey, to the target.

The practical rule: use a wildcard only for the web purpose that justifies it, and always check with dig what a random name under the domain returns for the MX, A, TXT and CNAME types.

Non-existent subdomains and impersonation#

An attacker can send with From: accounts@invoice.example.com even if invoice.example.com never existed. Without DMARC on the organisational domain, nothing stops them. With p=reject or sp=reject, the message is rejected since no authentication can align. That is the main argument against leaving sp=none, and for publishing np=reject as soon as verifiers support it.

Good practice#

1. Keep an inventory of sending subdomains, with for each: purpose, MAIL FROM, DKIM selectors, provider.
2. Publish SPF on every sending subdomain and v=spf1 -all on those that do not send.
3. Publish a dedicated _dmarc on subdomains with a distinct stream, with their own reports.
4. Set sp= explicitly on the organisational domain, at least as strict as p=.
5. Do not delegate an entire subdomain to a provider without checking which policies it publishes there.
6. For inbound mail, remember that MTA-STS applies per domain: a subdomain that receives mail needs its own policy.

What SenderRadar shows#

SenderRadar presents the subdomains associated with a domain when they can be identified, the state of SPF, DKIM and DMARC on each, the effective subdomain policy inherited from the organisational domain, and flags DNS wildcards likely to interfere with authentication records. SenderRadar relies on its own analysis base to set these elements against the main domain's configuration.

References#

• RFC 7208 – SPF
• RFC 6376 – DKIM
• RFC 7489 – DMARC and DMARCbis (DMARC working group)
• RFC 4592 – The Role of Wildcards in the Domain Name System