When your VMC expires, your BIMI setup no longer has valid certificate evidence. Mailbox providers that require a valid certificate for verified BIMI should stop showing the blue checkmark, and Gmail should stop showing the verified brand treatment tied to that VMC. The logo itself can still appear at mailbox providers that accept self-asserted BIMI, as long as the BIMI record, SVG, DMARC policy, sender reputation, and receiver-specific checks still pass.
The practical answer is: expired VMC means no valid verified mark. It does not make the old certificate partly trusted. It also does not guarantee that every mailbox provider removes the logo at the same second, because receivers cache DNS, fetches, and display decisions. But once the receiver validates the certificate date and sees that it is outside the valid period, the VMC path fails.
I treat this as a certificate lifecycle issue first and a BIMI DNS issue second. The BIMI TXT record can look perfect while the certificate behind the a= tag is expired. A format-only BIMI check catches syntax, but it does not prove that the VMC is currently trusted.
Short answer
An expired VMC makes the certified BIMI path fail. Gmail's blue checkmark disappears once Gmail evaluates the expired certificate. Logo-only display then depends on whether that mailbox provider accepts self-asserted BIMI for the sender and message.
What the receiver checks
A receiver does not simply read the BIMI record and trust the logo. It has to decide whether the message qualifies, whether the domain has DMARC enforcement, whether the logo is valid BIMI SVG, and whether the certificate evidence is valid. The BIMI Group VMC requirements include DMARC enforcement, a BIMI DNS record, a compliant SVG logo, and a verified certificate path for certified logo display.
- Message result: The message must pass authentication checks in a way the receiver accepts for the visible From domain.
- DMARC policy: The organizational domain needs enforcement, usually quarantine or reject, not a monitoring-only policy.
- BIMI record: The DNS record must point to a valid SVG and, for verified display, a certificate file through the a= tag.
- VMC validity: The certificate must be inside its valid date range and chain to a certificate authority accepted by the receiver.
- Receiver policy: Each mailbox provider applies its own display rules, caching, reputation thresholds, and user interface choices.
Flowchart showing BIMI display failing when the VMC validity check fails.
Does an expired VMC become self-asserted BIMI?
In practice, yes for some receivers, but the wording matters. An expired VMC is not a valid certificate. The receiver can reject the certified evidence and then decide whether the remaining BIMI record qualifies for logo-only display. That is close to self-asserted BIMI behavior, but it is still a receiver decision.
If a mailbox provider requires a valid VMC for any BIMI logo display, the logo disappears with the checkmark. If a mailbox provider accepts self-asserted BIMI, the logo can continue to appear without the verified mark. Yahoo Mail, AOL, and La Poste are the usual examples people check when they are testing logo-only BIMI behavior.
Valid VMC path
- Certificate status: The VMC is inside its valid date range and chains to an accepted issuer.
- Gmail result: The message qualifies for verified logo treatment when all other checks pass.
- Brand signal: The receiver has evidence that the logo belongs to the sending organization.
Expired VMC path
- Certificate status: The VMC date check fails, even when the BIMI TXT syntax looks correct.
- Gmail result: The blue checkmark and verified brand treatment stop after evaluation.
- Logo signal: Logo-only display depends on the receiver accepting self-asserted BIMI.
This distinction explains a confusing result: a sender can have a correct BIMI record, a reachable SVG, and a certificate file at the right URL, yet still get no Gmail mark because the certificate expired. A sender can also see a logo in one mailbox and no logo in another because the receiver rules are different.
Expected behavior by mailbox provider
The table below is the operational way I think about it. It is not a promise that every message renders the same way every time, because receiver reputation and caching still matter. It is the correct troubleshooting model when a VMC expires.
|
|
|
|
|---|---|---|---|
 Gmail | Certified path fails | No | No |
 Yahoo Mail | Verified mark fails | Receiver-specific | No |
 AOL | Verified mark fails | Receiver-specific | No |
 La Poste | Verified mark fails | Receiver-specific | No |
Other providers | Policy varies | Depends | No without valid cert |
Likely receiver behavior after VMC expiry
Gmail inbox row showing no blue verified checkmark beside the sender.
The most common trap is assuming that Gmail is using the same fallback logic as providers that accept self-asserted BIMI. It does not work that way for the blue checkmark. For Gmail, the certificate is part of the visible trust signal. If the certificate is expired, the visible trust signal fails.
How to confirm the VMC is the problem
I start with DNS because it tells me where the evidence file lives. A normal BIMI record with a VMC has an l= tag for the SVG and an a= tag for the certificate. If the certificate URL returns a PEM file, the next question is simple: is the certificate currently valid?
BIMI record with a certificateDNS
default._bimi.example.com. 3600 IN TXT ( "v=BIMI1; l=https://assets.example.com/bimi.svg; " "a=https://assets.example.com/vmc.pem" )
- Find the record: Look up the default BIMI selector first, then any selector the sender actually uses.
- Fetch the certificate: Open the URL in the a= tag and confirm it returns the expected PEM file.
- Check dates: Inspect the notBefore and notAfter values. If notAfter is in the past, the VMC has expired.
- Check DMARC: Confirm the organizational domain has enforcement and the message passes DMARC.
- Send a test: Send real mail through the affected stream and inspect what each mailbox provider renders.
Suped's product helps with the DMARC side of this workflow because it ties source authentication, SPF, DKIM, policy state, blocklist (blacklist) signals, and issue alerts together. Its DMARC monitoring helps spot the authentication failures that stop BIMI before the VMC even matters.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
If you need a fast DNS sanity check, Suped's DMARC checker is useful before you start debugging the certificate itself. If the domain is not at enforcement, spend time there first.
What to fix and in what order
The fix is not to remove BIMI unless you need an emergency rollback. The right fix is to renew or replace the mark certificate, publish the new certificate file, update the BIMI record if the certificate URL changed, and then retest mail that actually leaves your production sending platform.
Renewal sequence
- Renew certificate: Complete the VMC renewal with the certificate issuer before changing DNS.
- Publish PEM: Host the renewed certificate at a stable HTTPS URL controlled by your team.
- Update BIMI: Change the a= value only if the certificate URL changed.
- Retest mail: Send real messages and check both authentication results and inbox rendering.
Do not assume the logo returns immediately. DNS TTL, cached certificate fetches, cached SVG fetches, and mailbox provider rendering caches all add delay. For an expired certificate, I check again after the DNS TTL, then again after a full day, then I compare the same message stream across Gmail and a mailbox provider that accepts logo-only BIMI.
Self-asserted BIMI recordDNS
default._bimi.example.com. 3600 IN TXT ( "v=BIMI1; l=https://assets.example.com/bimi.svg" )
Removing the a= tag leaves a self-asserted BIMI record. That can be acceptable for providers that display self-asserted logos, but it will not restore Gmail's verified mark. If the business cares about the Gmail blue checkmark, the VMC renewal is the fix.
Why a valid-looking BIMI record still fails
A BIMI record can be syntactically valid and still fail display. This is why I separate record format from certificate validation. A DNS parser can confirm v=BIMI1, the SVG URL, and the certificate URL without checking whether the certificate is expired, revoked, issued for the right mark, or chained to an accepted issuer.
VMC renewal risk window
A simple way to decide how urgently to act before the certificate expires.
Healthy
90+ days
Renewal has enough time for validation and publishing.
Watch
30-89 days
Start renewal and verify trademark details now.
Critical
1-29 days
Escalate because display loss is close.
Expired
0 days
Verified BIMI fails until the certificate is renewed.
The better monitoring pattern is to treat BIMI as the final layer on top of reliable domain authentication. Suped's domain health checker helps check the base DMARC, SPF, and DKIM posture. For ongoing policy changes, Hosted DMARC gives teams a controlled way to stage enforcement without making every DNS change manually.
For most teams, Suped is the stronger practical choice for DMARC operations because it turns aggregate reports into clear issues, alerts on real authentication changes, and brings SPF, DKIM, DMARC, hosted SPF, hosted MTA-STS, and reputation checks into one workflow. BIMI still needs a valid mark certificate, but weak DMARC operations break the whole chain before the logo is even considered.
Checks that prevent repeat failures
The prevention work is simple, but it needs an owner. Someone has to own the certificate renewal date, the hosted certificate URL, the BIMI SVG, and the DMARC enforcement state. When ownership is split between brand, legal, DNS, and email operations, BIMI breaks quietly.
|
|
|
|---|---|---|
VMC | Security or IT | No checkmark |
Trademark | Legal | Renewal delay |
SVG | Brand | Logo rejected |
DNS | IT | Record stale |
DMARC | Email ops | BIMI blocked |
Operational ownership for BIMI and VMC
I also keep a specific test for certificate expiry. It is not enough to validate BIMI record syntax. The test has to fetch the certificate and inspect the date. The SSL.com VMC details page is useful background on how VMCs are tied to certified logo use and mark ownership.
- Expiry reminders: Set reminders at 90, 60, 30, 14, and 7 days before the notAfter date.
- Real-message tests: Test through each production mail stream, not only through a DNS checker.
- URL stability: Keep certificate and SVG URLs stable so renewal does not require avoidable DNS churn.
- Policy guardrails: Protect DMARC enforcement from accidental rollback to monitoring-only mode.
For deeper follow-up, I would check the VMC expiry guide, confirm Gmail and VMC requirements, and use a BIMI validation guide when the SVG or certificate format is suspect.
Views from the trenches
Best practices
Track certificate expiry beside DMARC policy so logo loss is caught before launch dates.
Test BIMI with a real message because a valid DNS record alone does not prove display.
Keep the SVG, PEM file, and DNS record under owned HTTPS paths with change control.
Common pitfalls
Assuming a BIMI record is healthy while the certificate date has already passed.
Expecting Gmail to show a verified mark when the VMC chain fails date validation.
Renewing the certificate but leaving the BIMI a tag pointed at the old PEM file URL.
Expert tips
Set renewal reminders at 90, 30, and 7 days because BIMI has receiver-side caching.
After renewal, send real mail through each major stream and inspect authentication results.
If display still fails, compare the From domain, DMARC policy, SVG, and certificate subject.
Marketer from Email Geeks says a brand can have a correct-looking BIMI record and still lose Gmail display when the certificate behind the record has expired.
2026-01-14 - Email Geeks
Expert from Email Geeks says the expired certificate should be treated as failed VMC evidence, leaving only receiver-specific logo-only BIMI behavior.
2026-01-15 - Email Geeks
The operational takeaway
When a VMC expires, the Gmail blue checkmark is gone until valid certificate evidence is restored and Gmail refreshes its decision. The BIMI logo can still appear in places that accept self-asserted BIMI, but that is not the same as certified BIMI and it does not restore verified status.
The clean fix is to renew the VMC, keep DMARC at enforcement, verify the SVG and PEM URLs, and test real messages after DNS and receiver caches have time to update. I would not treat a correct BIMI TXT record as proof of health unless the certificate date and chain have also been checked.
Best practical rule
Monitor VMC expiry like any other production certificate. BIMI sits on top of DMARC, but the visible verified mark depends on a valid certificate at the moment the receiver evaluates the message.
