Why DMARC passes on phishing

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 asking.

What DMARC actually checks

SPF answers whether the sending server is authorized 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 aligns 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

Direct spoofing of northfieldbank.com fails DMARC at a bank with a reject policy, so attackers do not do it. They send from:

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

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

What BIMI adds

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

It gives the customer nothing to do about a message that lacks the logo, which is every lure, and logos are exactly what attackers paste into their messages. 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 the institution.

That is what a communication provenance registry is for. The institution registers each message at send time with a recipient bound verify code and a content fingerprint. When the customer forwards the lure to verify@northfieldbank.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 the institution sent it, with the time.

Keep DMARC at reject

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

Read the full comparison or how the matching works.