You set DMARC p=reject and you are still getting spoofed: why

DMARC p=reject only does one thing: it tells receiving mail servers to bounce messages whose visible From: domain is exactly yours and which fail both SPF and DKIM alignment. That is a narrow guarantee. It does nothing about lookalike domains, display-name spoofing, inbound phishing aimed at your own users, or receivers that simply do not evaluate DMARC. If you are "still getting spoofed" after setting reject, almost always the attack was never in DMARC's scope to begin with.

DMARC only protects your exact From domain

DMARC is keyed to the domain in the From: header — and nothing else. An attacker who registers a cousin domain owns that domain's DMARC, not you.

• Lookalike / cousin domains: rnicrosoft.com (r-n looks like m), paypa1.com (digit one for L), your-company.co instead of .com. Each is a different domain with its own (probably absent) DMARC. Your p=reject is irrelevant to them.
• Display-name spoofing: the value most mail clients show big and bold is the display name, not the address. From: "PayPal Support" <[email protected]> passes DMARC perfectly — it is genuinely sent from gmail.com, which is correctly authenticated. The header is honest; the human is fooled.

No DMARC policy you publish can touch either of these. They need lookalike-domain monitoring and anti-phishing / display-name rules at the inbound gateway.

Reject is enforced by the receiver, not by you

Your DMARC record is an instruction. Whether it is honoured depends entirely on the receiving server choosing to evaluate DMARC and apply the disposition.

Google, Microsoft, and Yahoo enforce it. Plenty of smaller hosts, appliances, and mailing-list relays do not, or do so inconsistently. A receiver that never looks up _dmarc.yourdomain.com will deliver a forged message regardless of p=reject. You control the policy; you do not control the audience.

Your DMARC does nothing for inbound spoofed mail

This is the most common confusion. DMARC protects your domain's reputation when you are the From. It says nothing about mail arriving at your users claiming to be from someone else.

If staff are getting phishing from spoofed irs.gov, aws.amazon.com, or a fake vendor, your own DMARC is the wrong tool entirely — that is the sender's DMARC, evaluated by your inbound filter. Protecting your inbox needs inbound DMARC enforcement on your mail platform (reject/quarantine on failing inbound mail), not a stricter outbound record.

Allowlists and overrides still let mail through

Even at a DMARC-enforcing provider, local policy can override the verdict. A user-created allowlist, an org-level "always trust this sender", a connector exception, or a mailing-list ARC chain can all deliver a message that DMARC alone would have rejected. Check the receiver's override fields in your aggregate reports before assuming the policy failed.

Verify the record actually says reject

Before chasing exotic causes, confirm your published policy is what you think. A typo silently degrades enforcement:

dig +short TXT _dmarc.example.com

Look for p=reject with no stray spaces, and check sp= — if your subdomains have no policy, attackers will spoof billing.example.com instead. Also confirm legitimate mail is aligned, not just passing, or reject will bounce your own traffic.

Check what your DMARC record actually enforces →

DMARC p=reject is necessary and worth deploying — it kills exact-domain spoofing at compliant receivers and ends the cheapest impersonation attack. It is not sufficient. Layer on lookalike-domain monitoring, display-name and anti-phishing rules, BIMI to make your verified brand visible, inbound enforcement, and user training. Reject closes one door; the attackers walk to the next one.

Further reading

• What is DMARC?
• Email deliverability checklist: SPF, DKIM, and DMARC in order
• RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance