Somebody is sending phishing emails that appear to come from your company. Your customers are getting them. You did everything right — SPF, DKIM, DMARC at p=reject, the whole apparatus — and the emails keep arriving anyway.
This is one of the most demoralizing moments in email security, because the standard advice has already been followed and it didn't work. That's not because you configured something wrong. It's because most explanations of DMARC quietly omit what it doesn't cover, and the gap is much wider than people expect.
Here's how spoofing actually works, what your defenses genuinely stop, and what they were never designed to touch.
SMTP was built on the honor system
The reason spoofing is possible at all comes down to a design decision from 1982. SMTP, the protocol that moves email, has no built-in concept of proving who you are. You connect to a mail server and you state who you are. The server takes your word for it.
Worse — there are two separate "from" fields, and they have nothing to do with each other.
The envelope sender. This is part of the SMTP conversation itself, sent in the MAIL FROM command. It's used for bounce handling — where errors get returned. The recipient never sees it.
The header From. This is a line inside the message content, and it's what the mail client displays. This is what your users actually look at.
These two fields are set independently and nothing in the protocol requires them to match. That's not a bug — legitimate services rely on it constantly. Your newsletter provider sets the envelope sender to its own bounce-handling address while the header From shows your brand. Mailing lists do the same. It's normal.
But it also means: anyone can put anything in the header From. Type it in and send. The protocol doesn't care. That's the whole of it. Domain spoofing isn't an exploit or a vulnerability — it's SMTP working as designed.
The uncomfortable truth about SPF
This is where most understanding breaks down.
SPF checks the envelope sender. Not the header From.
Read that again, because it has a consequence people find genuinely surprising: an attacker can send you a message with a perfectly passing SPF result and a completely forged visible From address. They just set the envelope sender to a domain they legitimately control, with a valid SPF record, and set the header From to yours.
SPF passes. It's not lying — the message did come from a server authorized for the envelope domain. SPF answered the question it was asked, correctly. The question just wasn't the one that mattered.
SPF alone provides essentially no protection against visible domain spoofing. A domain with a flawless SPF record and no DMARC is wide open. This is why "we have SPF" is not an answer to "can someone spoof us."
DKIM has a mirror-image gap: it proves a message was signed by some domain and wasn't modified, but a valid signature from attacker-domain.example on a message claiming to be from you is still a valid signature.
DMARC is the piece that closes both gaps, by requiring alignment: the domain that passed SPF or DKIM must match the domain in the visible From. That's the actual protection. SPF and DKIM are inputs; alignment is the mechanism.
If you're unsure where your domain stands right now, checking the published SPF, DKIM, and DMARC records is a two-minute exercise, and the common finding is a domain with SPF and no DMARC policy — which feels protected and isn't.
What DMARC at p=reject genuinely stops
Give it its due. With p=reject and alignment working, you have shut down exact-domain spoofing. Nobody can send mail with @yourdomain.com in the visible From and have it accepted by any receiver that honors DMARC. That's a real and substantial win, and it's the single highest-value email security control available.
It also gives you visibility. Aggregate reports show you every source attempting to send as you.
Now the part that doesn't get said enough.
What DMARC does nothing about
Display name spoofing. This is the big one, and it defeats DMARC completely.
An email's From line has two parts: a display name and an address. Mail clients show the display name prominently and frequently hide the address entirely — especially on mobile, where screen space is scarce.
So the attacker sends:
From: Ramil Mastiyev <billing@totally-unrelated-domain.example>Your recipient sees "Ramil Mastiyev." That's it. That's what's on the screen.
And DMARC? DMARC evaluates totally-unrelated-domain.example — the actual From domain. The attacker owns it, configured SPF and DKIM properly, and DMARC passes. Cleanly. Your policy is irrelevant, because your domain isn't in the From field at all. It's in a text label that DMARC doesn't look at and users can't stop reading.
Your p=reject policy did not fail here. It simply wasn't involved. This is the most common form of business email compromise, and every DMARC configuration on earth is blind to it.
Lookalike domains. The attacker registers rnarinadns.io (that's r-n, not m) or yourdomain.co or your-domain.com. Then they configure SPF, DKIM, and DMARC on it — properly, because they want their phishing to authenticate. Everything passes, for their domain, which is exactly what the standards intend.
DMARC protects a domain. It says nothing about domains that merely resemble one. There's no mechanism for "this looks like someone else's," because there couldn't be.
Compromised legitimate accounts. If an attacker has valid credentials for a real mailbox on your domain, everything they send authenticates perfectly. It's genuinely from you. Every check passes because every check should pass. Email authentication answers "did this come from an authorized sender" — and a compromised account is an authorized sender.
Subdomain spoofing, if you left the door open. DMARC has a separate subdomain policy tag, sp=. If you set p=reject but never set sp=, subdomains inherit the parent policy — usually fine. But if you set sp=none (or a provider template did), then invoices.yourdomain.com is unprotected while the parent looks locked down. It's worth confirming what your record actually publishes rather than what you think it does.
The defenses for the gaps
Since DMARC structurally cannot cover these, you need different tools:
For lookalike domains: watch the Certificate Transparency logs. This is the most underused early-warning system in security. Every publicly trusted TLS certificate is logged, publicly, at issuance. Phishing operations need HTTPS to look legitimate — so they get a certificate, and it lands in a public log before they send anything.
Searching the CT logs for certificates issued to names resembling your domain will surface a lookalike during setup, typically days before the campaign launches. You get advance notice of an attack that hasn't happened yet, from a public dataset, for free. Do this periodically — it's one of the few controls that catches lookalikes at all.
For display name spoofing: this is mostly a client and training problem. Some mail providers now flag display names that don't match known contacts. Beyond that, it comes down to whether your people know to check the actual address rather than the label — which is a genuinely hard ask on a phone.
For compromised accounts: that's identity security, not email authentication. MFA, credential monitoring, anomaly detection on send patterns. Nothing in DNS helps you here.
For incoming suspicious mail: read the headers. When a message that claims to be from you (or from a supplier, or a bank) reaches someone and something feels off, the raw headers settle it. An email header analyzer will show what actually authenticated, for which domain, and whether the passing domain matches the visible one — which is precisely the distinction the attack depends on you not checking.
The honest summary
| Attack | Does DMARC stop it? |
|---|---|
Exact-domain spoofing (@yourdomain.com in From) |
Yes, at p=reject |
Display name spoofing (Your Name <attacker@elsewhere>) |
No — different domain, passes its own DMARC |
Lookalike domain (yourdomaln.com) |
No — it's a different domain with its own valid policy |
| Compromised account on your domain | No — it authenticates because it's real |
| Subdomain spoofing | Only if sp= is set correctly |
DMARC at p=reject is necessary, valuable, and worth the effort. It is not a solution to phishing. It closes one specific hole — the one where someone puts your exact domain in the From field — and that hole was worth closing.
But when someone tells you they've "solved spoofing" with DMARC, what they've actually done is force attackers to use the four techniques above instead. Which is progress. It just isn't the end of the conversation, and the gap between "DMARC deployed" and "we're protected from phishing" is where most successful attacks now live.