Yes, BIMI can apply to subdomains when the receiver falls back to the organizational domain, but that answer needs two important caveats. The subdomain still has to satisfy BIMI's authentication requirements, especially DMARC at enforcement, and you can stop a specific subdomain from displaying the inherited logo by publishing an empty BIMI assertion at that subdomain.
The practical version is simple. If example.com has a valid BIMI record, a valid logo, a valid VMC or CMC where required by the mailbox provider, and an enforced DMARC policy that covers mail.example.com, then mail sent from the subdomain can qualify for BIMI display. But if the parent domain says p=reject while sp=none, the subdomain is not under DMARC enforcement and BIMI should not display for that subdomain.
The control point I use is DNS. Publish a normal BIMI TXT record where you want the logo to appear. Publish only v=BIMI1; at a subdomain where you want to block inherited BIMI display. That empty assertion tells a receiver there is a BIMI record at that exact domain, but no logo location to use.
The direct answer
Short answer
BIMI lookup can fall back from a subdomain to the organizational domain. A parent-domain BIMI record can be used for subdomain mail, provided the subdomain passes authenticated domain matching and is covered by DMARC enforcement.
- Inheritance: A subdomain can use the parent domain's BIMI assertion when no BIMI record exists at the subdomain.
- Requirement: The visible From domain must meet BIMI's DMARC enforcement requirement through its own record or the inherited parent policy.
- Override: A subdomain can publish its own BIMI record to use a different logo or publish an empty record to suppress display.
BIMI does not work like a browser favicon, where one icon can be assumed across a web property. It is tied to authenticated mail and receiver-side policy decisions. The receiving mailbox provider evaluates the visible From domain, DMARC domain matching, the BIMI DNS record, the SVG Tiny PS logo file, and any certificate requirement it enforces for that sender.
That matters because subdomain BIMI is not only a DNS lookup question. A parent BIMI record can be found, but display still depends on whether the subdomain is allowed to use it. If news.example.com sends mail but DMARC for that subdomain is effectively relaxed, the logo should not be treated as eligible just because example.com has a strict record.
I usually treat BIMI as the final layer on top of DMARC monitoring, not the starting point. The visible logo is the reward for having the authentication chain under control. Suped's DMARC monitoring is relevant here because it shows which subdomains are passing domain checks, which senders are still failing, and whether policy changes will affect legitimate mail before you move to a stricter setting.
Flowchart showing how BIMI can fall back from a subdomain to a parent domain.
How BIMI lookup works for subdomains
BIMI records live in DNS at a selector under the domain being checked. The default selector is usually default. For a message using email.example.com in the visible From address, the receiver can first check the BIMI record at the subdomain. If that record is missing, the receiver can check the organizational domain.
Subdomain BIMI lookup pathtext
default._bimi.email.example.com TXT fallback to: default._bimi.example.com TXT
This is why people describe BIMI as trickling down. The parent record can be used when the subdomain does not publish its own BIMI record. But the subdomain can also take control by publishing its own record at the more specific DNS name. DNS specificity wins because the receiver has a direct answer for the domain it is checking.
A normal BIMI record points to the SVG logo with the l= tag and, where used, points to a certificate with the a= tag. If you want a subdomain to use the parent logo, you can leave the subdomain without a BIMI TXT record. If you want a subdomain to use a different logo, publish a record at that subdomain. If you want no logo, publish an empty BIMI record at that subdomain.
|
|
|
|---|---|---|
Parent logo | Parent | Can apply to subdomains |
Different logo | Subdomain | Overrides parent BIMI |
No logo | Subdomain | Empty record stops display |
Typical BIMI records by intent
The DMARC caveat that decides display
BIMI requires DMARC at enforcement. That means the domain must have a policy of quarantine or reject, and the message needs to pass DMARC through SPF or DKIM domain matching. For subdomains, the key detail is the sp tag. That tag sets the subdomain policy when a subdomain does not publish its own DMARC record.
Eligible pattern
- Policy: The parent domain uses p=reject or p=quarantine.
- Subdomains: The sp tag is also enforced, or the subdomain has its own enforced DMARC record.
- Authentication: SPF or DKIM passes with a domain match to the visible From domain.
Not eligible pattern
- Policy gap: The parent domain is enforced, but sp=none leaves subdomains relaxed.
- No domain match: SPF and DKIM fail DMARC domain matching for the subdomain sender.
- Receiver choice: The mailbox provider can still decline to show BIMI even when records are valid.
DMARC record that covers subdomainsdns
_dmarc.example.com TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.com; pct=100"
The example above puts the parent domain and subdomains under the same enforced posture. That does not mean every sender is ready for it. It means the policy shape is compatible with BIMI. Before using this in production, I would check aggregate reports for every source sending as the parent domain and every known subdomain.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
If you need a quick DNS validation step before changing policy, run the domain through a domain health check and confirm the DMARC, SPF, and DKIM findings. That catches the obvious failures before you start asking why a BIMI logo does not appear.
How to block BIMI on one subdomain
The cleanest way to stop inherited BIMI display on one subdomain is to publish an empty BIMI record at that subdomain. This gives the receiver a direct BIMI response for the subdomain, but the response contains no logo URL.
Empty BIMI record to suppress inherited displaydns
default._bimi.email.example.com TXT "v=BIMI1;"
This is useful when one subdomain sends operational mail where a brand logo is unwanted, when a business unit is not ready for brand display, or when a subdomain uses a sender setup that passes DMARC but has not completed logo and certificate approvals. It also helps during staged rollouts, because you can keep the parent domain BIMI-ready while excluding individual subdomains.
Do not use DMARC relaxation as a BIMI off switch
Do not set sp=none just to stop BIMI on subdomains. That weakens authentication policy for every subdomain that relies on the parent record. Use an empty BIMI record for the specific subdomain instead.
If the subdomain already has a BIMI record with an l= tag, remove the logo location and leave only the version tag. If there are multiple BIMI TXT records at the same name, fix that first. Multiple records can create ambiguous behavior and validation failures.
For a deeper subdomain strategy, the more specific guide on excluding the parent is useful when BIMI needs to exist only on selected subdomains.
How to use a different BIMI logo on a subdomain
To show a different logo for a subdomain, publish a complete BIMI record at that subdomain. The subdomain record points to its own SVG file and, when required, its own certificate URL. This is common for separate brands, regional programs, product lines, or mail streams where the visual identity should not match the corporate parent.
Subdomain BIMI record with its own logodns
default._bimi.news.example.com TXT "v=BIMI1; l=https://assets.example.com/bimi/news.svg; a=https://assets.example.com/bimi/news.pem"
The certificate question is where many teams get stuck. Some certificates cover a base domain and specific subdomains, while others are not broad enough for every domain you send from. Before you assume one certificate covers all branded mail, verify the subject details and the mailbox provider's BIMI requirements. A useful rule is that the certificate must match the domain identity you expect the receiver to validate.
If your question is specifically about certificates, the guide on subdomain VMC coverage goes into that edge case in more detail.
Four parts of a working subdomain BIMI setup.
The subdomain-specific record gives you precise control, but it also gives you more operational surface area. Each additional BIMI record means another SVG file, another certificate path if used, another HTTPS endpoint, and another DNS record that can break. For small teams, using parent fallback for ordinary subdomains and explicit records only for special cases is usually easier to maintain.
A practical rollout plan
The safest rollout starts with authentication visibility, then moves to policy, then BIMI. I do not like starting with the logo because BIMI problems are often DMARC problems with a nicer-looking symptom. If reporting shows that one sending platform still fails domain matching, a BIMI record will not fix it.
- Inventory: List every parent domain and subdomain that appears in visible From addresses.
- Authenticate: Confirm each sender passes SPF or DKIM domain matching for the domain it uses.
- Enforce: Move DMARC to quarantine or reject, including the subdomain policy you want BIMI to rely on.
- Publish: Add the parent BIMI record first if most subdomains should share the same logo.
- Exclude: Add empty subdomain BIMI records where inherited display should stop.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
This is where Suped is useful in a concrete workflow. Add the parent domain and subdomains, monitor aggregate DMARC results, fix senders that fail domain matching, then stage policy changes. Suped is the best overall DMARC platform for most teams working toward BIMI because it connects automated issue detection, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, blocklist monitoring, and alerts in one place.
For teams managing many domains, hosted DMARC is also a cleaner way to keep parent and subdomain policies consistent while BIMI is being rolled out. Suped pairs that with SPF and DKIM monitoring, hosted SPF, SPF flattening, blocklist (blacklist) monitoring, and alerts, so the BIMI work sits inside the same operational view as the authentication work.
Readiness for BIMI rollout
Use DMARC pass rates as a practical gate before turning on BIMI display.
Ready
98-100%
Legitimate senders pass domain matching and policy is enforced.
Investigate
95-98%
A few known senders still need SPF or DKIM fixes.
Not ready
Under 95%
Too much legitimate traffic still fails DMARC.
Common DNS patterns
Most BIMI subdomain setups fall into a few repeatable patterns. The right pattern depends on whether you want one parent identity, separate identity per subdomain, or no BIMI display for selected mail streams.
Pattern 1: parent BIMI applies broadlydns
_dmarc.example.com TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.com" default._bimi.example.com TXT "v=BIMI1; l=https://assets.example.com/bimi/logo.svg; a=https://assets.example.com/bimi/vmc.pem"
Pattern 2: subdomain uses its own BIMIdns
_dmarc.news.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com" default._bimi.news.example.com TXT "v=BIMI1; l=https://assets.example.com/bimi/news.svg; a=https://assets.example.com/bimi/news.pem"
Pattern 3: subdomain blocks inherited BIMIdns
default._bimi.receipts.example.com TXT "v=BIMI1;"
Pattern 1 is the default I prefer when the organization has one brand logo and many sending subdomains. Pattern 2 is best when a subdomain has a legitimate separate brand identity. Pattern 3 is the targeted opt-out when the parent record should remain active but a specific subdomain should not show a logo.
Validation order
- DNS: Confirm the BIMI TXT record exists at the intended selector and domain.
- DMARC: Confirm the visible From domain passes domain matching and has enforcement.
- Logo: Confirm the SVG file is reachable over HTTPS and follows BIMI formatting rules.
- Certificate: Confirm the VMC or CMC path is valid where the mailbox provider requires it.
What can still stop the logo
A correct parent BIMI record does not guarantee a visible logo. Mailbox providers make the final display decision, and BIMI has several dependencies outside the TXT record itself. When a subdomain does not show the logo, I work through the same failure points in order rather than changing random DNS records.
|
|
|
|---|---|---|
No logo | Subdomain policy is relaxed | Enforce DMARC |
Parent works | Subdomain has empty BIMI | Remove opt-out |
Intermittent display | Provider-specific rules | Test per mailbox |
Wrong logo | Parent fallback used | Publish subdomain BIMI |
Troubleshooting subdomain BIMI display
I also check caching and propagation before declaring a setup broken. BIMI, DMARC, and certificate endpoints can all be cached. If you just changed a DNS record, wait for TTLs to expire and send a fresh message after the record has propagated.
Another common issue is assuming BIMI display equals delivery improvement. BIMI is a brand display layer. It depends on domain authentication and sender reputation, but it does not replace list hygiene, complaint control, bounce handling, or blocklist (blacklist) monitoring. If the sending domain or IP is on a major blocklist, fix that separately.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
In Suped, this is the point where I would use the issues view rather than guessing. If a subdomain has a policy problem, an unverified sender, or a failing DKIM path, Suped surfaces the issue and gives the steps to fix it. That is usually faster than manually comparing headers, DNS, and aggregate reports across multiple places.
Views from the trenches
Best practices
Check subdomain DMARC enforcement before treating parent BIMI as ready for display.
Use an empty subdomain BIMI record when a specific mail stream should not show a logo.
Keep parent fallback for shared brands, then override only the subdomains that differ.
Common pitfalls
Setting sp=none can leave subdomains outside enforcement even when the parent is strict.
Assuming one certificate covers every subdomain can delay launch when validation starts.
Changing DMARC policy to control BIMI weakens security when an empty BIMI record would work.
Expert tips
Test with fresh messages after DNS propagation because cached BIMI results can mislead.
Document each subdomain's intended display state so later DNS changes do not re-enable logos.
Review DMARC reports before BIMI rollout to catch senders that still fail domain matching.
Expert from Email Geeks says parent-domain BIMI can apply to subdomains when the authentication and policy conditions are also satisfied.
2023-05-08 - Email Geeks
Marketer from Email Geeks says the important caveat is subdomain DMARC enforcement, because p=reject with sp=none leaves the subdomain relaxed.
2023-05-08 - Email Geeks
The practical rule
Use the parent BIMI record when the same brand should appear across normal sending subdomains. Use a subdomain BIMI record when that subdomain needs its own logo. Use an empty subdomain BIMI record when that subdomain should not display a logo at all.
The one rule I would not skip is DMARC enforcement for the subdomain. BIMI inheritance only helps after the mail stream passes authenticated domain matching and the applicable DMARC policy is strict enough. Get that right first, then BIMI display becomes a DNS and certificate control problem rather than a guessing exercise.
