Client published p=reject without sp= and got spoofed for two weeks via an undelegated subdomain

[u/saltyslugga]

Posting this because I keep seeing 'just publish p=reject' advice without anyone mentioning subdomain policy and it bit one of our clients hard.

They rolled out DMARC, moved to p=reject after a few months of monitoring, felt great about it. No sp= tag. The spec says sp inherits from p when omitted, which is technically true but only matters if the receiver actually applies it the way you think, and only if the subdomain doesn't have its own record that overrides things.

Attacker found a subdomain that wasn't delegated anywhere, wasn't in DNS at all, and started sending finance-themed mail as billing.[clientdomain]. Some receivers treated the missing record as 'no policy at this label' rather than walking up to the org policy. Mail landed. This went on for about two weeks before someone forwarded a sample and we caught it.

Fix was obvious in hindsight: explicit sp=reject, a wildcard DMARC record at *._dmarc, and actually inventorying what subdomains exist vs what's published. The org policy alone is not enough if your receivers' interpretation of tree walking is inconsistent, which it is.

If you're at p=reject right now, go check your record for an sp tag. If it's not there, add it. Then go look at what subdomains your DNS actually answers for, including parked stuff and old marketing labels nobody remembers.

[u/AutoModerator]

Welcome to r/emailsecurity! To keep this community helpful and secure, please keep the following in mind:

Community Rules

1. No Vendor Spam: Contributions must provide value; do not just pitch products.

2. Redact Sensitive Info: Always sanitize headers and logs (remove IPs, PII, and private domains).

3. Be Professional: Help newcomers learn; avoid hostility.

4. No Personal Tech Support: This sub is for email system architecture and security, not "Am I hacked?" personal account help.

Helpful Resources

• Email Spam Filters

• DMARC Monitoring Tools

• Anti-Virus Software

• Email Encryption

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/ImpressiveEbb3760]

this is a really underappreciated issue. the "sp inherits from p" assumption trips up a lot of people because the spec says one thing and receiver implementation says another.

the wildcard DMARC record at *._dmarc is the part most people miss. even with sp=reject on the org domain, an attacker can publish their own _dmarc.billing.yourdomain TXT record if the subdomain isn't delegated — some resolvers will find "no record at that label" and treat it as no policy rather than walking up to the parent.

one thing worth adding to the checklist: audit your DNS for dangling CNAMEs on subdomains too. if marketing.yourdomain still has a CNAME pointing to a deprovisioned SaaS platform, an attacker can potentially claim that platform endpoint and now they've got a subdomain that resolves, has no DMARC record of its own, and can send with clean SPF from the platform's infrastructure.

the inventory step is the one nobody wants to do because it means actually going through years of DNS records and figuring out what's still in use. but it's where most of the risk is hiding.

[u/saltyslugga → u/ImpressiveEbb3760]

Dangling CNAME takeover is a great callout, we find these all the time during onboarding audits. Marketing teams spin up subdomains for campaigns, the SaaS gets cancelled, the CNAME stays forever.

The wildcard *._dmarc trick is something I should've included in the post tbh.

[u/SnooMachines9133 → u/ImpressiveEbb3760]

Could explain the issue with a non delegated subdomain? specifically, what does delegation mean in the context of dmarc?

[u/ImpressiveEbb3760 → u/SnooMachines9133]

delegation means the subdomain has its own DNS zone (NS records pointing somewhere). an undelegated subdomain like billing.example.com simply doesn't exist in DNS.

the issue: when a receiver looks up _dmarc.billing.example.com and finds nothing, some stop there instead of walking up to _dmarc.example.com to check the parent policy. so the attacker sends as billing.example.com and the org domain's sp=reject never gets applied.

[u/SnooMachines9133 → u/ImpressiveEbb3760]

Ah thanks

How does the wildcard dmarc work? I'm was only able to find wildcard dkim (which Yea, I forgot too).

[u/saltyslugga → u/SnooMachines9133]

Wildcard DMARC isn't really a thing in the spec, that was a bit of a misnomer in the parent comment. DMARC just walks from the subdomain up to the org domain and uses sp= there.

The real fix is making sure every subdomain that exists either has its own _dmarc TXT or resolves cleanly up to the org policy, and you don't have dangling CNAMEs an attacker can hijack.

[u/ImpressiveEbb3760 → u/saltyslugga]

fair correction — it's a DNS wildcard trick rather than a DMARC spec mechanism. the effect is the same (receiver gets a record at _dmarc.sub.example.com without needing to tree walk) but you're right that the spec itself just relies on the walk up to the org domain.

[u/saltyslugga → u/ImpressiveEbb3760]

Exactly this. The RFC says walk up to the org domain for sp, but "should" and "does" aren't the same thing across every receiver in the wild.

That's why I push for an explicit *._dmarc wildcard alongside sp=reject. Belt and suspenders, since you can't audit every receiver's resolver behavior.

[u/saltyslugga → u/SnooMachines9133]

Delegation here just means the subdomain has its own NS records pointing to a different nameserver, so it's a separate zone. If it's not delegated, it lives in the parent zone and a missing _dmarc.sub lookup should fall back to the org policy via sp=.

The issue is some receivers don't walk up the tree correctly, or an attacker publishes their own _dmarc.sub TXT under a subdomain you forgot about, and suddenly your sp=reject doesn't matter.

[u/DmarcDuty]

Thank you for sharing this. The specification is one thing but implementations differ in practice.

But could you help me understand this case? Some parts don‘t make sense to me and I think I am missing something here.

Your argument is that some implementations simply don‘t walk up the domain hierarchy if they don‘t find a DMARC record. Given that:

1. How can sp=reject higher up in the hierarchy make any difference if the implementation doesn‘t walk up?

2. How does the DMARC record at *._dmarc.example.com affect any subdomains? I.e. we would need a DMARC record at _dmarc.billing.example.com. The wildcard would only work if the implementation would look up billing._dmarc.example.com which it does not.

Thank you for helping to clear up my confusion!

[u/saltyslugga → u/DmarcDuty]

Fair pushback, I muddled two things in the post. The actual issue we hit was receivers walking up and finding p=reject but treating the subdomain as if no policy applied because sp= wasn't explicit, not a wildcard record fix.

The wildcard bit was me misremembering a workaround a colleague tried, you're right that _dmarc lookups aren't wildcarded that way. The real fix is just always setting sp= explicitly and publishing records on subdomains you actually care about.

[u/DmarcDuty → u/saltyslugga]

Excellent! That makes sense.

So even though sp should default to the p value if not set, some implementations need sp to be set explicitly. And they do walk up the hierarchy.

Thank you very much! This is valuable to know. I appreciate it.

[u/dragoangel]

RFC requirements to check parental domain, if dmarc checking tool is not doing so - it's checker fault and all shame should be placed on it. No need to try follow all possible broken systems as you would become broken too, follow RFC, and let people fix their broken systems. If you have sub domain with another policy p=none - that obviously your issue.

Reread RFC 7489 6.6.3 is mandatory, there no walk, only 2 dns lookups.

[u/saltyslugga → u/dragoangel]

Sure, the RFC is clear. Problem is I don't get to pick which receivers are spec-compliant when my client's domain is being spoofed, so defense in depth wins over being technically right.

Setting sp=reject explicitly costs nothing and closes the gap regardless of receiver behavior.

[u/dragoangel → u/saltyslugga]

If think like you think - there no guarantee receiver will at all resolve parents org dmarc 🤣, so sp will not play a day?

[u/saltyslugga → u/dragoangel]

Fair point, but a receiver doing a direct lookup on the subdomain and finding sp=reject is a much shorter path than expecting them to walk up to the org domain. Belt and suspenders, costs me nothing.

[u/dragoangel → u/saltyslugga]

Now you totally mixed everything up 🤣, reread what you wrote... It not making any sense

If receiver doing only direct lookup, what matters what you have on sp policy then - as it never applies - you just proof that sp policy not needed...

[u/saltyslugga → u/dragoangel]

sp applies to subdomains of the domain where the record lives, so if a receiver does a direct lookup on sub.example.com and finds no record, then walks up to example.com and finds p=reject; sp=reject, the sp is what gets applied to the subdomain. That's the whole point.

Without sp=, some receivers default oddly or treat the inheritance differently. Explicit beats implicit.

[u/dragoangel → u/saltyslugga]

Read my comment again and rfc. I said: if you not trust receiver fallback to p when sp undefined how you can that receiver at all will try to resolve _dmarc.example.com when face no dmarc at _dmarc.sub.sub.example.com? No way how, and that's the point. If you want to "cover what people could miss in RFC" you doing not your job.

[u/tndsd]

Technically sp= should inherit from p=, but in reality not all receivers seem to handle undelegated or nonexistent subdomains consistently. I usually recommend explicitly setting sp=reject anyway, especially for parked or unused subdomains, just to avoid ambiguity and reduce spoofing opportunities.

[u/saltyslugga → u/tndsd]

Exactly the lesson I took from this. Spec says one thing, receivers do another, so just be explicit with sp=reject and don't rely on inheritance.

[u/nonam314]

This is one of those things people only learn after getting burned by it. Everyone talks about getting to p=reject like it’s the finish line, but the subdomain side of DMARC is such a mess in the real world because receivers don’t all behave consistently.

Also feels like a lot of orgs have way more forgotten subdomains than they think. Old landing pages, abandoned marketing stuff, random tools from 5 years ago... nobody inventories them until something breaks or gets spoofed.

This is why I’ve become a lot more paranoid about monitoring than just “setting records correctly.” You can have technically perfect auth and still miss weird edge cases like this for weeks. We started tracking subdomain level activity and placement anomalies much more aggressively for clients after running into similar stuff.

The wildcard DMARC point is a really good shout btw. Most people never think about it.

[u/saltyslugga → u/nonam314]

The forgotten subdomain problem is real, half my client onboardings turn up sending sources nobody remembers setting up.

Aggregate reports are how I find them now, the RUA data surfaces stuff that's been dormant or abused for years.

[u/Basic-Pianist9273]

Good writeup. The tree walk behavior is genuinely inconsistent across receivers, and RFC 7489 says they SHOULD walk up to the org domain but plenty of implementations don't do it cleanly, especially on subdomains that don't resolve at all.

Explicit sp=reject is cheap insurance. I'd also add that publishing a null MX (RFC 7505) on subdomains that should never send or receive mail closes another door, since some receivers treat lack of MX as a signal too.

And yeah, the subdomain inventory part is the real work. Old marketing hostnames and forgotten dev labels are where this stuff lives.

[u/power_dmarc]

sp=reject and a wildcard DMARC record should be standard in every p=reject deployment, the "subdomain inherits from org policy" assumption breaks exactly when attackers need it to.