Why DMARC passes on phishing

The first question we get from almost every fraud lead is some version of "we already have DMARC at reject, so what does this add?" It is a fair question, and the honest answer is that DMARC passes on most phishing because DMARC authenticates a domain, and attackers stopped using yours. Fromenance exists because communication provenance, evidence that your institution sent this message to this person, is a different question from domain authentication, and it is the one your customer is actually asking.

What DMARC actually checks

SPF answers whether the sending server is allowed to send for the domain in the envelope. DKIM answers whether parts of the message were signed by a key published under a signing domain. DMARC requires that one of those domains lines up with the domain in the visible From header, and tells receivers what to do when neither does.

That is the whole test. There is no check of the display name, the logo, the body, the links, or whether the domain in the From header has anything to do with your institution.

What attackers send instead

Spoofing jtmerlin.com directly fails DMARC at a bank with a reject policy, so attackers do not bother. They send from:

• Lookalike domains: jtmerlin-secure.com, jtmerlinalerts.net, Unicode homoglyphs
• Free mail accounts with "JT Merlin Bank Fraud Team" as the display name
• Compromised legitimate domains, including your vendors' and your customers' employers'
• Legitimate SaaS sending infrastructure, where the platform configured SPF and DKIM correctly

Every one of these authenticates cleanly for the domain it was sent from. jtmerlin-secure.com has valid SPF, a valid DKIM signature, and an aligned From header. DMARC passes. DMARC is doing its job. Its job just is not your customer's question.

What BIMI adds

BIMI puts your logo next to messages that pass DMARC with a strict policy, in clients that support it, if you hold a verified mark certificate. It is a real positive signal, and some customers in some clients will notice it.

What it cannot do is give the customer anything to do about a message that lacks the logo, which is every lure. And logos are exactly what attackers paste in. A missing logo is not an answer.

The question nobody in the chain answers

The customer holding the message wants to know one thing: did my bank send this to me? SPF, DKIM, and DMARC cannot answer it because they have no record of what your bank sent. A gateway can estimate. A brand protection vendor can look for the lookalike domain later. The only party with the record is you.

That is what a communication provenance registry is for. You register each message as you send it, with a recipient bound verify code and a fingerprint of the text. When the customer forwards the lure to verify@jtmerlin.com, there is no registration for it, and the reply says so: no registered communication matches. When they forward a real alert, the reply says you sent it, and when.

Keep DMARC at reject

None of this replaces DMARC. We depend on it: we only process mail to a tenant inbox when the forwarding hop passes DKIM or ARC for a domain the tenant owns, and the reply identity we recommend is a DKIM signed subdomain. DMARC keeps your real domain from being spoofed. Provenance answers your customer about everything else.

Read the full comparison or how the matching works.