Yes, a VMC can work on a subdomain even when that exact subdomain is not written in the certificate, as long as the subdomain sits under the base sending domain covered by the VMC. If the VMC covers example.tech, then mail sent as edu.example.tech is normally inside that base-domain coverage.
The confusing part is that some validators report this like a normal TLS certificate hostname problem: x509 says the certificate is valid for the base domain, not the subdomain. That message can be misleading for BIMI, because a VMC is not used like a web server certificate. A VMC binds an organization, logo, and sending domain for BIMI. It does not encrypt traffic and it does not need a private key or CSR.
The fix is not automatically to buy a new VMC for every subdomain. First, check whether your BIMI DNS records are being discovered as intended. In many setups, I keep the BIMI record on the organizational domain and let subdomains inherit it, then publish a subdomain BIMI record only when that subdomain needs a different logo, selector, or certificate reference.
The short answer
A subdomain does not need to be explicitly listed in a VMC when the base domain is already listed and the subdomain belongs under that same registrable domain. The DigiCert FAQ states the practical rule clearly: sending domains need to be listed, but subdomains are covered by the base domain.
Rule of thumb
If your VMC covers example.tech, you normally do not need a separate certificate entry for mail.example.tech, edu.example.tech, or billing.example.tech. If you also send as example.co.uk, that is a different base domain and it needs to be included.
The part that still needs care is BIMI record discovery. The BIMI Group FAQ describes the usual setup: publish a default BIMI record at the organizational domain so subdomains can inherit it, and publish a subdomain record only when you want that subdomain to use its own record.
- Certificate scope: The VMC can cover subdomains under the listed base domain.
- BIMI lookup: Receivers check the sender's visible From domain, then use the discovered BIMI record.
- DMARC gate: BIMI display still depends on DMARC passing with an enforcement policy.
- Provider decision: Mailbox providers decide whether the logo appears after the technical checks pass.
Why the x509 error appears
The error usually comes out of a generic certificate validation path. In ordinary TLS, a certificate for example.tech does not automatically match edu.example.tech unless the certificate also contains that subdomain or a valid wildcard. That web-certificate rule is familiar, so many libraries report a plain hostname mismatch.
BIMI VMC validation has a different goal. It checks whether the certificate is valid for the domain identity used by BIMI and whether the referenced logo matches the logo bound into the certificate. A plain TLS-style hostname error tells me to inspect the record path by hand before assuming the VMC is unusable.
TLS hostname thinking
- Exact host: The validator expects the exact DNS name in the certificate.
- Wildcard rule: A wildcard covers only the allowed host depth for web TLS.
- Wrong model: This can misread a VMC as if it protects a web endpoint.
BIMI VMC thinking
- Base domain: A listed base domain can cover its subdomains for VMC use.
- Logo binding: The SVG referenced in DNS must match the certificate evidence.
- Record path: The receiver uses the BIMI record it discovers for the sender domain.
How BIMI discovery affects subdomains
For a message using edu.example.tech in the visible From address, a receiver can look for a BIMI record at the subdomain. If it finds one there, that record can override the organizational-domain record. If it does not find one, the organizational-domain BIMI record can be used instead. That inheritance pattern is why a single parent record often solves the same-logo, same-VMC case.
This is also why removing the subdomain record can make a failing test pass. You are not making the VMC cover less. You are making the receiver use the parent-domain BIMI record, which fits the certificate path more cleanly. For more detail on this exact inheritance question, see root BIMI inheritance.
Parent BIMI record inherited by subdomainsDNS
default._bimi.example.tech. TXT "v=BIMI1;" " l=https://assets.example.tech/logo.svg;" " a=https://assets.example.tech/vmc.pem"
Subdomain BIMI record when you need an overrideDNS
default._bimi.edu.example.tech. TXT "v=BIMI1;" " l=https://assets.example.tech/edu.svg;" " a=https://assets.example.tech/vmc.pem"
Flowchart showing BIMI lookup moving from subdomain record to parent record and VMC validation.
Multi-level subdomains add another place to make mistakes. A record for default._bimi.example.tech does not mean every custom selector at every lower label has been configured. If you send on deeper names, check multi-level BIMI before changing the certificate.
What I would change in this setup
I would start by listing every visible From domain used by the mail streams. Then I would decide whether each stream needs its own BIMI record. If the same logo and same VMC apply everywhere, the cleanest setup is often one parent-domain BIMI record and no duplicate records on the subdomains.
Do not over-correct the certificate
Buying or reissuing a VMC with every subdomain listed is usually unnecessary when all subdomains are under the same base domain. Check DNS discovery, the certificate URL, the SVG match, and DMARC policy first.
- Inventory senders: List every visible From domain, including marketing, product, receipts, and internal notification streams.
- Check DMARC: Confirm each stream passes DMARC through SPF or DKIM domain matching.
- Simplify BIMI: Keep the parent record when all streams use the same logo and certificate.
- Override only: Publish a subdomain BIMI record only for a different logo, selector, or certificate reference.
- Retest mail: Send a fresh message after DNS has propagated, because cached BIMI results cause stale failures.
A fast domain-wide check helps separate BIMI certificate noise from authentication problems. Suped's domain health check is useful here because it checks DMARC, SPF, and DKIM together instead of treating the VMC error as a standalone issue.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
After that, I would test the specific message path. The visible From domain, DKIM signing domain, SPF return-path domain, DMARC policy, BIMI selector, SVG URL, and VMC URL all need to be read together. One broken part is enough to stop the logo, even if the certificate itself is acceptable.
Where DMARC fits
BIMI sits on top of DMARC. If DMARC is still at p=none, most providers will not show the logo even when the VMC is valid. The domain generally needs an enforcement policy, meaning p=quarantine or p=reject.
DMARC policy readiness for BIMI
A simple way to read whether the domain is ready for VMC-backed BIMI display.
Monitor only
p=none
Useful for discovery, not enough for most BIMI display paths.
Partial enforcement
pct<100
Better, but percentage staging can still block display at some providers.
Full enforcement
quarantine or reject
The practical target for BIMI and VMC deployment.
This is where Suped's product is the strongest practical choice for most teams working toward BIMI. Suped brings DMARC monitoring, SPF and DKIM checks, hosted DMARC, hosted SPF, hosted MTA-STS, SPF flattening, blocklist monitoring, real-time alerts, and issue-specific fix steps into one workflow.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
For a VMC subdomain problem, that workflow matters because the visible symptom is often a certificate warning, while the cause sits in DNS, DMARC policy staging, SPF lookup depth, a missing DKIM signature, or a provider-specific sender stream. Suped's hosted DMARC can also reduce DNS-change friction when teams need controlled policy staging, especially when several subdomains share one parent-domain rollout.
If you need to validate the current DNS policy before changing BIMI, run a DMARC check. If you manage many domains or client domains, hosted DMARC keeps policy changes cleaner than hand-editing TXT records for every step.
Decision table for VMC subdomain cases
I use this table when deciding whether to change BIMI DNS, change the certificate request, or leave the certificate alone.
|
|
|
|---|---|---|
Same base | Covered | Use parent BIMI |
Different base | Needs entry | Add domain |
Different logo | Depends on cert | Use selector |
Expired VMC | Fails | Renew cert |
DMARC none | Not enough | Move policy |
Common VMC and BIMI subdomain decisions
Expiration is easy to overlook because the BIMI DNS record can stay unchanged while the hosted PEM becomes invalid. Keep renewal ownership clear, and review VMC expiry checks before the certificate date becomes an outage.
When I keep subdomain BIMI records
- Different brand: A product line, school, region, or business unit needs its own approved mark.
- Different selector: A stream intentionally chooses a non-default BIMI selector in message headers.
- Different control: A subdomain owner needs independent change control for logo and certificate URLs.
- Different exclusion: A subdomain should suppress BIMI while the parent domain continues to show it.
Views from the trenches
Best practices
Keep the parent BIMI record authoritative when subdomains share the same logo and VMC.
Validate the visible From domain, DMARC policy, SVG URL, and PEM URL as one path.
Document which subdomains inherit BIMI and which ones intentionally override the parent.
Common pitfalls
Treating a VMC like a normal TLS cert leads teams to list needless subdomain names.
Duplicating BIMI records on every subdomain increases drift and stale certificate links.
Testing cached messages after DNS changes makes old BIMI or VMC failures look current.
Expert tips
Work the BIMI discovery path by hand before paying to reissue a certificate too early.
Use subdomain BIMI only when the sender needs a distinct logo, selector, or control.
Track VMC renewal dates with the same ownership model used for DMARC policy changes.
Marketer from Email Geeks says a parent BIMI record can be the right fix when subdomains share the same VMC.
2025-01-09 - Email Geeks
Marketer from Email Geeks says a subdomain not listed in the VMC does not automatically mean the certificate is wrong.
2025-01-09 - Email Geeks
The practical answer
A VMC for the base domain can work for subdomains that sit under that base domain, even when the subdomain is not explicitly named in the certificate. I would not reissue the certificate just because a checker prints a TLS-style hostname mismatch.
The better sequence is to verify the base domain in the VMC, simplify BIMI DNS so the parent record is inherited where appropriate, confirm the SVG and PEM files are publicly reachable over HTTPS, and make sure DMARC is at full enforcement for the sending domain. Only list another domain in the VMC when it is truly a different base domain, or when the certificate issuer's current process requires it for your specific request.
For teams splitting mail streams across many subdomains, Suped's product keeps the operational part manageable: it shows which domains are passing authentication, which ones still need policy work, and where DNS records or sender configuration are blocking BIMI readiness.
