BIMI, VMC, and the Case of the Missing Blue Checkmark

Everything was right, but it was all wrong. The domain's DMARC policy was at `p=reject`, a prerequisite we'd hammered into place months ago. The `_bimi` DNS record was syntactically perfect, pointing to a compliant SVG and a freshly purchased Verified Mark Certificate. The bill from the Certificate Authority was paid. The result in the user's inbox? Nothing. No logo. No coveted blue checkmark in Gmail. Just empty space where the brand should be.

This is the point where the ticket gets escalated. The simple fixes have been tried. DNS propagation has been checked and re-checked. This isn't a typo in a TXT record. This is a ghost in the machine, an expensive ghost, and our job is to hunt it down.

The hunt for a silent failure like this doesn't start with a GUI. It starts on the command line, with the raw cryptographic artifacts themselves. Someone, somewhere, made a mistake, and the evidence is hiding in plain sight, encoded in the bytes of the VMC.

The Anatomy of a Perfect Failure

Before we dive into the guts of the certificate, let's appreciate the scene. This wasn't a half-hearted attempt. The team responsible for this deployment had followed the BIMI standard to the letter, or so it seemed.

First, DMARC was correctly configured and enforced. According to RFC 7489, for BIMI to even be considered by a receiver, the organizational domain's DMARC policy must be `p=quarantine` with a percentage of 100, or a straight `p=reject`. This domain was at `p=reject`, so they had cleared the highest bar. SPF (RFC 7208) and DKIM (RFC 6376) were aligned and passing consistently.

Second, the BIMI record itself was text-book. A `dig TXT default._bimi.example.com` returned a clean result: `v=BIMI1; l=https://media.example.com/images/logo.svg; a=https://media.example.com/certs/vmc-evidence.pem;`. The `l=` tag pointed to the logo, and the `a=` tag pointed to the VMC. The URLs were live and returned HTTP 200 responses.

Finally, the assets themselves appeared correct. The SVG file was a tiny, pristine vector graphic that had been run through a linter to ensure it met the BIMI `tiny-ps` profile—no scripts, no external links, no data URIs. The VMC was a PEM file purchased from a legitimate, recognized Certificate Authority. On the surface, every box was checked. This is what makes this kind of failure so insidious. It's a failure of trust, not syntax.

Following the Paper Trail with OpenSSL

When a complex system fails silently, you have to start interrogating its components directly. For any X.509 certificate, the ultimate ground truth is found with `openssl`. It's not pretty, but it's unambiguous.

Checking the Basics: Subject, Issuer, and Chain

The first step is to grab the certificate and run some basic checks. You can download it directly from the URL in the `a=` tag of the BIMI record. We saved it as `vmc.pem`.

Initial diagnosis uses a simple command: `openssl x509 -in vmc.pem -noout -subject -issuer -dates`. We're confirming three things. Is the subject correct? Does it match the organization's legal name? Is the issuer a known VMC-issuing CA like DigiCert or Entrust? Are the `notBefore` and `notAfter` dates valid? In our case, all three of these checks passed. The certificate was for the right company, issued by the right CA, and was not expired. No red flags here.

Next, we considered the certificate chain. A VMC, like a TLS certificate, is signed by an intermediate CA, which is in turn signed by a root CA. A mail receiver's validator might not perform extra fetching for missing intermediates. The server hosting the VMC must provide the full chain. A quick check of the PEM file showed it contained not just the leaf certificate, but the intermediate as well. Another dead end.

Peeling Back the Layers to the Raw Certificate Contents

With the obvious checks cleared, it was time to dump the entire certificate structure into plain text. This command produces a torrent of output, but it's where the real forensic work begins.

$ openssl x509 -in vmc.pem -text -noout — Terminal Command

Scrolling through the output, we passed the public key, the signature algorithm, and the standard extensions like Key Usage and Subject Alternative Name. Everything looked normal. But VMCs have a special section that standard TLS certificates do not, and that's where the investigation led us next.

The Smoking Gun: A Mismatched Trademark Extension

Buried deep within the X.509 v3 extensions section, we found it. VMCs contain a custom extension defined by the BIMI working group. This extension uses the Object Identifier (OID) `1.3.6.1.4.1.58327.1.1`. This is the cryptographic proof that links the certificate not just to a domain, but to a specific, legally registered trademark.

When `openssl` doesn't have a schema for an OID, it labels it as 'Unknown Extension' and dumps the raw Abstract Syntax Notation One (ASN.1) data. That's what we saw. But feeding that raw data into an ASN.1 parser reveals the underlying structure.

trademark-validation-extension ::= SEQUENCE {
trademarkJurisdiction UTF8String,
trademarkRegNumber UTF8String,
trademarkRegDate GeneralizedTime,
trademarkDescription UTF8String OPTIONAL
} — ASN.1 Definition for VMC Trademark Extension

The parsed data from our 'failed' certificate looked something like this: `trademarkJurisdiction: US`, `trademarkRegNumber: 90817228`, `trademarkRegDate: 2021-08-03`. We then cross-referenced this with the actual trademark record from the U.S. Patent and Trademark Office. The jurisdiction was correct. The date was correct. But the registration number? The official number was `90817288`. A single digit—a `2` instead of an `8`—had been transposed during the certificate issuance process.

This was the smoking gun. When a major mailbox provider like Gmail or Yahoo Mail receives the email, its MTA fetches the VMC. It parses this exact extension. Then it likely queries its own internal or a third-party trademark verification service using the data found in the certificate. When that query comes back with 'no match' because of the typo, the entire BIMI validation fails. It doesn't fall back to a non-VMC logo. It doesn't generate an error report. It just fails silently. The email is delivered, but without the brand logo. From the outside, it looks like nothing happened, which is exactly the problem.

Collateral Damage: Is Your Evidence Document Reachable?

While the primary cause of our incident was the certificate data itself, another common pitfall nearly tripped up our investigation. This is the `a=` tag in the BIMI DNS record.

This tag, which is optional for self-asserted (non-VMC) BIMI but required for VMCs, points to the 'evidence' of your trademark rights. In the case of a VMC, it points to the VMC file itself, which contains the bundled trademark data.

The critical point is that the receiving mail server must be able to successfully perform an HTTP GET request on this URL. It sounds simple, but we've seen this fail in numerous ways. MTAs at major providers aren't running on a web browser inside your corporate network. They are automated, hardened systems on the public internet.

Common Accessibility Failures

First, the URL must be publicly accessible. We've seen teams host their VMC on a development server or an internal storage blob that requires authentication or is restricted by IP address. The MTA's request will get a 403 Forbidden or 401 Unauthorized, and validation will fail.

Second, TLS issues on the hosting server can be fatal. If the server hosting the `.pem` file has an expired, misconfigured, or self-signed TLS certificate, the MTA's secure HTTP client will refuse to connect. The chain of trust must be unbroken from start to finish.

Finally, watch out for redirects. While a single `301` or `302` redirect is usually fine, complex redirect chains or a hop that downgrades from HTTPS to HTTP will often cause the validator to give up. Keep it simple: one public HTTPS URL that directly serves the certificate file.

Remediating and Redeploying: The VMC Playbook

Finding the root cause is satisfying, but the job isn't done until the logo is in the inbox. Fixing a flawed VMC requires a precise, methodical approach.

Engaging the Certificate Authority

You cannot edit a signed certificate. Its immutability is the entire point. The flawed VMC must be revoked and a new one must be re-issued by the CA. This is where your detailed forensic evidence becomes crucial.

Open a high-priority support ticket with the CA. Don't just say 'our VMC isn't working.' State the facts. 'We have discovered a data error in the `trademark-validation-extension` (OID `1.3.6.1.4.1.58327.1.1`) of the VMC issued for serial number XYZ. The `trademarkRegNumber` is listed as `90817228`, but the correct number, per the public USPTO record, is `90817288`. Please re-issue the certificate with the corrected data.' Providing this level of detail—with screenshots and links to the public trademark records—is the fastest way to get the CA's validation team to act.

The Redeployment Checklist

Once the CA provides the new, corrected `.pem` file, you need to deploy it carefully.

First, upload the new certificate file to your public web host, replacing the old one. Ensure its permissions are publicly readable. Second, verify the URL in the `a=` tag of your BIMI DNS record still points to the correct location. Third, do a final check that the URL is accessible from an external network—use a simple `curl -v` from a cloud machine, not your laptop. Finally, after you're certain everything is in place, send a test message to an address at a supporting provider like Gmail. You may need to wait a few minutes for caches to clear, but the blue checkmark and logo should now appear, closing the incident.

The takeaway

A Verified Mark Certificate isn't a fire-and-forget asset you buy once. It is a precise cryptographic statement of identity, where every single byte in its ASN.1 structure matters. The validation process at the receiving MTA is automated, unforgiving, and utterly silent in its failures. It will not send you a bounce or a helpful error message; it will simply decline to display the logo you paid for.

This reality makes hands-on diagnosis a non-negotiable skill for anyone managing email authentication at scale. Trusting that the CA got it right is not a strategy. You must be willing to get your hands dirty with command-line tools to verify their work. Or, you can use a platform that automates this kind of deep-header and certificate analysis, turning hours of guesswork into a clear, actionable finding.