Does a root domain BIMI record apply to subdomains without their own record?
Yes. If a subdomain sends mail and it has no BIMI record of its own, the root domain's BIMI record can apply, as long as the DMARC policy that applies to that subdomain is enforcing. In practical terms, mail sent with a visible From domain like news.example.com can use the BIMI record at default._bimi.example.com when there is no usable record at default._bimi.news.example.com.
The caveat matters more than the yes. BIMI display depends on both BIMI discovery and the domain's DMARC posture. A root BIMI record does not make a subdomain eligible if the subdomain has its own non-enforcing DMARC record, or if the root DMARC record uses sp=none for subdomains.
- Short answer: Root BIMI can cover subdomains that do not publish their own BIMI record.
- Main condition: The subdomain must be under an enforcing DMARC policy, normally quarantine or reject.
- Override rule: A subdomain's own BIMI record takes priority for that subdomain.
The short answer
I treat this as a two-part lookup. First, the receiver decides which domain is being evaluated, usually the domain in the visible From address. Then it checks whether that domain has a BIMI record for the relevant selector. If it does not, the root domain record can be used as the fallback BIMI assertion.
That means a single root BIMI record can be enough for ordinary subdomains, provided the subdomains have no BIMI records of their own and the DMARC policy path still qualifies for BIMI. This is the same practical answer behind parent domain BIMI checks.
Flowchart showing subdomain BIMI lookup, root BIMI fallback, and DMARC policy.
The common trap
A root BIMI record is not a shortcut around DMARC. If the subdomain has its own DMARC record with p=none, receivers have no enforcement signal for that subdomain, so BIMI display fails even when the root has a valid SVG and certificate.
How BIMI inheritance works
BIMI records are TXT records under a selector. Most senders use the default selector, so the root record is normally published at default._bimi.example.com. A subdomain-specific BIMI record uses the same pattern below the subdomain, such as default._bimi.news.example.com.
If the subdomain-specific record exists and is valid, it controls the logo for that subdomain. If it exists and is broken, I fix or remove it instead of assuming fallback. A bad local BIMI record is different from no local BIMI record.
|
|
|
|---|---|---|
Absent | Valid | Root logo can apply |
Valid | Valid | Subdomain logo wins |
Broken | Valid | Fix the subdomain first |
Absent | Absent | No BIMI assertion found |
BIMI lookup outcomes for a subdomain using the default selector.
Selectors matter too. If you send a BIMI-Selector header that names a custom selector, the receiver looks for that selector, not the default one. The fallback only works for the selector being evaluated.
Where the certificate fits
The logo file and mark certificate still need to satisfy the mailbox provider's BIMI rules. Certificate coverage, SVG Tiny PS formatting, HTTPS hosting, and provider-specific display rules all sit after the DNS lookup.
Records that prove the behavior
This root BIMI record is enough for a subdomain with no BIMI record of its own, assuming the subdomain also qualifies through DMARC. I keep the BIMI record simple, because most display failures are caused by invalid logo hosting, certificate mismatch, or DMARC policy mistakes rather than the TXT syntax itself.
Root domain BIMI recorddns
Host: default._bimi.example.com Type: TXT Value: v=BIMI1; l=https://assets.example.com/logo.svg; a=https://assets.example.com/vmc.pem
If the marketing team wants a different logo for news.example.com, publish a BIMI record at the subdomain. That record then controls that subdomain's logo decision.
Subdomain-specific BIMI recorddns
Host: default._bimi.news.example.com Type: TXT Value: v=BIMI1; l=https://assets.example.com/news.svg; a=https://assets.example.com/news-vmc.pem
Use root BIMI
- Best fit: All subdomains should show the same brand logo.
- DNS load: One BIMI record has less operational work.
- Risk: One mistake affects every relying subdomain.
Use subdomain BIMI
- Best fit: A subdomain needs a different logo or certificate.
- DNS load: Each subdomain has its own record to maintain.
- Risk: A broken local record blocks fallback behavior.
The DMARC condition
BIMI requires an enforcing DMARC policy. For a subdomain, the question is not only whether the root has BIMI. The question is which DMARC policy applies to the exact From domain and whether that policy is enforcing.
A root DMARC record can include sp=, the subdomain policy tag. If sp=quarantine or sp=reject applies, the subdomain has an enforcing DMARC policy. If sp=none applies, that subdomain does not have the enforcement BIMI expects.
Root DMARC policy that supports subdomain BIMIdns
Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:dmarc@example.com
A subdomain can also publish its own DMARC record. That record takes priority for that subdomain. This is why subdomain DMARC overrides matter so much for BIMI.
Subdomain DMARC record that blocks BIMI displaydns
Host: _dmarc.news.example.com Type: TXT Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com
DMARC policy strength for BIMI
Use this as a quick read on whether the applying DMARC policy supports BIMI.
None
p=none
Monitoring only, not enough for BIMI display.
Quarantine
p=quarantine
Enforcing policy accepted by BIMI programs.
Reject
p=reject
Strong enforcement accepted by BIMI programs.
I also pay attention to deep subdomains. Under the older DMARC discovery model, a very deep domain can jump back to the organizational domain rather than every intermediate label. Newer DMARC tree walk behavior changes that assumption. For four-label and deeper sender domains, test the actual domain path rather than relying on memory.
How I check it safely
My check starts with the exact visible From domain, not the domain people use in meetings. A sending platform can use mail.example.com, news.example.com, or example.com as the user-facing domain. BIMI follows the domain that appears to the recipient.
- Confirm the From domain: Send a real message and inspect the visible From address and authentication results.
- Check subdomain BIMI: Look for the selector under the exact subdomain first.
- Check root BIMI: Verify the root BIMI TXT record, logo URL, and certificate URL.
- Check DMARC enforcement: Confirm the applying policy is quarantine or reject.
- Check provider display: Remember that mailbox providers still decide whether to render the logo.
For a focused DNS check, the DMARC checker confirms whether the policy syntax is valid. For a broader view of DMARC, SPF, and DKIM together, run a domain health check before changing BIMI.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Suped's product helps with the operational part of this check. Its DMARC monitoring view shows which sources are passing authentication, where subdomain policy gaps exist, and which issues need action. That matters because BIMI display usually fails for a reason outside the BIMI TXT record itself.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
For teams with many domains, Suped's Hosted DMARC can stage policy changes and keep subdomain enforcement easier to manage. Hosted DMARC is especially useful when different business units own DNS and marketing wants BIMI rolled out without repeated DNS tickets. Suped also brings hosted SPF, SPF flattening, hosted MTA-STS, real-time alerts, and blocklist (blacklist) monitoring into the same platform.
Subdomain patterns to watch
The easiest setup is one root BIMI record, one enforcing root DMARC policy, and no subdomain overrides. The hardest setup is several subdomains, each with different DMARC records, different sending vendors, and inconsistent selector use.
If you use several subdomain layers, such as promo.eu.example.com, test each level directly. The practical answer still starts with the same idea, no local BIMI record means root BIMI can apply, but the DMARC policy discovery path needs verification. This is where BIMI subdomain levels become important.
Best operating model
- Default path: Publish one valid root BIMI record and keep subdomains clean unless they need different logos.
- Policy path: Use an enforcing root DMARC policy and avoid accidental sp=none.
- Exception path: Publish subdomain BIMI only when a different logo or certificate is required.
Views from the trenches
Best practices
Check the exact From domain first, then test BIMI and DMARC at that same subdomain.
Keep root BIMI as the default path unless a subdomain needs a separate logo.
Use an enforcing sp tag when subdomains inherit policy for BIMI eligibility.
Common pitfalls
Assuming a root logo works while a subdomain DMARC record still uses p=none.
Leaving a broken subdomain BIMI record in DNS and expecting root fallback to fix it.
Testing only the root domain when the sender actually uses a deeper subdomain.
Expert tips
Document which subdomains intentionally override BIMI so future DNS changes stay clear.
Treat DMARC policy and BIMI lookup as separate checks before blaming mailbox display.
Retest deep subdomains as DMARC tree walk behavior becomes more widely adopted.
Marketer from Email Geeks says a root BIMI record applies when the subdomain has no BIMI record of its own.
2025-09-24 - Email Geeks
Marketer from Email Geeks says the answer changes if a subdomain DMARC record removes enforcement.
2025-09-24 - Email Geeks
The practical takeaway
A root domain BIMI record does apply to subdomains that do not have their own BIMI record, but only when the DMARC policy that applies to those subdomains is enforcing. The most common working setup is a valid root BIMI TXT record plus a root DMARC record using p=quarantine or p=reject, with sp= also enforcing for subdomains.
I keep the rule simple: no subdomain BIMI record means the root BIMI record can be used, but any subdomain BIMI or DMARC record must be checked as a local override. That single distinction prevents most false assumptions during BIMI rollout.
