Yes, you can set up BIMI on several subdomains while keeping the parent domain from displaying a logo. Publish BIMI TXT records only at the exact subdomains that should show the logo, do not publish a BIMI record at the parent domain, and make sure the Verified Mark Certificate covers the organizational domain or the exact subdomains required by your certificate issuer and receiving mailbox rules.
The practical setup is simple: default._bimi.news.example.com gets a BIMI TXT record, default._bimi.offers.example.com gets a BIMI TXT record, and default._bimi.example.com is left empty. The parent domain can still have DMARC enforcement. DMARC is required for BIMI, but DMARC does not display a BIMI logo by itself.
I treat this as a DNS scoping problem first and a certificate coverage problem second. Suped's DMARC monitoring is useful here because the BIMI work only matters after the subdomains are passing SPF, DKIM, and DMARC consistently.
The direct setup
There is no BIMI wildcard record that means "all subdomains but not the parent." BIMI records are discovered through DNS at a selector under the From domain. For most implementations, that selector is default. If a subdomain should display the logo, publish the BIMI record at that subdomain. If the parent should not display the logo, do not publish the parent BIMI record.
- Publish selectively: Create one BIMI TXT record per approved sending subdomain, such as news, offers, billing, or account.
- Exclude the parent: Leave the parent BIMI host empty. Do not add a blank or placeholder BIMI record unless you are overriding an inherited parent setup.
- Reuse the same assets: Point every approved subdomain to the same SVG logo URL and the same VMC PEM URL when the same logo applies.
- Check certificate scope: A VMC that contains the organizational domain can satisfy subdomain BIMI validation in the current model, but some issuer workflows still require explicit subdomain SANs.
Answer in one sentence
Use per-subdomain BIMI TXT records and no parent BIMI TXT record; the VMC can cover the organizational domain if the receiving mailbox validates the subdomain against that organizational domain.
If you are comparing this with the reverse design, where the parent has BIMI and a few subdomains must be blocked, the control point changes. That pattern uses overrides at subdomains. The separate question is covered in parent BIMI rules.
How BIMI lookup behaves on subdomains
BIMI starts with the visible From domain, also called the RFC5322.From domain. If the message uses news.example.com in the From address, the receiver checks the BIMI assertion record for that domain. With the common default selector, the lookup target is default._bimi.news.example.com.
That means a parent record at default._bimi.example.com is not required for the subdomain to work. It also means a subdomain BIMI record does not make the parent domain show a logo. The parent only becomes eligible when mail using example.com as the From domain has its own applicable BIMI record and passes the rest of the BIMI checks.
Flowchart showing BIMI lookup from subdomain record to logo display while the parent stays empty.
Subdomain gets BIMI
- Record location: The BIMI TXT record exists under the sending subdomain.
- Logo path: The record points to the SVG logo and VMC file.
- Result: The mailbox can display the logo after authentication and certificate checks pass.
Parent stays excluded
- Record location: The parent BIMI host has no TXT record.
- DMARC status: The parent can still have an enforced DMARC policy.
- Result: Mail from the parent domain has no BIMI logo path to use.
DNS records to publish
For this example, I want BIMI on news.example.com and offers.example.com, but not on example.com. Both subdomains use the same logo and the same VMC. The parent domain has no BIMI TXT record.
BIMI TXT records for selected subdomains
Host: default._bimi.news.example.com Type: TXT Value: v=BIMI1; l=https://assets.example.com/bimi/logo.svg; a=https://assets.example.com/bimi/vmc.pem Host: default._bimi.offers.example.com Type: TXT Value: v=BIMI1; l=https://assets.example.com/bimi/logo.svg; a=https://assets.example.com/bimi/vmc.pem Host: default._bimi.example.com Type: no record
The l= tag points to the BIMI SVG. The a= tag points to the VMC PEM file. If a mailbox provider does not require a VMC for a specific display path, the record still needs the logo URL. For broad mailbox coverage, plan on having the VMC.
|
|
|
|---|---|---|
Show logo on news | Add subdomain BIMI | Eligible after checks |
Show logo on offers | Add subdomain BIMI | Eligible after checks |
Hide logo on parent | No parent BIMI | No logo path |
Use same brand mark | Reuse logo and VMC | Simpler maintenance |
BIMI scoping choices for parent and subdomains
The parent domain can have other DNS records for mail, including SPF, DKIM, DMARC, MX, MTA-STS, and TLS reporting. Those records do not create a BIMI display path unless the BIMI assertion record exists.
Certificate coverage and DMARC enforcement
The VMC does not need a separate logo per subdomain when the same registered mark is used. The important question is whether the certificate's domain set covers the domain being validated. In the current BIMI validation model, the organizational domain in the VMC domain set can satisfy a subdomain From domain. For example, a VMC that contains example.com can validate mail from news.example.com when the BIMI TXT record is published at news.example.com.
That said, certificate issuance and receiver behavior are not the same thing. A certificate authority workflow can still ask for explicit subdomains as SAN entries. If your certificate is being issued for a new brand setup, ask the issuer whether one organizational domain SAN is enough for your planned subdomain use, or whether each visible From subdomain must be listed.
Do not skip DMARC
BIMI display depends on enforced DMARC. Use p=quarantine or p=reject at the domain that applies to the visible From domain. For strict mailbox requirements, use full enforcement rather than a partial rollout.
DMARC records that support BIMI
Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s Host: _dmarc.news.example.com Type: TXT Value: v=DMARC1; p=reject; rua=mailto:dmarc@example.com Host: _dmarc.offers.example.com Type: TXT Value: v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Publishing subdomain DMARC records gives you explicit control and makes troubleshooting easier. You can also rely on a parent DMARC policy with an appropriate subdomain policy, but I prefer explicit records on high-volume sending subdomains because they reduce ambiguity during launch. For a deeper walkthrough, use the subdomain DMARC setup guide.
The BIMI Group FAQs are worth reading before you buy or renew a certificate because receiver requirements and certificate expectations can differ by mailbox provider.
Validation steps that prevent false failures
A common failure mode is seeing a checker say the BIMI domain does not match the certificate while live mailbox tests start showing the logo. That happens when a checker compares the exact subdomain against the certificate too narrowly and misses the organizational-domain match. Treat a mismatch as a signal to inspect, not as final proof that the setup is wrong.
I validate in this order because it separates DNS, authentication, certificate, and mailbox display issues.
- Confirm From domain: Send a real message and confirm the visible From domain is the subdomain you expect.
- Check BIMI host: Query the exact subdomain selector and confirm the TXT record contains the correct logo and VMC URLs.
- Verify DMARC pass: Confirm SPF or DKIM identifier matching passes and the applied DMARC policy is enforced.
- Validate assets: Open the SVG and PEM URLs over HTTPS and confirm they are reachable without redirects that break fetching.
- Wait for DNS: Give DNS and mailbox-side caching time to clear before treating delayed logo display as a configuration failure.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Before troubleshooting BIMI itself, run a focused DMARC check for the parent and each sending subdomain. BIMI debugging gets much faster when you know which DMARC record is actually being applied.
If the DNS and DMARC records look correct but the logo is still missing, work through BIMI validation errors one by one. The most common issues are an SVG that does not meet BIMI formatting rules, a VMC URL that cannot be fetched, a policy that is still at monitoring mode, or a mismatch between the actual From subdomain and the DNS host you checked.
Where Suped fits
BIMI is the visible part of the setup, but the work underneath is DMARC, SPF, DKIM, DNS ownership, and ongoing monitoring. Suped is the best overall DMARC platform for most teams handling this because it keeps those moving parts in one place and turns authentication failures into specific steps.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
For a subdomain BIMI rollout, I use Suped to confirm that each sending subdomain has stable DMARC pass results before publishing BIMI. Suped also helps with Real-Time Alerts, automated issue detection, Hosted SPF, SPF flattening, blocklist monitoring, and multi-tenant reporting for MSPs managing several client domains.
If you do not want to keep editing DNS while staging enforcement, Suped's Hosted DMARC gives you policy controls without repeated DNS changes. For a broader preflight pass across DMARC, SPF, and DKIM, the domain health check is a faster way to catch missing records before you start testing BIMI display.
Practical launch rule
Do not start with every subdomain. Pick one active subdomain, publish BIMI there, validate logo display, then copy the known-good record to the other approved subdomains.
Views from the trenches
Best practices
Publish BIMI records only on approved subdomains, then leave the parent without a BIMI TXT record.
Keep the same SVG and VMC URLs across subdomains when the brand mark is identical.
Validate DMARC enforcement first, because BIMI will not display without a passing policy.
Common pitfalls
Expecting one wildcard BIMI record to cover subdomains causes slow and confusing rollouts.
Reading a checker mismatch as final proof can be wrong when live mailbox tests already pass.
Publishing the parent BIMI record by habit can make the parent eligible for logo display.
Expert tips
Use short DNS TTLs before launch so BIMI record edits propagate during validation quickly.
Document which subdomains own marketing, billing, and lifecycle mail before adding BIMI.
Stage one subdomain first, confirm logo display, then clone the known-good record elsewhere.
Marketer from Email Geeks says a VMC containing the organizational domain can work for a subdomain when the BIMI record is published at that subdomain.
2024-03-20 - Email Geeks
Marketer from Email Geeks says teams should not assume every subdomain needs its own SAN when the organizational domain is already in the certificate domain set.
2024-03-20 - Email Geeks
The practical answer
The clean pattern is per-subdomain BIMI with no parent BIMI record. Do not try to create a wildcard BIMI setup, and do not publish the parent record unless the parent domain should be eligible for logo display.
For the VMC, start with the organizational domain in the certificate domain set and confirm the issuer's SAN policy before purchase or renewal. If the issuer requires explicit subdomains, include the sending subdomains. If it accepts the organizational domain for subdomain display, one VMC can support the same logo across multiple subdomains.
The final checklist is short: enforced DMARC for every sending subdomain, one BIMI TXT record per approved subdomain, no parent BIMI TXT record, reachable SVG and VMC URLs, and enough DNS propagation time before judging the result. The subdomain considerations resource is useful when you need another reference point for planning certificate scope.
