What "dkim=pass" really means

If you have opened an email’s headers, found a line like dkim=pass header.d=supplier.com; spf=pass; dmarc=pass, and want to know whether that means the message is safe: it means the message really came from that domain, and nothing more. It says nothing about whether the invoice is genuine, whether the bank details are right, or whether the person typing was your supplier.

That is not a technicality. The most expensive invoice fraud in Europe passes all three checks, every time, because it is sent from the supplier’s real mailbox. If you are holding a payment request, the supplier email check reads the message and says which of these things it could actually establish — and, just as importantly, which it could not.

What each of the three checks is actually asking

They are often written as if they were one verdict. They are three different questions, and none of them is “is this email honest”.

SPF asks whether the server that delivered the message is one the domain’s owner listed as allowed to send. It is a question about an IP address. It says nothing about who wrote the message or what is in it.

DKIM asks whether a cryptographic signature over parts of the message matches a public key published in the domain’s DNS. A pass means somebody holding that domain’s private key signed those parts, and they have not been altered since. It is the strongest of the three — and it is a statement about the domain, not about the sender’s intent.

DMARC asks whether SPF or DKIM passed for a domain that matches the From: address the reader sees, and tells receiving servers what to do when neither does. It ties the other two to the visible sender. That is genuinely valuable, and still not a claim about content.

So dkim=pass header.d=supplier.com means: this really is your supplier’s domain. Which is exactly what you would expect when a criminal is sitting in your supplier’s mailbox.

The fraud that passes every check

The version of invoice fraud that succeeds is not a lookalike domain. It is a real email from the real supplier’s real mailbox, usually reached with a password from an unrelated breach or a phishing page filled in weeks earlier.

Everything authenticates, because everything is genuine:

• the message is signed by the supplier’s own domain, so DKIM passes;
• it leaves the supplier’s own mail provider, so SPF passes;
• the From: address matches, so DMARC passes;
• the thread history is real, because it is the real thread.

Only the bank details are new. Email authentication has no opinion on bank details.

This is why “the email authenticated” is never a reason to pay, and why every result on this site — including the clean ones — ends with the same sentence about phoning a number you already had. There is a longer walkthrough in a supplier emailed asking to change their bank details.

Who wrote the line you are reading

There is a second trap, and it is easy to miss.

Authentication-Results: is a header written by the mail server that received the message — your own provider, usually. When you read dkim=pass there, you are reading somebody else’s verdict, recorded at delivery time. That is normally trustworthy, because your own provider wrote it.

But headers are just text. If the block was forwarded to you, pasted into a ticket, copied out of a colleague’s screenshot, or handed over by whoever is asking to be paid, then the line saying dkim=pass is a claim by whoever produced the text — and anyone can type it. There is no cryptography protecting a header that says cryptography succeeded.

The honest distinction is between three quite different situations:

What you have	What can be established
The full raw message, including its signature	The signature can be verified now, by you
Only headers, with an Authentication-Results line	The receiving server’s recorded verdict, taken on trust
Neither — just the visible email	Only what the domain publishes: SPF, DMARC, MX

Any tool that shows you the second and calls it the first is telling you something you have no way to check. The supplier email check labels which of the three it is doing, and never promotes one to another: a dkim=pass sitting in a pasted header block is reported as the receiver’s verdict, said in those words.

When a “fail” matters more than a “pass”

A pass is weak evidence. A fail is strong evidence, and worth stopping for.

If DKIM verification actually runs and disagrees — the signature does not match the content — the message was altered after signing, or was never signed by that domain at all. If DMARC is set to p=reject and the message failed anyway, it should not have been delivered.

There is one asymmetry worth carrying: cannot check is not the same as failed. An unreachable DNS lookup, a revoked key, an expired signature or a signature that only covers part of the body all mean the arithmetic could not be completed. That is not a finding against the sender, and a tool that renders it as one wastes the only signal that would have been worth acting on.

What to do with a message you are unsure about

1. Do not reply to it. If the mailbox is compromised, your reply goes to the attacker, and a mailbox rule may hide it from the real supplier.
2. Phone the supplier on a number from an old invoice, your accounting system, or their website reached by typing the address yourself.
3. Check the identifiers separately — the VAT number, the company register entry, and, for a Polish supplier, whether the account is on the white list. The invoice checker does all of these from the document itself.
4. Treat a change in bank details as the event, not the email around it. That is the thing worth a phone call, whatever the headers say.

What this cannot tell you

Email authentication is a check on the channel, not the claim. It cannot tell you that the goods were ordered, that the amount is right, that the person emailing still works there, or that the account belongs to your supplier. Poland is the only country in the EU that publishes an answer to that last question, which is why the white list is worth using where it applies.

Everywhere else, the control that catches this is a voice call to a number you already had.