## TL;DR
Close the subdomain itself: if it should never send mail, publish a null MX style defence with an SPF record that authorises nothing and a DMARC record at p=reject for that subdomain; if it does send through a service, give it aligned SPF and DKIM and its own enforced DMARC record. Then test from outside. Attackers pick subdomains precisely because the root domain is locked down and nobody applied the same controls one level down.

```text
spoofed mail from our own unprotected subdomain delivered because no sp tag in dmarc record
```

## Use this when
- Spoofed mail uses your real subdomain in the From or envelope and is delivered to your users or customers.
- The subdomain has no DMARC record, or the root record has no sp tag covering it.
- The subdomain is unused for mail, or sends only through one known service.

## Not for this skill when
- The spoof uses a lookalike domain you do not own. That is a filter and user reporting problem, not your DNS.
- The subdomain is fully aligned and enforced already and the mail still arrived. Investigate the receiving filter path instead.

## Steps
1. List every subdomain that appears in your DNS and in mail headers, and mark which ones legitimately send mail. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: every subdomain is classified as sending, receiving only, or unused
2. For non-sending subdomains, publish an SPF record authorising no servers and a DMARC record at p=reject with reporting to your rua. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: external lookups show the lockdown records on a test subdomain
3. For sending subdomains, publish aligned SPF and DKIM for their one service and an explicit DMARC record that will move to reject. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: service test mail from the subdomain shows aligned passes
4. Add or confirm the sp tag on the root DMARC record so undiscovered subdomains default to your chosen policy. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: the root record shows an sp value that matches your intent
5. Send an unauthorised test as the subdomain from an external service and confirm receivers reject it. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: the spoof style test is rejected or clearly fails DMARC at the test receiver

## Why it happens
DMARC protects exactly the domains it is published and inherited for, and inheritance gaps are subtle: a root record without an sp tag, a service subdomain created by another team, or a legacy name that still resolves. Attackers enumerate subdomains because mail from a real subdomain of a trusted organisation inherits human trust even when filters should catch it. Locking down non-sending names is cheap, permanent, and removes the easiest spoofing surface most organisations own.

## Variants and edge cases
### spoofed mail own subdomain delivered no sp tag dmarc
The missing sp tag wording from the incident.
### unprotected subdomain spoofing publish dmarc reject spf null
The lockdown record variant for unused subdomains.
### subdomain takeover mail spoof dmarc coverage audit fix
The audit variant for finding every exposed name.

Compatibility: RFC 7489 DMARC sp tag, RFC 7208 SPF, subdomain inventory and DNS audit tooling.

Edge cases to check:
- A subdomain delegated to a vendor with its own name servers needs the records in the vendor zone; your root zone cannot publish them.
- Parked and forgotten subdomains from old campaigns are the most common gap found in these audits.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_AVOEtp8yaPj1ss-sXdw7UA