Blog · Bimi
Why Your BIMI Logo Disappears When Your VMC Certificate Expires
Why Your BIMI Logo Disappears When Your VMC Certificate Expires
An expired Verified Mark Certificate is the usual reason a BIMI logo stops rendering. Nothing in DNS changes when that date passes, so every "is my record still there" check still returns yes. The BIMI record is a pointer to two files. One of those files, the certificate behind the a= tag, has a hard expiry date, and when it passes the logo stops showing.
Here is a concrete case. A practitioner checking BIMI for a large US bank found the bank's VMC had expired on 2026-05-16. The certificate was issued by DigiCert under "DigiCert Verified Mark RSA4096 SHA256 2021 CA1". Everything else was fine. The DNS record was published, the logo URL returned HTTP 200 with image/svg+xml, and a format checker called the record valid. One date inside a file was the whole problem.
The short answer: the record is fine, the certificate is not
If you want the fix in three commands, here it is. Pull the record, fetch the certificate, read the date:
bash
dig TXT default._bimi.example.com +short
curl -s https://example.com/vmc.pem | openssl x509 -noout -dates
If notAfter is in the past, you have your answer. Everything else in this article explains why the usual checks did not warn you, what to do next, and how to stop it happening again.
Why an expired certificate breaks nothing you can see
A BIMI record looks like this:
text
default._bimi.example.com IN TXT "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem"
Three moving parts, each with its own failure mode:
| Part | Where it lives | What a format check sees |
|---|---|---|
| The record | DNS TXT at default._bimi. | Present, syntactically valid |
| The logo | The SVG at the l= URL | HTTP 200, image/svg+xml |
| The certificate | The PEM at the a= URL | HTTP 200, a valid PEM chain |
All three can be healthy on the wire and still fail at the mailbox provider, because the certificate has a notAfter date and a DNS record does not.
The number that makes this an annual event
BIMI Mark Certificates have a maximum validity period of 398 days. The BIMI Group says so directly, and points at the AuthIndicators Working Group Mark Certificate Requirements as the source. The same FAQ notes the 47-day TLS baseline rule does not apply to BIMI mark certificates, because they live in a separate PKI, and that there is no plan to shorten the maximum.
So a deployed VMC sits on a yearly clock. A real one, not a theoretical one.
What actually breaks when the date passes
An expired VMC does not fall back to self-asserted BIMI. This is the point people get wrong most often. Expiry does not demote a certified record to an uncertified one. It removes the valid evidence, and the certified path stops working. If you want a self-asserted record, you publish it deliberately. Expiry does not do it for you.
The Gmail checkmark goes first. Google requires a Valid Mark Certificate for the verified checkmark, and it revalidates on its own schedule. Once the certificate is past notAfter, that mark is gone. Some providers, Yahoo among them, accept a self-asserted record for logo display without a checkmark.
Your authentication does not change at all. SPF, DKIM and DMARC are untouched by a certificate expiry. Mail is still accepted, still delivered, still signed. What you lost is brand display, not deliverability.
Here is the full picture of what does and does not change once the date passes:
| What | After the certificate expires |
|---|---|
| SPF, DKIM and DMARC results | Unchanged |
| Your DMARC policy and its enforcement | Unchanged |
| The BIMI DNS record | Unchanged, still published |
| The logo file | Unchanged, still downloads |
| The certificate file | Unchanged on disk, but past notAfter |
| The Gmail checkmark | Gone |
| A logo without the checkmark | Still possible, but only if you publish a CMC yourself |
The reporting gap: no DMARC report will ever tell you
RFC 7489 defines the DMARC aggregate report format. The string "bimi" does not appear anywhere in it. The report schema has policy_published, identifiers, auth_results, dmarc_aggregate_report and the optional failure block. There is no BIMI element, because BIMI was not part of that standard.
BIMI failure reporting does exist as draft-adams-bimi-reporting, an individual Internet-Draft that has not been published as an RFC. No mailbox provider is required to send it.
The practical consequence: no DMARC aggregate report you receive will ever tell you that your logo stopped rendering. Your DMARC tooling is looking in the wrong place. If you rely on DMARC reporting to notice problems, this failure mode is silent by design.
What I found when I checked 24 major brands
On 2026-10-24 I looked up default._bimi. for 24 large-brand domains, fetched the a= certificate URL where one was published, and read the certificate dates.
- 14 domains published a BIMI record containing a certificate URL.
- 2 of those 14 referenced an expired certificate.
- The other 12 carried certificates with expiry dates between 2027-04-08 and 2027-10-15. Observed lifetimes ran from 364 to 396 days, all inside the 398-day maximum.
The two expired ones:
| Domain | Certificate validity | Status at scan | Record still published? | SVG / PEM |
|---|---|---|---|---|
| opentable.com | 2021-08-12 to 2022-08-12 | Expired just over four years | Yes | Both HTTP 200 |
| zoom.us | 2025-07-11 to 2026-08-11 | Expired 74 days earlier | Yes | Both HTTP 200 |
Every check most people run returns a pass on both of those domains. The DNS record resolves. The SVG downloads with the right content type. The PEM downloads and parses as a certificate. The only thing wrong is a date in the past.
That is not a story about carelessness. It is a story about blindness. The most common way to notice a broken BIMI deployment is a marketing colleague asking why the logo vanished.
For contrast, bankofamerica.com now publishes a certificate valid from 2026-04-11 to 2027-04-13. The expired certificate found in May 2026 had been renewed by then, and the DNS record never had to change.
How to check your own certificate in under a minute
If you want the fast answer first, the DMARCFlow BIMI Checker pulls the record from your DNS, validates the logo and the VMC, and shows the record as a mailbox provider would see it. It needs no account. Treat it as the first pass, not the last word, because the authoritative expiry date lives inside the certificate file.
Then confirm it yourself. Four steps, copy-paste ready.
Step 1: read the BIMI record
bash
dig TXT default._bimi.example.com +short
You are looking for v=BIMI1, an l= URL and, if the domain is certified, an a= URL. One note on l=: in Google's certificate-based setup the logo is embedded in the certificate, so l= can legitimately be empty. An empty l= is not by itself a fault.
Step 2: check the logo URL and its content type
bash
curl -sI https://example.com/logo.svg | grep -i content-type
image/svg+xml is required. A misconfigured web server serving text/plain or application/octet-stream is a common second cause of a missing logo, and it has nothing to do with certificates. The host also has to speak TLS, and Google recommends TLS 1.2 or later for the server hosting your BIMI files.
Step 3: read the certificate dates
bash
curl -s https://example.com/vmc.pem | openssl x509 -noout -dates -subject -issuer
You get notBefore and notAfter. Compare notAfter with today. If it is in the past, you have your answer.
Step 4: confirm DMARC is still enforcing
bash
dig TXT _dmarc.example.com +short
You need p=quarantine or p=reject, and pct=100. The BIMI Group implementation guide says the policy must be enforced on the organizational domain and its subdomains, and that "none" policies or a pct below 100 are not accepted. Google says the same.
A policy that quietly drifted back to p=none kills the logo just as effectively as an expired certificate. It is the second most common cause, and it is the one people look in the wrong place for. The DMARCFlow DMARC Checker checks DMARC, SPF and DKIM together with no login required.
What else makes a BIMI logo disappear
If the certificate dates check out, you are looking at a different problem. The BIMI Group lists the usual causes of a logo that does not display, and only one of them is certificate expiry:
- DMARC not enforced, or identifier alignment broken
- The SVG or the certificate cannot be retrieved
- The provider's own reputation thresholds are not met for the sending domain
- The certificate is missing or invalid where the provider requires one
- Interface caching, where the provider is still showing a previous state
The third one catches people out. A domain can have perfect authentication and a valid certificate and still not display a logo, because the provider gates logo display on its own sender reputation. That is a deliverability problem, not a BIMI problem, and no amount of certificate renewal fixes it.
What to do when the certificate has already expired
Renew the VMC if you want to keep the Gmail checkmark. That is the only route to a verified mark. Renewal is a conversation with your mark certificate authority. No monitoring tool can do it for you.
A CMC gives you a logo without the checkmark. A Common Mark Certificate covers the logo for domains without a registered trademark. It does not produce a verified checkmark. It is a different product, not a downgrade of the same one.
Publish the replacement before you have to. The a= URL does not have to change. Serve the new PEM from the same location and leave the DNS record alone. The bankofamerica.com example above works exactly that way.
Making sure it does not happen again
Add the expiry date to one recurring check. The certificate file has the date. Read it on a schedule and treat the result like you treat a TLS expiry. The one-line version of the check is the same command as before:
bash
curl -s https://example.com/vmc.pem | openssl x509 -noout -enddate
If you already run a DMARC check on a cadence, fold the BIMI certificate expiry into the same job rather than creating a second process. For DMARC report analysis, the DMARCFlow Email Header Analyzer is the quickest way to prove that authentication is still passing while the logo is gone, which is the combination that makes people doubt their own setup.
The threshold to alert on. Alert at 60 days out. A renewal cycle that starts 60 days before expiry leaves room for a failed issuance, a pending trademark query or a support queue.
Put the renewal in the calendar before the CA window opens. This is the part people underestimate. Google notes that a trademark can take 6 to 12 months to obtain, and a VMC requires a registered trademark. For a first-time applicant the lead time is measured in months. For a renewal the CA window is shorter but still not instant. Expect the logo to lag the new certificate too: providers revalidate on their own schedule, and certificate vendor documentation puts the wait for a published BIMI record to start displaying in Gmail at up to seven days. Renewal does not restore the checkmark instantly.
A check you can run right now
Fifteen minutes, three commands, one date to look at:
1. Pull the BIMI record with dig and note the a= URL.
2. Run the openssl x509 -noout -dates command on it and write the notAfter date somewhere you will see it in 60 days.
3. Confirm your DMARC policy is still p=quarantine or p=reject with pct=100.
If the date is in the past, start the renewal conversation now and check what a CMC would cost you if you only need the logo.
If you want continuous monitoring rather than a manual audit, DMARCFlow runs from EUR 1.00 per month on the Personal plan and EUR 34.99 per month on SMB, both excluding VAT, with Enterprise on request and no lock-in. That buys ongoing DMARC report analysis and visibility into who sends on your domain, which is a different job from renewing a certificate. To be straight about the limit: DMARCFlow validates the BIMI record, the logo and the certificate retrieval path. It does not renew anything, it does not alert on certificate expiry, and it does not replace the relationship with your certificate authority. The notAfter line in the certificate file stays the authoritative date.
Frequently asked questions
Is my email still authenticated if my VMC expired?
Yes. SPF, DKIM and DMARC are unaffected by a certificate expiry. Mail is still delivered and still signed. You lost brand display, not authentication.
How long is a VMC valid for?
Maximum 398 days, per the BIMI Group and the AuthIndicators Working Group Mark Certificate Requirements. In practice, observed lifetimes across the 14 published certificates I checked ran from 364 to 396 days.
Will my BIMI logo come back automatically after I renew?
Do not count on the timing. The DNS record can stay exactly as it is, but providers revalidate on their own schedule and caching means the logo can lag the new certificate. Certificate vendor documentation puts the wait for a published record to start displaying in Gmail at up to seven days.
Does an expired VMC get treated as self-asserted BIMI?
No. Expiry removes the valid evidence. It does not demote a certified record to an uncertified one. A self-asserted record is a separate DNS state you publish deliberately.
Can I keep the Gmail logo without the checkmark?
With a Common Mark Certificate, yes. Gmail shows a checkmark only for a VMC. A CMC covers the logo for domains without a registered trademark, but it does not produce the verified mark.