p=reject Without sp= Still Gets Subdomains Spoofed

A company recently published a DMARC record with `p=reject` - one of the strictest available policies - and still got impersonated. The emails weren't coming from their main domain. They were coming from a subdomain the company had set up for a third-party marketing tool years earlier, then forgotten about.

The attacker registered the undelegated subdomain before the company could, and sent phishing emails that passed SPF checks. DMARC rejected nothing because the subdomain wasn't covered by the parent's `p=reject` policy. The company's brand was being used to target their own customers.

---

The Scenario: p=reject, No sp=, Spoofed Anyway

The company did everything the standard advice recommends. They set up SPF, DKIM, and DMARC with `p=reject` on their primary domain. They thought they were protected.

What they didn't do was set an `sp=` tag.

Without `sp=`, a DMARC policy only governs the exact domain it is published on. It says nothing about subdomains. So when someone sends mail from `marketing.company.com` or `app.company.com`, the receiving mail server evaluates those domains against their own SPF and DKIM records - not against the parent domain's DMARC policy.

In this case, the marketing subdomain had been handed off to a third-party platform years earlier. The company stopped using the platform but never cleaned up the DNS records. When the platform's servers were decommissioned, the subdomain's infrastructure lapsed. An attacker noticed the gap, registered the subdomain through a dropped DNS delegation, and started sending authentic-looking phishing emails.

The company's DMARC record didn't help because it was only protecting the apex domain.

---

Why Undelegated Subdomains Fall Outside Your DMARC Policy

DNS delegation is the mechanism that hands a subdomain to a different set of nameservers. When you delegate `marketing.company.com` to a third party's nameservers, you are telling DNS: "everything under this branch is now managed elsewhere."

Your DMARC record on `company.com` stops at the delegation boundary. Receivers evaluating mail from `marketing.company.com` will only check the DMARC record (if any) published for `marketing.company.com` - not the one on `company.com`. If there is no DMARC record on the subdomain, there is no DMARC policy to enforce.

This is defined in RFC 7489, Section 6.6.3. The policy at the parent domain does not cascade downward to delegated subdomains unless you explicitly tell it to with an `sp=` tag.

The practical consequence: if you delegate a subdomain and something inside that delegation goes wrong - a service gets abandoned, a vendor relationship ends badly, a DNS record lapses - your parent domain's `p=reject` provides no protection.

---

How the Attack Works in Practice

The sequence is straightforward and requires no special technical skills to execute:

The attacker identifies a company with `p=reject` on their main domain but no `sp=` tag in the record.
They enumerate the company's delegated subdomains, looking for ones that are no longer actively maintained. Common targets include `newsletter`, `offers`, `marketing`, `crm`, `support`, and historical tool subdomains.
They check whether those subdomains still have valid DNS delegations and active services.
If a delegation has lapsed - the third party decommissioned the service, the contract ended, or the DNS was simply abandoned - the attacker registers the subdomain through a dropped domain service or contacts the relevant registrar.
They configure the subdomain's SPF record to point to a server they control and start sending email.

Receiving mail servers see SPF pass (the mail comes from the attacker's server, which now matches the subdomain's SPF record). They see DKIM fail or not present (the subdomain has no DKIM record). And DMARC fails - but only if the subdomain has a DMARC record that explicitly checks alignment. Without one, the receiver has no policy to apply, and the mail is accepted.

The result: emails that appear to come from the company's domain, pass SPF, and bypass DMARC entirely because the subdomain was never covered by the parent's policy.

---

Who Usually Has This Problem

This gap is common in organisations that have accumulated email infrastructure over years or decades.

The most frequent causes:

Third-party marketing tools. Platforms for email newsletters, promotions, or customer communications often require you to delegate a subdomain to their nameservers. When the contract ends but the DNS isn't cleaned up, the delegation can persist long after the service is gone.

Cloud and SaaS onboarding. Some cloud platforms ask customers to create subdomains and delegate them during setup. The operations team may not track these once the initial engineer leaves.

Internal tools with external hosting. Subdomains for internal applications that were hosted externally, decommissioned, and never cleaned up.

M&A activity. Companies that merged or were acquired often have duplicate email infrastructure where subdomains from the acquired company's DNS are partially maintained but no longer monitored.

In most of these cases, the original stakeholders knew about the subdomains. The problem emerges years later when the domain portfolio hasn't been reviewed and those delegations have quietly become dangling assets.

---

How to Close the Gap - sp=, Wildcard, or Both

Option 1: Add sp= to your existing record

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@company.com; pct=100;

Adding `sp=reject` extends your policy to all subdomains that don't have their own explicit DMARC record. This is the most common fix.

The tradeoff: you need to be certain that all legitimate subdomain senders are fully DMARC-compliant - meaning they pass SPF or DKIM with proper alignment. If any subdomain is sending mail through a service that hasn't been properly configured, adding `sp=reject` will break it. Before deploying `sp=reject`, review your DMARC reports to confirm every subdomain that is sending mail is actually supposed to be.

Option 2: Wildcard your DMARC record

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@company.com; pct=100;

A wildcard DMARC record at the apex domain (`*.company.com`) technically achieves the same result as `sp=reject` for most configurations. The practical difference is minimal. The `sp=` approach is generally preferred because it is explicit and easier to audit.

Option 3: Use sp=none while you investigate

If you suspect you have unknown subdomain senders, `sp=none` will give you visibility without disrupting existing flows:

v=DMARC1; p=reject; sp=none; rua=mailto:dmarc-reports@company.com; pct=100;

This rejects mail from the apex domain but passes mail from subdomains, then sends reports on all subdomain activity. Use this as a transitional step while you audit your subdomain portfolio.

Which to use when

Use `sp=reject` when you have high confidence in your subdomain sender landscape - meaning you know every subdomain that sends mail and have confirmed each one is properly configured. Use `sp=none` when you are still discovering unknown senders and don't want to risk disrupting legitimate mail.

---

How to Discover Subdomains You Didn't Know About

You can't protect subdomains you don't know exist. Discovery is the prerequisite for closing the gap.

Read your DMARC aggregate reports. Your `rua` target receives aggregate reports from receivers showing every domain and subdomain that has sent mail to them in the reporting period. Look specifically for subdomains that appear in `source_ip` or `envelope_from` fields that you don't recognise. Any subdomain with sending volume you can't attribute to a known service is a gap.

Query your DNS proactively. If you control your DNS, list all `CNAME` and `NS` records that point subdomains to external nameservers. Any subdomain delegated to a third party's nameservers is a candidate for review.

Use a subdomain enumeration tool. Services that crawl DNS records for a given domain can surface subdomains that have active DNS records but may have been forgotten. Run this against your own domain periodically as part of domain hygiene.

Check for dropped delegations. If a third party's nameserver stops responding for your subdomain, that delegation has lapsed. You may still own the subdomain name, but if the delegation expired and someone else registered it, you have a security gap.

This is where a dedicated DMARC monitoring service adds value. Services that aggregate and normalise DMARC reports across your full domain portfolio make it easier to spot unexpected sending sources - including subdomains you didn't know were active - before they become incidents. Rather than reviewing raw XML from individual receivers, you get a normalised view of every subdomain sending to external domains, with source IPs and volumes. This is specifically where DMARCFlow is useful: it turns DMARC report data into a queryable, filterable record of your sending landscape, making it practical to catch gaps like forgotten subdomain delegations before attackers do.

---

FAQ - sp= and Subdomain Protection

Does p=reject protect subdomains automatically?

No. The `p=` tag only governs the domain it is published on. To extend DMARC policy to subdomains, you need the `sp=` tag. Without it, subdomains are not covered by your policy.

What happens if a subdomain I don't control has its own DMARC record?

The subdomain's own record takes precedence. If `marketing.company.com` has its own DMARC record, receivers will use that record, not the parent. Subdomains you don't control but have delegated to third parties may have their own policies or may have no policy at all.

Should I use sp=reject or sp=none?

Use `sp=reject` when you have confirmed that all legitimate subdomain senders are fully DMARC-compliant. Use `sp=none` as a monitoring step while you audit subdomain sending sources. Never deploy `sp=reject` without reviewing your aggregate reports first - you will break legitimate mail from misconfigured subdomains.

Can I use a wildcard DMARC record instead of sp=?

Yes, in most cases. A wildcard record (`*.company.com`) and `sp=reject` produce similar results for subdomains. The `sp=` approach is more explicit and easier to review in a DNS record, which is why it is generally preferred.

Does adding sp=reject affect subdomains used for internal mail only?

If a subdomain is used only for internal mail that never leaves your organisation, its DMARC posture matters less for external receivers - but it still matters for any mail that exits your internal network. Apply `sp=reject` consistently across your full domain portfolio to avoid creating gaps an attacker could exploit.

What about subdomains that send mail through third-party providers?

If a subdomain sends mail through a third-party provider (a marketing platform, a cloud service, a CRM), that provider should be configured with proper SPF and DKIM for the subdomain. Before adding `sp=reject`, verify each provider's setup. If a provider can't or won't configure proper authentication for a subdomain you need to protect, that's a vendor management problem that needs to be resolved before enforcement.

An attacker registered an undelegated subdomain. Can DMARC help?

No. DMARC can only protect domains you control. If an attacker controls a subdomain because the delegation lapsed and they registered it, DMARC on your parent domain won't help. The subdomain is now theirs. You would need to recover the domain name through your registrar's dispute process and re-delegate it. Prevention (monitoring for dropped delegations, keeping DNS records current) is the only reliable protection here.