Authenticated is not authentic

Finance pays an invoice. Afterwards, someone pulls the headers.

SPF passed. DKIM passed. DMARC aligned. The signature was valid, the sending infrastructure was authorized, the policy was satisfied. Three green checks on a message that cost the company money.

Every one of them was accurate. The domain that authorized the mail simply was not yours.

What each record actually binds

Briefly, because everything below depends on the precision.

SPF binds an envelope sender domain to the addresses permitted to send for it. A particular server was allowed to transmit for a particular domain.

DKIM binds a domain to message content through a signature and a published key. A domain took responsibility for this content, and the covered parts arrived unmodified.

DMARC requires the domain the reader sees in the From header to align with a domain authenticated by SPF or DKIM, with at least one aligned mechanism passing. It also publishes the domain owner's handling policy for messages that fail that test.

Every one of these is a statement about a domain. Not one is a statement about a person, a company or an intention. A domain that authorizes its own mail correctly passes, whether it belongs to you or to someone who registered it on Tuesday.

Authentication answers: did the domain in this message authorize it?

It does not answer: is this the domain the reader thinks they are looking at?

Many convincing email attacks live in the gap between those two sentences.

Nobody attacks your authentication

They do not need to. That is the part worth sitting with.

An attacker registers a domain that reads like yours. A hyphen inserted. A word dropped. A different suffix. A character borrowed from another alphabet that renders almost identically. Then they publish their own SPF, their own DKIM key, their own DMARC policy, and they send.

Everything passes. The headers are clean. A gateway evaluating authentication alone has nothing to object to, because nothing is wrong. That domain genuinely did authorize that message.

Your policy is irrelevant here. Your domain was never involved.

Publishing a reject policy makes direct spoofing of your exact domain much harder at receivers that enforce DMARC, which matters and is worth doing. It has no effect on a different domain that merely looks like yours.

The field no standard covers

The From header carries two things. A display name and an address. People read one of them.

On a phone the address is often not shown at all until the header is deliberately expanded. In a full inbox on a laptop, the display name is what the eye lands on and the address is grey text most people never focus on.

So a message from an ordinary consumer mailbox, with the display name set to a real person's name and title, arrives fully authenticated, because the consumer provider genuinely sent it, and presents to the reader as that person.

Nothing was spoofed. The authentication is honest. The deception sits entirely in a field any sender can set to any value, and that no authentication standard has ever attempted to cover.

The same applies to a divergent Reply-To. The visible sender can be one address and the destination of a reply another. Many legitimate mailing and support platforms do this, which is exactly why a receiver cannot treat the pattern as malicious on its own.

When the account really is yours

A compromised mailbox inside your organization, or inside a supplier's, authenticates perfectly. It is supposed to. Right domain, right key, right addresses, right account.

This is why payment fraud so often arrives inside a real thread rather than as a new message. The attacker does not have to resemble the counterparty. They are, technically, sending as the counterparty.

There is no authentication failure to detect, so no authentication control engages. What engages instead is behavioral detection on the identity side, anomalous sign-ins and newly created forwarding rules, and a procedural control on the business side that verifies payment changes through a channel other than the one requesting them.

Everyone you have authorized to send as you

Every vendor in your sending configuration is a party permitted to send as your domain. Marketing platforms, ticketing, HR tooling, e-signature, invoicing, monitoring, the survey tool somebody trialled in 2019 and never removed.

Two consequences follow.

The permitted set is larger than it looks. SPF records can include other providers' records, one configuration entry can expand into a large shared address space, and DKIM or return-path configuration may be spread across several vendors.

That does not mean another tenant on a shared sending platform can automatically impersonate your domain. Tenant isolation, custom return paths, DKIM keys and provider-side controls matter. The operational problem is simpler: every authorized sender becomes part of your mail trust boundary, and you need to know exactly how that authorization is scoped.

Where the business use allows it, putting third-party senders on dedicated subdomains keeps the parent domain's sending surface smaller, limits the impact of one vendor's configuration and makes removal cleaner than unwinding years of mixed sending history.

What alignment covers, and where it stops

None of the above is an argument against DMARC. It blocks a major class of direct domain spoofing, gives you reporting on who is sending under your name, and is now part of the baseline expected for reliable bulk delivery at the large mailbox providers.

What it covers is your exact domain and, depending on how you publish, your subdomains.

What it does not cover is any domain that is not yours, any display name, any Reply-To, or any account that was legitimately compromised.

One piece is easy to miss. Domains and subdomains you own but never send from still need an explicit non-sending posture. That normally means publishing records that make unauthorized mail fail rather than leaving a parked brand domain with an ambiguous configuration.

What actually helps

Roughly in order of return.

Watch the space around your name. Registration monitoring for near-miss variants, and a route to act when one appears. Defensively registering the obvious ones costs less than one successful incident.

Read your reporting. Aggregate reports show which infrastructure is attempting to send using your domain, including systems nobody remembered. They are one of the best sources for building and validating the sending inventory.

Mark external mail visibly. A clear indicator on messages from outside the organization can help against display-name deception because it addresses the part DNS cannot: what the reader actually sees.

Detect the pattern, not the record. Gateway controls for lookalike domains, first-contact senders, and display names matching internal staff that do not resolve to internal addresses.

Keep the authorized set small. Audit the sending inventory, remove what has aged out, move what is active onto scoped subdomains.

Put a procedure behind the money. Any change to bank details verified through a channel that is not the thread requesting it. This is the control that holds when every technical layer has behaved correctly, which, as above, is the normal case.

The check worth running

From an external mailbox, send yourself a message with your own full name and title as the display name. Look at it on a phone, in a notification, and in the inbox list.

That is the view your finance team gets. All of it passed authentication.

Explore this expertise: Email Deliverability

All technical notes