Yes, BIMI can work on multiple levels of subdomains. The part that catches people is where the BIMI record has to live. A BIMI record at a middle subdomain does not automatically roll down to every deeper subdomain. For a message using email.xyz.sample.com in the visible From address, the BIMI record needs to be found at email.xyz.sample.com or at the organizational domain, sample.com. A record at xyz.sample.com alone is not enough.
I treat this as a lookup problem first, not a branding problem. Receivers do not walk every parent label until they find a logo. They check the RFC5322.From domain and the organizational domain under BIMI rules. After that, they check whether the message passes DMARC, whether the BIMI TXT record is valid, and whether the certificate is acceptable for the domain being used.
For the exact setup in the question, sample.com has no BIMI, xyz.sample.com has BIMI, and email.xyz.sample.com needs the logo. The fix is to publish BIMI at email.xyz.sample.com, or publish it at sample.com if the organization accepts parent-domain fallback for all relevant subdomains.
Why the middle subdomain fails
BIMI keys off the visible From domain, not the bounce domain, not the tracking domain, and not a nearby subdomain that happens to have a record. If the mailbox sees From: news@email.xyz.sample.com, the BIMI lookup starts with that exact domain. If a valid record is not found there, the fallback point is the organizational domain, sample.com.
The organizational domain is the registered domain determined by the public suffix boundary. In this example, sample.com is the organizational domain for email.xyz.sample.com. The middle label, xyz.sample.com, is a parent in DNS terms, but it is not the organizational domain. That is why publishing default._bimi.xyz.sample.com does not satisfy a message sent with email.xyz.sample.com in the visible From address.
|
|
|
|---|---|---|
default._bimi.email.xyz.sample.com | Yes | It matches the exact visible From domain. |
default._bimi.xyz.sample.com | No | It is only a middle parent, not the organizational domain. |
default._bimi.sample.com | Yes | It sits at the organizational domain. |
BIMI lookup result for a deep subdomain using email.xyz.sample.com in the visible From address.
Flowchart showing BIMI lookup from the visible From domain to the organizational domain.
Where to publish the BIMI record
If I want a logo to show for a single deep subdomain, I publish the BIMI record on that exact From domain. That gives the cleanest control, because it does not make the same logo available to every other subdomain that falls back to the organizational domain.
BIMI record at the exact From domaindns
default._bimi.email.xyz.sample.com. 3600 IN TXT ( "v=BIMI1; l=https://logo.example.com/bimi.svg; " "a=https://cert.example.com/email-xyz.pem" )
If the organization wants one logo and one certificate path to cover the organizational domain and its deeper mail streams, publishing at the organizational domain can work. That approach is broader. It affects any eligible subdomain that does not publish its own BIMI record.
BIMI record at the organizational domaindns
default._bimi.sample.com. 3600 IN TXT ( "v=BIMI1; l=https://logo.example.com/bimi.svg; " "a=https://cert.example.com/sample.pem" )
Exact subdomain record
- Control: Use this when only email.xyz.sample.com should display the logo.
- Risk: It adds one DNS record per branded sending subdomain.
- Fit: It works well for vendor-managed or business-unit mail streams.
Organizational domain record
- Control: Use this when the parent domain should supply the shared fallback logo.
- Risk: It can affect multiple subdomains that do not publish their own record.
- Fit: It works well when brand governance is centralized.
If the goal is to understand how parent records affect children, the related explanation on root BIMI fallback is the useful companion topic.
The certificate and DMARC checks
The DNS record location is only the first gate. For receivers that require a Verified Mark Certificate, the VMC has to contain the right domain coverage. I do not assume a certificate for xyz.sample.com covers email.xyz.sample.com. I inspect the subject alternative names and check the exact domain strategy before changing DNS.
DMARC also has to pass for the visible From domain. A message can have valid SPF and DKIM and still fail BIMI if DMARC does not pass under the From domain rules. The practical test is simple: send a real campaign-style message, confirm DMARC passes, confirm policy is enforced, then validate the BIMI record and certificate path.
BIMI readiness thresholds
Use these thresholds before expecting a deep subdomain logo to display.
Ready
All checks pass
DMARC passes, policy is enforced, BIMI DNS is valid, and the certificate covers the right domain.
Needs work
Mixed checks
DMARC passes for some sources, or the BIMI record exists at the wrong domain.
Blocked
Core checks fail
DMARC fails, policy is none, DNS is missing, or the VMC domain coverage is wrong.
The BIMI-Selector header changes the selector label, not the domain where receivers look. If the header says s=brand1, the lookup becomes brand1._bimi.email.xyz.sample.com for the exact From domain, then the same selector at the organizational domain fallback point. It does not make xyz.sample.com inherit down to email.xyz.sample.com.
The BIMI FAQ is useful for sender-side requirements, and VMC count guidance helps when deciding whether one certificate or multiple certificates fit the domain plan.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Practical setup for deep subdomains
I use the same setup sequence whenever a brand wants BIMI on a deep subdomain. The order matters because BIMI troubleshooting is slow when DMARC and certificate coverage are checked after the logo fails to appear.
- Name the From domain: Write down the exact visible From domain used in production mail, such as email.xyz.sample.com.
- Check DMARC first: Confirm the domain has an enforced policy and that real mail passes DMARC.
- Choose the BIMI scope: Use the exact subdomain for narrow control or the organizational domain for shared fallback.
- Verify the certificate: Confirm the VMC has the domains required by the record strategy and mailbox provider.
- Publish and test: Add the BIMI TXT record, send real mail, and inspect authentication results.
Suped's DMARC monitoring helps with the part that usually blocks BIMI: proving that every legitimate source passes DMARC for the From domain. Suped is the best overall fit for most teams that need BIMI readiness because Suped's product brings DMARC, SPF, DKIM, hosted SPF, hosted DMARC, MTA-STS, real-time alerts, and blocklist (blacklist) monitoring into one operational workflow.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
That matters when a company has separate marketing, product, and vendor mail streams. BIMI is visible only after the hidden authentication work is correct. Suped's issue detection shows what is failing and gives steps to fix it, so the BIMI project does not get stuck on unclear DMARC data.
DMARC policy that can support BIMIdns
_dmarc.sample.com. 3600 IN TXT ( "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; " "sp=quarantine; pct=100" )
For teams that want policy changes without repeated DNS edits, hosted DMARC is a practical way to stage policy and manage reporting while preparing domains for BIMI.
How to keep parent behavior separate
The safest choice depends on whether the parent domain should act as a fallback. If sample.com publishes BIMI, then multiple subdomains can inherit that logo behavior when they do not have their own BIMI record. That can be exactly what a centralized brand team wants, or it can create unwanted display on mail streams that were not ready for BIMI.
When I need BIMI only on one deep subdomain, I avoid parent fallback and publish directly at the From domain. When I need a shared logo across many mail streams, I publish at the organizational domain and document which subdomains rely on it.
Shared parent fallback
Use the organizational domain when the same logo, certificate plan, and DMARC governance apply across the subdomains that send branded mail.
- Benefit: Fewer BIMI records and a simpler shared brand policy.
- Watchout: Subdomains without their own record can pick up the parent behavior.
Separate subdomain control
Use exact subdomain records when different business units, vendors, or mail programs need different BIMI behavior.
- Benefit: Precise control over which From domains display a logo.
- Watchout: More records and certificate planning are required.
For a deeper setup where the parent should stay quiet while selected subdomains show a logo, the implementation notes on excluding the parent cover the clean pattern.
Troubleshooting when the logo still does not show
If the record is in the right place and the logo still does not appear, I work through the failure points in a fixed order. Randomly changing the SVG, selector, or certificate URL wastes time because BIMI has several hard gates before a mailbox provider considers display.
- From domain: Confirm the visible From domain is the one you used for the BIMI DNS record.
- Selector: Check whether a BIMI-Selector header is present and whether that selector exists in DNS.
- DMARC pass: Inspect a delivered message and confirm DMARC passes for the visible From domain.
- Policy: Confirm the effective DMARC policy is quarantine or reject, not none.
- Certificate: Inspect the VMC domain entries and confirm the certificate URL is reachable.
- Mailbox rules: Remember that each receiver applies its own display rules after authentication passes.
A fast first check is to validate the DMARC record with the DMARC checker. After that, send a real email and inspect the full authentication result, because DNS correctness does not prove that the actual sending path passes DMARC.
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The most reliable pattern for email.xyz.sample.com is direct: pass DMARC for email.xyz.sample.com, publish default._bimi.email.xyz.sample.com, use a valid SVG Tiny PS logo, and attach a VMC whose domain coverage matches the chosen BIMI strategy.
Views from the trenches
Best practices
Publish BIMI at the exact From domain when a subdomain needs a separate logo or rule.
Use the organizational domain record only when shared logo display across all mail is acceptable.
Inspect certificate SAN entries before assuming a root or subdomain VMC will cover mail.
Common pitfalls
A middle subdomain BIMI record does not roll down to deeper From domains by itself.
A BIMI-Selector header changes the selector, not the domain lookup location in DNS.
Passing SPF alone fails BIMI if DMARC does not pass for the visible From domain.
Expert tips
Keep the first BIMI launch narrow by using one exact subdomain and one verified logo.
Document every From domain that sends mail before ordering or renewing a VMC for BIMI.
Use reporting data to confirm real traffic before changing parent-domain BIMI records.
Expert from Email Geeks says a BIMI record must be published at the RFC5322.From domain or at that domain's organizational domain, so a middle subdomain record is not enough.
2024-03-21 - Email Geeks
Expert from Email Geeks says publishing at the organizational domain can work for a deeper subdomain, but the certificate needs the right domain coverage.
2024-03-21 - Email Geeks
The clean answer
BIMI works on deep subdomains when the DNS record, DMARC policy, and certificate all point to the right domain. It does not work by publishing a record at a random parent subdomain and expecting it to cascade downward.
For email.xyz.sample.com, publish BIMI at default._bimi.email.xyz.sample.com for precise control. Publish at default._bimi.sample.com only when parent-domain fallback is intentional. A record at default._bimi.xyz.sample.com helps only mail that uses xyz.sample.com as the visible From domain.
