Will BIMI work on multiple levels of subdomains?
Updated on 31 Jul 2026: We updated this guide for RFC 9989, current BIMI subdomain lookup, selector signing, and Mark Certificate options.
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 under the current BIMI lookup rules.
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 the DMARC result and effective policy, the BIMI TXT record, the logo asset, and any Mark Certificate required by the receiver.
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. 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, tracking domain, or a nearby subdomain that happens to have a record. If the mailbox sees From: news@email.xyz.sample.com, the BIMI lookup starts with email.xyz.sample.com. If a valid record is not found there, the fallback point in this example is the organizational domain, sample.com.
The current BIMI draft defines this fallback with DMARC's organizational-domain terminology. For the ordinary sample.com structure used here, sample.com is the organizational domain for email.xyz.sample.com. The middle label, xyz.sample.com, is a DNS parent, but the BIMI lookup does not search it as an intermediate fallback.
RFC 9989 changed DMARC organizational-domain discovery in 2026. DMARC now uses a bounded DNS tree walk instead of relying on a public suffix list. The May 2026 BIMI draft still cites RFC 7489 for its organizational-domain definition, so a delegated DMARC boundary should not be treated as a guaranteed BIMI fallback point without receiver testing.
|
|
|
|---|---|---|
default._bimi.email.xyz.sample.com | Yes | It matches the exact visible From domain. |
default._bimi.xyz.sample.com | No | It is an intermediate DNS parent, not a lookup point in this example. |
default._bimi.sample.com | Yes | It sits at the organizational-domain fallback point. |
BIMI lookup result for email.xyz.sample.com under the current BIMI draft.
BIMI lookup flow from the exact From domain to the organizational-domain fallback.
Where to publish the BIMI record
To show a logo for one deep subdomain, publish the BIMI record on that exact From domain. This gives the cleanest control because it does not make the same logo available to other subdomains through organizational-domain fallback.
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 eligible mail streams beneath it, publishing at the organizational domain can work. This broader choice affects any eligible subdomain that does not publish a record for the selector in use.
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
- Use it when only email.xyz.sample.com should display the logo.
- Plan for one DNS record per branded sending subdomain and selector.
- It fits vendor-managed and business-unit mail streams that need separate control.
Organizational domain record
- Use it when the organizational domain should supply one fallback logo.
- Document every subdomain that relies on the inherited record.
- It fits centralized brand control with one certificate plan.
The certificate and DMARC checks
The DNS record location is only the first gate. A receiver can require a BIMI Mark Certificate, such as a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC). A certificate can cover multiple domains but only one logo. Inspect its subject alternative names and confirm that the domain used by the BIMI strategy is covered.
The message must pass DMARC for the visible From domain. Either SPF or DKIM can provide that pass when its authenticated domain matches the From domain under DMARC rules. The effective policy for the visible From domain and organizational domain must be quarantine or reject, and an applicable sp=none policy blocks BIMI processing for subdomain mail.
BIMI readiness thresholds
Use these thresholds before expecting a deep subdomain logo to display.
Ready
All checks pass
DMARC passes, the effective policies are enforced, BIMI DNS is valid, and any required Mark Certificate covers the chosen domain.
Needs work
Mixed checks
DMARC passes for some sources, or the BIMI record exists at the wrong lookup point.
Blocked
Core checks fail
DMARC fails, an effective policy is none, DNS is missing, or required certificate coverage is wrong.
The BIMI-Selector header changes the selector label, not the domain lookup path. If the header says s=brand1, receivers check brand1._bimi.email.xyz.sample.com and then brand1._bimi.sample.com. They do not fall back to the default selector. The BIMI-Selector header should be covered by the DKIM signature that produces the DMARC pass; otherwise, the receiver should ignore it.
The BIMI FAQ covers sender requirements, certificate types, logo hosting, and receiver-specific display decisions.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Practical setup for deep subdomains
Use the same setup sequence whenever a brand wants BIMI on a deep subdomain. The order matters because troubleshooting becomes slow when DMARC policy, real sending traffic, asset hosting, and certificate coverage are checked only after the logo fails to appear.
- Write down the exact visible From domain used in production mail, such as email.xyz.sample.com.
- Confirm that real mail passes DMARC and that the effective domain policies are quarantine or reject.
- Choose the exact subdomain for narrow control or the organizational domain for shared fallback.
- Confirm that any required Mark Certificate covers the domains used by the record strategy.
- Publish the BIMI TXT record, send production-like mail, and inspect the authentication results.
Suped's DMARC monitoring groups aggregate reports by source and From domain. That workflow helps identify legitimate mail that still fails DMARC before an enforced policy or BIMI record is published for a deep subdomain.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
This matters when marketing programs and vendor mail use separate infrastructure. Suped's issue detection identifies the source and authentication path behind a failure, so the team can correct DMARC before testing BIMI display.
DMARC policy that can support BIMIdns
_dmarc.sample.com. 3600 IN TXT ( "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; " "sp=quarantine" )
RFC 9989 removed the DMARC pct tag. Do not add pct=100 to a new record. Use p=quarantine or p=reject and set an enforced subdomain policy when subdomain mail needs BIMI.
Suped's hosted DMARC lets teams stage policy changes and manage reporting without repeated DNS edits while they prepare domains for BIMI.
How to keep parent behavior separate
The right choice depends on whether the organizational domain should act as a fallback. If sample.com publishes BIMI, eligible subdomains can inherit that logo when they do not have their own record for the selector in use. This can support centralized brand control, but it can also enable display on a mail stream that was not included in the rollout plan.
For BIMI on one deep subdomain, publish directly at the From domain and avoid a parent record unless shared fallback is intentional. For one logo across several mail streams, publish at the organizational domain and document every subdomain that relies on it.
Shared parent fallback
Use the organizational domain when the same logo and certificate plan apply to every eligible subdomain that sends branded mail.
- This reduces the number of BIMI records to maintain.
- Subdomains without their own selector record can use the parent behavior.
Separate subdomain control
Use exact subdomain records when business units or mail programs need different BIMI behavior.
- This gives precise control over which From domains display a logo.
- Each record and selector needs its own change and renewal plan.
For a setup where the parent should stay quiet while selected subdomains show a logo, see the notes on excluding the parent.
How to stop inherited BIMI on one subdomain
A missing subdomain record allows lookup to continue at the organizational domain. To stop that fallback for email.xyz.sample.com, publish an explicit declination record at the exact subdomain. Empty l= and a= values tell a BIMI-aware receiver that this domain declines participation.
Explicit BIMI declination at the deep subdomaindns
default._bimi.email.xyz.sample.com. 3600 IN TXT ( "v=BIMI1; l=; a=;" )
Declination is selector-specific. If mail uses BIMI-Selector: v=BIMI1; s=brand1;, publish the empty record at brand1._bimi.email.xyz.sample.com. A default-selector declination does not stop lookup for brand1.
Use an explicit declination only when the subdomain should not use the inherited logo. Removing the record later restores the organizational-domain fallback for that selector.
Troubleshooting when the logo still does not show
If the record is in the right place and the logo still does not appear, work through the failure points in a fixed order. Changing the SVG, selector, certificate URL, or DMARC policy at random wastes time because BIMI has several gates before a mailbox provider considers display.
- Confirm that the visible From domain matches the domain used for the BIMI DNS record.
- Check whether a BIMI-Selector header is present, signed, and published at the correct lookup points.
- Inspect a delivered message and confirm that DMARC passes for the visible From domain.
- Confirm that the effective DMARC policies are quarantine or reject and that sp=none does not apply.
- Inspect the Mark Certificate domain entries and public certificate chain, including its current status.
- Fetch the logo and certificate URLs over HTTPS, then check the status, content type, redirect target, and TLS identity.
- Account for receiver-specific reputation and display rules after the technical checks pass.
Start by validating the DMARC record with the DMARC checker. Then send a real email and inspect the full authentication result, because valid DNS does not prove that the sending path passes DMARC.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The direct pattern for email.xyz.sample.com is to pass DMARC for that From domain, publish default._bimi.email.xyz.sample.com, use a valid SVG Tiny PS logo over HTTPS, and attach a Mark Certificate accepted by the target receiver when required.
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 mail is acceptable.
Inspect Mark Certificate SAN entries before assuming one domain entry covers nested 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 with one exact subdomain and one approved logo.
Document every From domain that sends mail before requesting a BIMI Mark Certificate.
Use DMARC report data to confirm real traffic before changing parent BIMI records.
An Email Geeks participant 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
An Email Geeks participant 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
