That BIMI Logo in Your Phish? It's Not a Bug, It's a Feature.

You're triaging a user-reported email. It has all the hallmarks of a classic phish: manufactured urgency, a suspicious link, slightly off grammar. But there, in the avatar slot where a generic initial should be, is a crisp, verified corporate logo. Your first thought: how?

This isn't a technical failure of the email authentication stack. It’s the opposite. The attacker has successfully configured their infrastructure to pass the very checks designed to stop them. They've turned a trust signal into a Trojan horse.

Brand Indicators for Message Identification (BIMI) is not a security protocol. It's a marketing and deliverability feature built on top of one. It provides a standardized way for a domain to publish a logo that mail clients can display *if and only if* the message passes DMARC authentication. The critical part is that BIMI validates the *domain*, not the sender's claimed *brand*. This is the gap attackers are now exploiting.

The Attacker's Playbook: Weaponizing Trust with Lookalikes

The TTP is straightforward and alarmingly effective. An adversary registers a lookalike or typosquatted domain—think `microsft-support.com` or `citi-securelogin.net`. From there, they build a legitimate-looking email infrastructure on top of this fraudulent foundation.

First, they configure the domain's DNS with ruthlessly correct email authentication records. They publish an SPF record (RFC 7208) that authorizes their sending IPs. They set up DKIM (RFC 6376) and sign their outgoing mail. Critically, they publish a DMARC record (RFC 7489) with a strict policy, `p=quarantine` or even `p=reject`. This isn't just for show; a strict DMARC policy is a prerequisite for BIMI to function in most mail clients.

With DMARC in place, they proceed to the final step: publishing the BIMI record itself. This involves obtaining a Verified Mark Certificate (VMC) from a recognized Certificate Authority. A VMC is a specific type of X.509 certificate that binds a logo (in SVG format) to a specific domain after the CA has verified the organization's right to use that logo. The attacker might register a trademark for their lookalike brand's logo, or find a CA with less stringent validation for a non-trademarked VMC. Once issued, the attacker publishes the BIMI record in DNS, pointing to the logo and its VMC.

The result? When their phishing email hits the target's inbox, the receiving mail server performs the DMARC check. It passes, because the email genuinely originated from the attacker's `microsft-support.com` domain, which they fully control. The mail client sees the passing DMARC verdict, finds the BIMI record, validates the VMC, and proudly displays the attacker's logo next to the message. The user, conditioned to trust these visual cues, is now far more likely to click.

Triage Step 1: Deconstruct the Authentication-Results Header

Your first instinct should be to check the headers, specifically the `Authentication-Results` header. This is where the receiving mail server stamps the verdicts for SPF, DKIM, and DMARC. In a BIMI-enabled phish, you'll see something that looks both right and wrong at the same time.

Authentication-Results: mx.google.com;
dkim=pass header.i=@microsft-support.com header.s=google header.b=ABC...;
spf=pass (google.com: domain of billing@microsft-support.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=billing@microsft-support.com;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=microsft-support.com

Notice what's happening here. DKIM passes for the domain `microsft-support.com`. SPF passes for the same domain. Consequently, DMARC passes. The system is working perfectly. The problem isn't the verdict; it's the domain the verdict applies to. The authentication proves the message is from `microsft-support.com`, not `microsoft.com`. The logo display is authorized for the fraudulent domain, not the legitimate brand.

This header is your ground truth. It immediately tells you that the BIMI display is technically correct based on the DMARC result for the `header.from` domain. Your investigation now shifts from 'Is this broken?' to 'Who actually owns this domain?'

Triage Step 2: Correlate VMC Data with Sender Identity

A passing DMARC and a BIMI record aren't enough. The presence of a logo means there's a VMC involved. Your next job is to find it and inspect its contents. You can typically find the BIMI record for the fraudulent domain using a `dig` or `nslookup` command for the TXT record at `default._bimi.microsft-support.com`.

The record will look something like `v=BIMI1; l=https://path/to/logo.svg; a=https://path/to/vmc.pem;`. The `a=` tag contains the URL to the VMC file. Download that PEM file and inspect it using OpenSSL (`openssl x509 -in vmc.pem -text -noout`).

Check the Certificate's Subject

Inside the VMC, you're looking for the Subject field. This contains the organization's verified legal name. Does the `organizationName` in the certificate match the brand being impersonated? For our `microsft-support.com` phish, the VMC's Subject might list an organization like 'MSFT Support Services LLC', a shell company registered by the attacker. It won't say 'Microsoft Corporation'. This is a massive red flag. The CA validated the entity that requested the certificate, but that entity is not the brand the recipient thinks it is.

Inspect the Trademark Information

If the VMC contains trademark information, it will be in a `1.3.6.1.4.1.58132.1.2` extension. You'll find details like the trademark number, jurisdiction, and registration date. Does this correspond to the legitimate brand's registered trademark? Almost certainly not. The attacker may have even registered their own fraudulent trademark for their lookalike logo, which is a level of dedication that pays dividends in bypassing user suspicion.

Triage Step 3: Hunt for Reputation and Infrastructure Clues

With the authentication and identity layers deconstructed, it's time to zoom out and assess the attacker's infrastructure. Context is everything. A technically perfect set of records on a brand new, suspicious domain is a classic indicator of malicious intent.

Domain Age and History

Run a `whois` on the fraudulent domain. How old is it? Phishing campaign domains are often registered just days or weeks before the attack begins. A `Creation Date` of less than 90 days ago, especially for a domain pretending to be a major corporation, is highly suspect. Contrast this with the legitimate domain's registration date, which will likely be decades old.

SPF and Received Header Analysis

Look at the SPF record again. Does it include IPs or netblocks from budget hosting providers or services known for lax abuse policies? While major brands might use third-party senders, the infrastructure listed for a lookalike domain will often look cheap and transient.

Trace the path of the email through the `Received` headers. Where did the email originate? Are you seeing mail servers with generic hostnames like `srv-123-45-67.cheapvps.net`? This is another signal that you're not dealing with a legitimate corporate mail flow, which would typically involve servers with branded hostnames like `mail-out.microsoft.com`.

Even ARC, the Authenticated Received Chain (RFC 8617), can play a role. While designed to preserve authentication results across hops, a phish originating from the attacker's own server will likely have a simple, short chain, further distinguishing it from complex corporate mail flows that might involve multiple internal relays or security gateways.

The takeaway

A logo in the inbox feels like a guarantee, but it's just another piece of data. BIMI authenticates that a specific *domain* sent a message and authorized a logo—nothing more. It does not, and cannot, verify that the domain represents the *brand* you think it does. The attacker's entire strategy is built on collapsing that distinction in the user's mind.

For the blue team, the takeaway is clear: treat a BIMI logo as a starting point for investigation, not an endpoint of trust. Correlating the DMARC-validated domain, the VMC's organizational data, and the infrastructure's reputation is the only way to expose the truth. Platforms like MailSleuth.AI can automate this header analysis and reputation checking, but the analyst's critical thinking is what ultimately separates the feature from the trap.