A VMC certificate does not need to be bought separately for every sub-domain just because those sub-domains send email. If the same organization, same verified mark, and same organizational domain are in scope, a VMC validated for the organizational domain can support BIMI display for child sub-domains. The BIMI record at the organizational domain can also be inherited by sub-domains, unless a sub-domain publishes its own BIMI record that changes or suppresses the logo.
The caveat is important: inheritance of the BIMI DNS record and coverage of the VMC certificate are related, but they are not the same thing. The DNS record tells mailbox providers where to find the SVG logo and certificate file. The VMC tells them that a mark verifying authority has checked the organization and the logo rights. If a sub-domain uses a different logo, belongs to a different organizational domain, or needs separate certificate identity, one certificate may not be enough.
I treat BIMI as the display layer on top of email authentication. It only becomes predictable after DMARC is enforced, SPF or DKIM creates a valid domain match, and the logo assets can be fetched over HTTPS. For the authentication side, Suped's DMARC monitoring workflow is the place to watch pass rates, policy state, failing sources, and the sender cleanup needed before BIMI can work.
The direct answer for sub-domains
For a normal setup such as example.com, news.example.com, offers.example.com, and receipts.example.com, one VMC is usually enough when all of those domains use the same registered logo and the certificate is issued for the organization behind the parent domain. A quote that triples the cost because there are three sending sub-domains should be challenged before renewal.
- Same logo: one VMC can cover multiple sending sub-domains when the same verified mark applies.
- Different logo: a separate VMC is needed for each distinct mark that must display in the inbox.
- Different domain: separate organizational domains need explicit certificate coverage or separate certificates.
- Sub-domain override: a child domain can publish its own BIMI record when it needs a different logo path.
The BIMI Group FAQ states that a default BIMI record should be published at the organizational domain and can be inherited by sub-domains. It also notes that a sub-domain can publish its own record, which gives the domain owner a clean way to override inherited display.
Do not approve a per-sub-domain renewal until the issuer confirms why the parent-domain VMC does not cover the child sending domains. The right question is not "how many sub-domains send mail?" It is "how many verified marks and organizational domains must the certificate cover?"
Flowchart showing how an email moves from From domain checks to BIMI logo display.
How the lookup actually works
A mailbox provider starts with the visible From domain, not the return-path alone. If the message is from offers.example.com, the provider checks whether the message passes DMARC for that visible domain. In practice, DKIM is the cleaner path for BIMI because the DKIM signing domain can match the visible From domain even when the sending platform uses its own bounce domain.
After DMARC passes, the provider looks for a BIMI TXT record at the selected BIMI selector. Most senders use the default selector. The parent domain record can apply to child domains, and a child domain can publish a more specific record when needed. That is why a parent-domain BIMI setup can display a logo for sub-domain mail without copying identical records everywhere.
Parent-domain BIMI recorddns
default._bimi.example.com. TXT "v=BIMI1; l=https://brand.example/bimi/logo.svg;" "a=https://brand.example/bimi/vmc.pem"
The value of l= points to the SVG logo. The value of a= points to the certificate file. The provider fetches those assets, checks the certificate, applies its own mailbox policy, and then decides whether to display the logo. A correct DNS record is necessary, but it does not force every provider to show the logo every time.
Inherited parent record
- Best fit: one logo across parent and child sending domains.
- DNS effort: publish once at the organizational domain.
- Risk: logo appears on more sub-domains than intended.
Sub-domain record
- Best fit: a child domain needs a different logo or no logo.
- DNS effort: publish a record at the child BIMI hostname.
- Risk: stale child records can override the parent setup.
When one VMC is enough
One VMC is usually enough when the business owns one trademarked logo and wants that same logo to appear for mail sent by the parent domain and its sub-domains. DigiCert's public DigiCert VMC guidance gives a practical example: multiple email sub-domains with unique email addresses and a single logo can use one VMC.
|
|
|
|---|---|---|
Same logo | One | Same mark |
Different logos | Multiple | Distinct marks |
Different domains | Confirm | Issuer scope |
Seasonal logo | Multiple | New mark |
Typical VMC renewal decisions for sub-domain senders.
The clean renewal request is specific: ask the certificate issuer to validate the organizational domain and confirm whether the child sending domains are covered for the same mark. If the answer is yes, the sub-domain count should not multiply the certificate count. If the answer is no, ask which domain or mark requirement creates the extra certificate need.
DigiCert CertCentral certificate details screen for checking VMC renewal scope.
When a separate certificate is justified
A separate VMC makes sense when the inbox logo changes in a way that the certificate must prove. BIMI is not a general image hosting trick. The certificate is tied to validated rights in the mark, so a new logo normally means a new validation path.
- Brand split: marketing.example.com and billing.example.com use different registered marks.
- Domain split: example.com and example.co.uk need separate coverage under issuer rules.
- Business split: a subsidiary uses a distinct legal identity and its own trademark.
- Selector split: different BIMI selectors point at different logo and certificate pairs.
Sub-domain override exampledns
default._bimi.news.example.com. TXT "v=BIMI1; l=https://brand.example/bimi/news.svg;" "a=https://brand.example/bimi/news-vmc.pem"
That override is useful when a child domain genuinely needs its own brand treatment. It is wasteful when every child domain points at the same SVG and the same verified mark. If you need a deeper walkthrough of inheritance controls, the subdomain BIMI display page covers the parent and child record behavior in more detail.
Why VMCs matter for logo display
A VMC matters because several major mailbox providers will not display a BIMI logo without a certificate. Google and Apple are the most common reason this comes up. A self-asserted BIMI record can still be useful for providers that accept it, but it does not satisfy providers that require certificate-backed mark verification.
|
|
|
|---|---|---|
 Google | Required | No VMC, no logo |
 Apple | Required | Certificate checked |
 Yahoo | Varies | Self-asserted possible |
Provider behavior changes, so treat this as an implementation planning view.
The business reason is simple: the logo is visible to recipients before they read the message. That makes BIMI useful for recognition, but it also means providers need a stronger proof path than a domain owner pointing DNS at any image. A VMC adds that proof path by connecting the logo to a validated organization and mark.
BIMI does not override reputation, mailbox policy, or UI caching. Even with DMARC enforcement, a valid SVG, and a valid VMC, a provider can delay display or choose not to display the logo in a specific inbox view.
If the specific concern is Gmail, the Gmail and VMC page explains why certificate-backed BIMI is different from publishing only a DNS record.
The DMARC work that comes first
I would not start a VMC renewal by looking at certificate line items. I would start by proving that every sending stream using the parent or child domain passes DMARC and that the policy is at enforcement. BIMI generally needs a policy of p=quarantine or p=reject, not a monitoring-only policy.
BIMI readiness by DMARC policy
Mailbox providers still apply their own rules, but policy state is the first gate to check.
Monitoring
p=none
Good for discovery, not enough for BIMI display at many providers.
Partial enforcement
pct below 100
Closer, but percentage settings can still block eligibility.
Enforced
quarantine or reject
The usual baseline before logo display is considered.
Suped's Hosted DMARC helps teams move through policy staging without editing DNS for every small change. That matters when BIMI is tied to several sending platforms and sub-domains, because failed sources need to be fixed before the policy moves to enforcement. Suped also connects the authentication view with blocklist (blacklist) monitoring and real-time alerts, which helps catch reputation or configuration problems before a logo rollout turns into a guessing exercise.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
For a quick check outside the dashboard, use the DMARC checker to confirm the record syntax, then use the domain health checker when you need a broader view of DMARC, SPF, DKIM, and DNS health before publishing BIMI.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A practical rollout plan
For a renewal with multiple sending sub-domains, I use this order. It keeps the certificate decision tied to actual sending behavior instead of a rough domain count.
- Inventory senders: list every parent domain and child domain used in visible From addresses.
- Confirm policy: move the organizational domain and active sub-domains to enforced DMARC.
- Check logo scope: decide whether every stream uses the same registered mark.
- Ask issuer: confirm certificate coverage for the organizational domain and child domains.
- Publish BIMI: use the parent record by default, then override only where needed.
- Send tests: test real mail to target providers and allow for caching delay.
BIMI selector exampletext
BIMI-Selector: v=BIMI1; s=receipts receipts._bimi.example.com. TXT "v=BIMI1; l=https://brand.example/bimi/receipt.svg;" "a=https://brand.example/bimi/receipt-vmc.pem"
Selectors are useful when one domain needs more than one approved logo. They do not remove the certificate requirement for providers that require a VMC. They only tell the provider which BIMI record to query for a given message.
For most teams, Suped is the best overall DMARC platform for this workflow because it combines automated issue detection, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, blocklist monitoring, and multi-domain reporting in one place. That is the operational layer BIMI depends on.
If DNS ownership slows the rollout, Hosted DMARC is a practical way to stage policy changes while the team cleans up senders and prepares the logo assets.
How to avoid inherited logo surprises
The main risk with parent-domain BIMI is not cost. It is unintended display. If the parent record is inherited, a child domain can start showing the parent logo once it meets the same authentication and provider requirements. That is fine for normal brand mail, but not always fine for test domains, partner streams, or internal-only mail.
Before publishing a parent BIMI record, map every sub-domain that appears in the visible From address. Decide which ones should display the brand logo, which ones need their own logo, and which ones should not display a BIMI logo. If a child domain must behave differently, publish a child record or remove that sending pattern from branded mail.
Good parent setup
- Domain map: every visible From domain is known.
- Logo scope: the same verified mark fits each stream.
- DNS control: child overrides are intentional.
Risky parent setup
- Unknown mail: old systems still send from child domains.
- Mixed brands: different logos share one parent.
- No owner: nobody reviews child BIMI records.
The same logic applies to the certificate. If the sub-domain is not explicitly listed in a certificate, the answer still depends on the organizational domain and issuer validation. The VMC subdomain certificate page covers that certificate-specific edge case.
Views from the trenches
Best practices
Verify the organizational domain before pricing separate certificates for every sending subdomain.
Publish a parent BIMI record, then override only the subdomains that need different logos.
Confirm DMARC enforcement before spending time on SVG hosting or certificate renewal.
Common pitfalls
Buying one certificate per subdomain wastes budget when the same verified mark applies.
Publishing BIMI before DMARC enforcement creates a record that major providers ignore.
Using a complex SVG often fails because mailbox providers fetch small, strict files.
Expert tips
Ask the issuer whether one certificate can list the organizational domain and child domains.
Use a no-logo BIMI record only when a subdomain must suppress inherited display.
Track logo tests by mailbox because caching can make a correct setup look broken today.
Marketer from Email Geeks says a VMC validated at the organizational domain can cover child sending domains when the same mark is used.
2025-03-06 - Email Geeks
Marketer from Email Geeks says Google and Apple need a certificate before they show the BIMI logo in supported inbox views.
2025-03-13 - Email Geeks
What I would do at renewal
I would renew one parent-domain VMC when the sub-domains all use the same verified logo and the issuer confirms that the organizational domain coverage applies. I would buy more than one certificate only when there are different marks, different organizational domains, or a clear issuer requirement that cannot be met with the parent-domain certificate.
The bigger work is usually not the certificate. It is getting DMARC enforcement stable across every sender, publishing a clean SVG, making the certificate file reachable, and checking real mailbox display. Suped is strongest here as the operational control point: it shows which senders are ready, which ones are blocking enforcement, and which DNS or reputation issues need fixing before BIMI can work reliably.
