Subdomains and DMARC: The sp= Tag and the Forgotten Subdomain Problem

Subdomains inherit the DMARC policy of their organisational domain unless you say otherwise. The sp= tag on _dmarc.yourcompany.co.za sets the policy for every subdomain without its own record, and when sp= is absent, subdomains follow p=. A subdomain that publishes its own DMARC record overrides both. The common gap is sp=none, which leaves every subdomain spoofable.

How DMARC inheritance works

When a receiving server gets a message with From: billing@invoices.yourcompany.co.za, it looks for a DMARC record in two places. First at the exact domain, _dmarc.invoices.yourcompany.co.za. If nothing is there, it falls back to the organisational domain, _dmarc.yourcompany.co.za.

The organisational domain is the registered domain: the part directly below a public suffix. Because co.za is itself a public suffix, the organisational domain for mail.yourcompany.co.za is yourcompany.co.za, not co.za. Receivers work this out using the Public Suffix List, which is why .co.za, .org.za and similar second-level registrations behave exactly like .com for DMARC purposes.

Under the current DMARC specification (RFC 7489) the lookup does not walk through intermediate levels. Mail from a.b.yourcompany.co.za checks _dmarc.a.b.yourcompany.co.za and then _dmarc.yourcompany.co.za; a record at _dmarc.b.yourcompany.co.za is not consulted. Keep subdomain structures shallow where you can, and test deeper names before relying on them.

Alignment follows the same organisational logic. Under the default relaxed alignment, a DKIM signature with d=yourcompany.co.za aligns with mail from news.yourcompany.co.za, and vice versa, because both share an organisational domain. DMARC alignment explained covers this in detail.

What the sp= tag does

The sp= tag only has meaning on the organisational domain’s record. It sets the policy for subdomains that fall back to that record. It accepts the same values as p=: none, quarantine or reject.

Two practical consequences follow. First, if you omit sp=, your subdomains move to enforcement at the same moment as your main domain, which is usually what you want, provided you have checked that no subdomain sends unaligned mail. Second, sp= can be stricter than p=. Many organisations never send from most subdomains, so it is perfectly reasonable to set sp=reject while the main domain is still at p=quarantine.

The forgotten subdomain problem

One of the most common patterns in published DMARC records is p=reject; sp=none. Somebody moved the main domain to enforcement but was worried about breaking a subdomain sender, so they exempted every subdomain. The worry was reasonable. The fix was not, because it was never revisited.

The effect is that yourcompany.co.za is protected, while accounts.yourcompany.co.za, payments.yourcompany.co.za and secure.yourcompany.co.za are not. Those names do not need to exist in DNS for an attacker to put them in a From address, and to a supplier reading a payment request, a subdomain of your real domain looks more trustworthy, not less. Attackers can find sp=none as easily as you can: your DMARC record is public.

The same gap appears when a subdomain publishes its own record at p=none for a one-off campaign and is then forgotten, or when a marketing platform’s setup guide suggests a monitoring-only record on its sending subdomain.

Part of the reason these gaps survive is that they are quiet. A spoofed subdomain at sp=none produces no bounce, no complaint and no alert. The only trace is a row in an aggregate report showing a subdomain you do not recognise, sent from an IP address you do not use, with a disposition of none. If nobody reads the reports, nobody sees it. That is why subdomain policy deserves a scheduled review rather than a one-off decision made during the first rollout.

Subdomains that send mail

Subdomains are a sound way to separate mail streams. Common patterns include:

• news.yourcompany.co.za or mail.yourcompany.co.za for newsletters and marketing.
• notify.yourcompany.co.za for system alerts and transactional mail from an application.
• bounce.yourcompany.co.za as a custom return-path for a third-party platform.
• A separate subdomain for a division or brand that runs its own mail platform.

Each sending subdomain needs its own SPF record if it is used as a return-path or envelope domain, and its own DKIM records if a platform signs as it. SPF does not inherit: v=spf1 on yourcompany.co.za says nothing about news.yourcompany.co.za. That is a benefit, because a subdomain’s SPF lookups do not count against your main record’s 10-lookup limit, which is one reason bulk senders move there. For the wider picture on third-party platforms, see the services that send as you.

Whether a sending subdomain should publish its own DMARC record depends on timing. If it is aligned and ready at the same time as the main domain, inheritance is simpler. If it needs a different pace, give it its own record so it can progress separately, rather than holding every other subdomain back with sp=none.

Designing a subdomain policy

A practical decision framework:

The key move is the third row. Exempting one named subdomain with its own record is targeted and visible. Exempting all subdomains with sp=none is broad and easily forgotten.

Point every subdomain record’s rua at the same reporting address as the main domain, so all your data lands in one place. Aggregate reports for subdomains that inherit policy are already sent to the organisational domain’s rua, and they show the exact From domain, so you can see subdomain traffic without extra records. Reading them is covered in how to read a DMARC report.

A worked example

Consider a business that sends day-to-day mail from Microsoft 365 on yourcompany.co.za, newsletters from a marketing platform on news.yourcompany.co.za, and nothing from any other subdomain. After a month of monitoring, the main domain is fully aligned but the newsletter platform has not yet had its custom DKIM set up.

The tempting record is:

v=DMARC1; p=quarantine; sp=none; rua=mailto:reports@yourcompany.co.za

It protects the main domain and leaves every subdomain open, including the dozens of plausible names that do not exist. The better pair of records is:

_dmarc.yourcompany.co.za: v=DMARC1; p=quarantine; sp=reject; rua=mailto:reports@yourcompany.co.za

_dmarc.news.yourcompany.co.za: v=DMARC1; p=none; rua=mailto:reports@yourcompany.co.za

Now the main domain is at quarantine, every subdomain except one is at reject, and the newsletter subdomain is explicitly in monitoring with its reports flowing to the same place. Once the marketing platform signs with an aligned DKIM key and the reports confirm it, the newsletter record moves through quarantine to reject on its own schedule, or is deleted so it simply inherits.

The difference between the two approaches is not technical complexity, it is visibility. The second design names its exception, so anyone reading the DNS later can see exactly what is unprotected and why. The first hides the exception inside a single tag that applies far more widely than anyone intended. The staged progression itself, with approval and a rollback path at each step, follows the same pattern described in moving from p=none to p=reject.

Subdomain checklist

1. Look up your organisational domain record and note p= and sp=.
2. Search your aggregate reports for any header From domain that is a subdomain.
3. List every subdomain that legitimately sends and confirm each one aligns via DKIM or SPF.
4. Check for DMARC records published on subdomains, and whether any are stuck at p=none.
5. Replace any sp=none with either inheritance or a named exception.
6. For subdomains that never send, consider an explicit v=spf1 -all where they have other DNS records such as a website, so the name cannot be used as an envelope domain.
7. Record the decisions and review them whenever a new platform is onboarded.

How MailMarq helps

MailMarq reviews subdomain traffic as part of every assessment and designs policy so that your subdomains are protected alongside the main domain, with named exceptions only where the evidence calls for them. The Velocity package covers up to 10 domains of one organisation plus 2 subdomains. Compare the packages or ask us to review your record.

Frequently asked questions

MailMarq
MailMarq is a managed DMARC service run from Johannesburg. Our team has built and managed business websites, hosting and email infrastructure for South African companies since 2016, and writes these guides from work on real domains.