DMARC for Subdomains: How the sp Tag Protects Your Domain

Short answer: A DMARC record on your main domain also covers its subdomains. Mail from a subdomain such as billing.yourdomain.com is judged by the sp= policy in the parent record, or by p= if sp= is absent, unless the subdomain publishes its own DMARC record. Use sp=reject (or an enforcing p= without sp=) so criminals cannot spoof subdomains you never use, and give sending subdomains their own authentication and, if needed, their own DMARC record.

Why subdomains matter for spoofing

When businesses secure e-mail, they usually focus on the main domain: yourdomain.com. Attackers know this. A message from invoices.yourdomain.com or secure.yourdomain.com looks just as official to most recipients, and the subdomain does not need to exist in DNS for a criminal to put it in a From address.

If your DMARC setup only enforces a policy for the main domain and leaves subdomains unprotected, spoofed mail from invented subdomains can pass through receivers that would reject the same message from the main domain. The sp= tag exists precisely to close that gap.

Subdomains also appear naturally in business mail. Marketing platforms, helpdesks and transactional services often recommend a dedicated subdomain for sending, and large organisations delegate subdomains to departments or brands. Each of these legitimate uses needs the right policy, while every name you do not use should be closed to abuse. Getting both right is mostly a matter of understanding how DMARC chooses which policy to apply.

How DMARC finds the policy for a subdomain

When a receiver gets a message with a From address on a subdomain, it looks for a DMARC record in this order:

1. At the subdomain itself: _dmarc.billing.yourdomain.com. If a record exists, its p= policy applies.
2. At the organisational domain: _dmarc.yourdomain.com. If there is no record at the subdomain, the receiver uses the parent’s record and applies its sp= policy, or its p= policy if sp= is not set.

Two details are worth knowing. First, the lookup always goes to the organisational domain, not to every level in between: for a.b.yourdomain.com without its own record, the receiver checks _dmarc.yourdomain.com, not _dmarc.b.yourdomain.com. Second, the report addresses in the parent record also receive reports about subdomain mail that falls under it, so one mailbox can give you visibility across the whole domain.

This is why a single well-configured record on the main domain can protect every subdomain, and why a careless sp=none can undo the protection for all of them.

Common configurations compared

The fourth row is a useful trick that many people miss. While you are still collecting reports and fixing senders on the main domain, you can already reject spoofed mail from subdomains, provided none of your legitimate mail uses a subdomain From address without proper authentication.

Subdomains that send legitimate mail

If you send newsletters from news.yourdomain.com or notifications from mail.yourdomain.com, those subdomains must pass DMARC under whichever policy applies to them. Make sure that:

• the sending platform signs with DKIM for the subdomain or for the main domain (relaxed alignment accepts either);
• if SPF is used for alignment, the envelope sender is on the subdomain or the main domain and the subdomain’s SPF record, or the return-path’s record, authorises the platform;
• DMARC reports show the subdomain’s mail passing before you enforce.

Once these are true, the subdomain can safely sit under an enforcing policy just like the main domain.

If a platform insists on signing with its own domain and cannot be configured otherwise, do not solve it by weakening the policy for all subdomains. Either use the platform’s own From domain, or publish a temporary, separate DMARC record for just that subdomain while you look for a better tool.

When to give a subdomain its own DMARC record

A separate record at _dmarc.subdomain makes sense when:

• A different team or vendor manages the subdomain and needs its own report address.
• The subdomain is still being rolled out and needs p=none temporarily while the main domain is already at p=reject. This is cleaner than weakening sp= for all subdomains.
• You want separate reporting to see the subdomain’s traffic on its own.

Remember that a subdomain record overrides the parent completely for that subdomain, including its policy. Do not publish p=none on a subdomain and forget it there.

Subdomains that do not exist

Attackers do not need your subdomains to exist. They can invent any name. The parent record’s sp= (or p=) covers these invented names too, because receivers fall back to the organisational domain’s record when no subdomain record is found.

A newer part of the DMARC work at the IETF also discusses how receivers should treat non-existent subdomains specifically, and some receivers already apply extra suspicion to mail from names that have no DNS records at all. Regardless, the practical step for you is the same: make sure the policy that covers subdomains is enforcing.

In other words, you do not need to predict which names an attacker might invent. One enforcing policy at the organisational domain covers all of them at once, including names that will never appear in your DNS.

For extra hardening of subdomains that exist in DNS but never send mail, such as www, shop or cdn, you can also publish v=spf1 -all on them. That makes SPF fail explicitly for any attempt to use them as envelope senders.

Common subdomain mistakes

• A forgotten sp=none. Someone added it during an early rollout to be cautious, the main policy later moved to p=reject, and every subdomain stayed unprotected for years.
• Subdomain records copied from a template with p=none, published by a vendor’s setup guide and never revisited.
• Sending subdomains without authentication. A helpdesk uses support.yourdomain.com as the From domain, but only the main domain was configured in the tool, so its mail fails DMARC as soon as the subdomain policy is enforced.
• Assuming subdomains are separate domains. Some administrators believe that a subdomain without its own record is unprotected. In fact it inherits the parent’s policy, which is exactly what you want when that policy is strict.
• Report addresses on subdomain records pointing to mailboxes that no longer exist, so failures on that subdomain go unnoticed.

Each of these is visible with a few DNS lookups and a glance at DMARC reports. Adding subdomains to your regular e-mail review takes minutes and closes a gap that attackers actively look for.

Checking your subdomain coverage

1. Look up your main DMARC record: dig TXT _dmarc.yourdomain.com +short. Note p= and sp=.
2. List the subdomains that send mail, from your inventory and DMARC reports.
3. Check each sending subdomain for its own DMARC record: dig TXT _dmarc.news.yourdomain.com +short.
4. Confirm that no subdomain record says p=none unintentionally.
5. Send test messages from each sending subdomain and check dmarc=pass in the headers.
6. Review DMARC reports for failures on subdomain From addresses; unknown subdomain sources are often spoofing attempts.

Where subdomain policies fit in your rollout

A practical order for most businesses: publish DMARC on the main domain with p=none and sp=reject if no subdomain sends mail yet, fix the main domain’s senders using reports, add proper authentication for any sending subdomain, then move p= to quarantine and reject. At the end, sp= can simply be removed or left as reject, and both main domain and subdomains are protected.

Site AI Audit checks whether your domain publishes DMARC and which policy it sets, together with SPF (including the lookup limit), DKIM and MX records, and explains each finding in plain words. A free check is a quick way to confirm the main record; paid plans keep watching it and alert you when it changes.

Related reading

• DMARC Explained: Policies, Alignment and a Safe Rollout
• Email Spoofing: How to Stop People Sending Mail as Your Domain
• Should You Send Marketing Email from a Subdomain? Pros and Cons

The bottom line

Subdomains are covered by your main DMARC record unless they publish their own. Make sure the policy that applies to them enforces, using sp=reject or an enforcing p= without a weaker sp=. Authenticate every subdomain that sends mail, give it its own DMARC record only when there is a clear reason, and never leave a forgotten p=none on a subdomain.

الأسئلة الشائعة

What does the sp tag in DMARC do?

It sets the policy for subdomains of the domain where the record is published. If sp is absent, subdomains follow the main p policy.

Do subdomains need their own DMARC record?

Not necessarily. The parent record covers them. A separate record is useful when a subdomain needs a different policy or report address.

Can attackers spoof subdomains that do not exist?

Yes, they can put any subdomain in a From address. Your parent DMARC record’s subdomain policy decides how receivers treat such mail, so it should be enforcing.

Is sp=reject safe if I send newsletters from a subdomain?

Yes, once the newsletter platform is authenticated and aligned for that subdomain. Confirm in DMARC reports and headers before enforcing.

Can I use p=none with sp=reject?

Yes. It protects unused subdomains while you are still monitoring the main domain, provided no legitimate mail uses unauthenticated subdomain addresses.

Does a subdomain DMARC record override the parent?

Yes. If a record exists at the subdomain, its own p policy applies to that subdomain instead of the parent’s sp or p.