Subdomains can be as spoof-able as the parent domain if DMARC is not configured for them. The sp= tag and per-subdomain DMARC records control this. This article explains how DMARC discovers policies for subdomains, the role of the sp= tag, when to publish dedicated subdomain records, and how to harden non-sending subdomains for UK businesses.
sp= tag explainedConsider a UK firm that publishes a strong DMARC record at firm.co.uk — p=reject; adkim=s; aspf=s. An attacker cannot spoof [email protected]. But what about [email protected], a subdomain the attacker has discovered exists (or simply invented)?
If no _dmarc.billing.firm.co.uk record exists and the parent record does not specify sp=, DMARC's inheritance rules kick in — and in some edge cases the subdomain ends up unprotected. The attacker sends From: [email protected] with their own DKIM/SPF on their own domain, passes authentication on their own domain, and the recipient sees a convincing brand-subdomain spoof.
The sp= tag and dedicated subdomain records are how UK businesses close this gap.
When a receiver evaluates DMARC for a message from [email protected], it follows this sequence:
_dmarc.billing.firm.co.uk. If a record exists, use it.firm.co.uk) and query _dmarc.firm.co.uk.sp= tag, apply that policy to the subdomain.sp=, apply the parent's p= policy.This tree-walk is the RFC 7489 behaviour. DMARCbis drafts adjust some of the mechanics but preserve the spirit: subdomains inherit from the organisational domain unless they publish their own.
sp= tag explainedThe sp= tag lets the parent's DMARC record specify a separate policy for subdomains without forcing every subdomain to publish its own record. Permitted values are the same as p=:
sp=none — no subdomain enforcement; subdomain mail delivered regardless.sp=quarantine — subdomain mail failing DMARC goes to spam.sp=reject — subdomain mail failing DMARC is rejected.If sp= is omitted, subdomains inherit the parent's p= value. Best practice is to publish sp= explicitly to make the intent visible in DNS.
Common production pattern for a UK business:
_dmarc.firm.co.uk. IN TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:[email protected]"Parent and all subdomains at p=reject. No wiggle room for attackers.
A subdomain that publishes its own _dmarc record completely overrides the parent's sp= and p=. This is useful when:
news.firm.co.uk) may need p=quarantine during its own rollout while the main domain is already at p=reject.Example: a UK consultancy runs firm.co.uk for staff email and news.firm.co.uk for monthly newsletters. Staff mail is strict:
_dmarc.firm.co.uk. IN TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:[email protected]"Newsletter subdomain is currently at quarantine, being rolled out to reject:
_dmarc.news.firm.co.uk. IN TXT "v=DMARC1; p=quarantine; pct=50; rua=mailto:[email protected]"Both coexist. Receivers apply the most specific record they find.
_dmarc.firm.co.uk. IN TXT "v=DMARC1; p=reject; sp=reject; ..."Simplest. All subdomains (sending or not) subject to reject policy. Suitable for organisations with few actively-used subdomains.
_dmarc.firm.co.uk. TXT "v=DMARC1; p=reject; sp=quarantine; ..."
_dmarc.news.firm.co.uk. TXT "v=DMARC1; p=quarantine; pct=100; ..."
_dmarc.invoices.firm.co.uk. TXT "v=DMARC1; p=reject; ..."
_dmarc.alerts.firm.co.uk. TXT "v=DMARC1; p=reject; ..."Fine-grained control. Suitable for larger operations with distinct sender classes and different risk profiles per class.
_dmarc.firm.co.uk. TXT "v=DMARC1; p=reject; sp=reject; ..."
_dmarc.firm-consulting.co.uk. TXT "v=DMARC1; p=reject; sp=reject; ..."
_dmarc.firm-capital.co.uk. TXT "v=DMARC1; p=quarantine; sp=quarantine; ..."Each brand domain (top-level separate registration) gets its own DMARC independently. Subdomains of each inherit from their parent's sp=.
Subdomains that never send legitimate email are the most common spoofing targets — attackers probe for subdomains and often find undefended ones. Lock them down:
subdomain.firm.co.uk IN TXT "v=spf1 -all"*._domainkey.subdomain.firm.co.uk IN TXT "v=DKIM1; p="_dmarc.subdomain.firm.co.uk: "v=DMARC1; p=reject; rua=mailto:..."Three records per non-sending subdomain. If you have many, the work adds up — but it makes every one of them immune to spoofing.
For organisations with dozens of non-sending subdomains, set sp=reject on the parent and rely on inheritance. That gives most of the protection without per-subdomain publication — though it does not publish per-subdomain SPF, so attackers can still pass SPF on their own domain and only DMARC alignment blocks them.
RFC 7489 defines a specific tree-walk: when a message's From: is at a subdomain, the receiver queries the subdomain's _dmarc record first, then walks up to the organisational domain. DMARCbis refines this by clarifying behaviour in edge cases (multi-level subdomains, wildcards) but retains the general pattern.
Practical takeaway for UK deployments: publish DMARC at every level of the tree where you care about the policy. Inheritance via sp= works but explicit publication is less ambiguous.
A periodic audit for any UK business with multiple subdomains:
_dmarc.subdomain. Record whether it has its own record or inherits from parent.sp= is what you intended.DMARC processing services with multi-domain dashboards make this audit a single-click exercise.
sp=reject) applies across all subdomains by default. Additional subdomains that need separate DMARC records can be added independently.
Many UK organisations roll out DMARC parent-first, subdomains-later. The pattern works:
p=none, then quarantine, then reject.sp=none during parent rollout to avoid accidentally blocking subdomain mail.p=reject, begin subdomain audit.p=none and monitor.sp= to match.This staged approach prevents the common failure mode where sp=reject blocks subdomain mail before subdomain senders are properly configured.
For subdomains that simply share the parent's mail infrastructure — support.firm.co.uk, hr.firm.co.uk pointing at the same servers — the parent's SPF, DKIM selectors and DMARC cover them adequately as long as sp= is set appropriately. No separate subdomain record is needed.
Subdomains entirely operated by third parties (for example news.firm.co.uk CNAMEd to a marketing platform's sending infrastructure) should have their own DMARC record reflecting the third party's authentication posture. The parent's sp= would otherwise apply the wrong policy.
Attackers enumerate subdomains using several techniques:
accounts, billing, payments, hr, support, noreply, email) against the domain.Knowing that enumeration is comprehensive, the defence is simple: every discoverable subdomain needs DMARC coverage, either through its own record or through inherited sp=. No subdomain should be discoverable-but-undefended.
Q: Do I need sp= if my p= already covers the intent?
A: Publishing sp= explicitly makes the intent visible and removes any ambiguity. Some receivers handle implicit inheritance differently in edge cases. Explicit is safer.
Q: What if a subdomain's _dmarc record is weaker than the parent's sp=?
A: The subdomain's own record wins. A subdomain at p=none overrides a parent's sp=reject. Audit subdomain records to catch legacy p=none entries that would leak through.
Q: Can I publish DMARC at a wildcard subdomain (*.firm.co.uk)?
A: DMARC lookups are at specific names (_dmarc.subdomain), not at the subdomain itself. A wildcard _dmarc does not typically work as expected. Use sp= on the parent instead.
Q: Does sp= apply to every level of subdomain (sub.sub.firm.co.uk)?
A: Yes — when no intermediate DMARC record exists, the tree walks up to the organisational domain and applies sp=. Intermediate records short-circuit the walk.
Q: What is the interaction between sp= and pct=?
A: pct= on the parent record applies to both p= and sp= policies. If you want different percentages for parent and subdomains, publish separate subdomain records.
Q: How do I protect a subdomain my business never uses but that exists in DNS?
A: Publish three records: null SPF, null DKIM, and a DMARC record at the subdomain with p=reject. Or simply remove the subdomain from DNS if it genuinely has no purpose.
Q: Do attackers commonly target undefended subdomains?
A: Yes. Subdomain probing is routine — attackers enumerate common names (accounts, invoices, billing, alerts, no-reply) and target the ones that return NXDOMAIN without DMARC coverage.
Q: What about subdomains inside a CNAME chain?
A: DMARC lookups resolve CNAMEs normally. If news.firm.co.uk is a CNAME to news-provider.net, the DMARC lookup for _dmarc.news.firm.co.uk evaluates based on your DNS, not the CNAME target's.
Q: Is it acceptable to leave sp=none while the parent is at p=reject?
A: Only if you consciously want subdomains to have weaker enforcement (for example during a staggered rollout). Otherwise, publish matching enforcement for consistency.
Q: Does sp= affect reporting?
A: No — reporting addresses (rua, ruf) always come from the parent record (or the subdomain's own record if one exists). sp= controls enforcement policy only.
Q: How common is subdomain spoofing compared to main-domain spoofing?
A: Rising. As main-domain DMARC coverage improves across UK businesses, attackers pivot to subdomains. Aggregate reports increasingly show subdomain-based spoofing volumes that rival the main domain's.
Q: Should a subdomain's DMARC record include its own sp=?
A: If it has its own sub-subdomains (child.subdomain.firm.co.uk), yes. Otherwise sp= is redundant — most subdomains are leaf nodes with no children.
Q: What is the fastest way to add DMARC coverage to dozens of non-sending subdomains?
A: Set sp=reject on the parent. Combined with p=reject, this gives immediate coverage across all subdomains without per-subdomain publication. Follow up over time with individual records where specific subdomains need custom policies.
Q: If a subdomain publishes DMARC but its parent does not, what happens?
A: The subdomain's record applies to mail from that specific subdomain. Mail from other subdomains (without their own records) falls through to the parent — which has no DMARC, so it is unprotected. Publish DMARC at every level, starting with the organisational domain.
Q: Does setting sp=reject on the parent require any SPF or DKIM configuration on subdomains?
A: No. sp=reject just tells receivers to reject subdomain mail that fails DMARC. Whether subdomain mail passes or fails depends on whatever SPF/DKIM setup that subdomain has — which may be inherited or subdomain-specific.
Q: Can I use sp= to let subdomain mail bypass parent enforcement temporarily?
A: Yes — sp=none weakens enforcement for subdomains while the parent stays strict. Occasionally useful during rollouts when subdomains have legacy senders not yet authenticated. Tighten sp= as you fix each subdomain's senders.
Q: Are there any NCSC UK recommendations around subdomain policy?
A: NCSC guidance expects central government domains to apply DMARC across the whole domain tree, including subdomains. sp=reject is the expected posture. Local authorities and NHS suppliers are expected to follow.
Q: Does sp= apply to every nested subdomain level or only the first?
A: Every level. A DMARC lookup for foo.bar.baz.firm.co.uk walks all the way up and applies sp= from the first record it finds (the organisational domain's _dmarc, typically).
Q: Can I test subdomain DMARC without waiting for real traffic?
A: Yes — use a DMARC record validator (MXToolbox, dmarcian, NCSC Mail Check) that queries your subdomain's _dmarc and reports the effective policy. These tools simulate the tree-walk without needing live mail.
Q: How does DMARCbis change subdomain handling?
A: DMARCbis introduces a more explicit tree-walk algorithm and deprecates some edge-case behaviour around the organisational domain determination. Net effect on UK deployments: neutral-to-positive — existing records continue to work, with slightly clearer specification.
Q: What is a reasonable subdomain DMARC audit cadence?
A: Quarterly for stable organisations; monthly if subdomains are being added regularly (new product launches, marketing campaigns). Automate DNS scanning if possible.
Q: Should internal subdomains (intranet.firm.co.uk, etc.) publish DMARC?
A: If they ever send email to external recipients — yes. If they are purely internal with mail never leaving the corporate network, DMARC has nothing to act on, but publishing a restrictive record defends against any accidental external leakage or spoofing attempts.
Q: Does sp= interact with DNSSEC?
A: No — sp= is a DMARC tag, DNSSEC is about DNS integrity. Publishing both is best practice but they are independent layers.
Q: Can attackers register a similar subdomain I do not own and publish their own DMARC there?
A: Subdomains are delegated from the parent zone which you control — attackers cannot publish DMARC at anything.firm.co.uk unless they compromise your DNS. They can, however, register similar-looking top-level domains (firm-co-uk.com) — a separate problem (lookalike domains) addressed by registry monitoring, not DMARC.
Q: How quickly do changes to sp= take effect?
A: As quickly as DNS propagation — usually within an hour for standard TTLs. Receivers then pick up the new policy on their next DMARC lookup.
Q: If my domain is being resold to third parties through subdomains (white-label hosting), who owns subdomain DMARC?
A: Technical control remains with the DNS operator (usually you). Operationally, you may want to publish loose sp= or per-subdomain records tailored to the third party's authentication practices. Coordinate explicitly.
Q: What happens with deeply nested subdomains like d.c.b.a.firm.co.uk?
A: DMARC lookup walks from the deepest level upward. If any level has a _dmarc record, that wins. Otherwise, the organisational domain's sp= applies. Deeply nested subdomains usually have no DMARC record, so organisational sp= is what matters.