Suped

Does a parent domain need BIMI for subdomain BIMI to work?

Matthew Whittaker profile picture
Matthew Whittaker
Co-founder & CTO, Suped
Published 31 May 2025
Updated 16 Aug 2025
7 min read
When delving into Brand Indicators for Message Identification (BIMI), a common question that arises, especially for organizations with complex domain structures, is whether the parent domain needs its own BIMI record for a subdomain's BIMI to function correctly. This is a crucial point for email deliverability, as getting BIMI right can significantly enhance brand visibility and trust in the inbox. It's understandable to wonder how these authentication protocols interact across different levels of your domain.
The short answer is no, a parent domain (or organizational domain) does not strictly require its own BIMI record for a subdomain to display its brand logo. However, there's a critical prerequisite that must be met at the organizational domain level: a properly configured DMARC policy. Without a robust DMARC implementation, BIMI simply won't work, regardless of where your BIMI record is published.
This distinction is often a source of confusion because DMARC, unlike BIMI itself, has an inherent inheritance mechanism that affects subdomains. While you can publish BIMI records directly on a subdomain, the foundational DMARC policy must be in place and enforced on the organizational domain. This ensures that the email ecosystem trusts your domain before attempting to display your brand's logo.
Let's explore the nuances of how BIMI, DMARC, and domain hierarchy interact to ensure your brand's logo appears as expected in recipients' inboxes.

Understanding BIMI and domain hierarchy

BIMI, or Brand Indicators for Message Identification, allows email senders to display their brand's logo next to their authenticated emails in supporting inboxes. This visual cue helps recipients instantly recognize legitimate senders, boosting trust and engagement. To function, BIMI relies on a strong foundation of email authentication protocols, specifically SPF, DKIM, and DMARC. Of these, DMARC is the most critical for BIMI to work.
DMARC, or Domain-based Message Authentication, Reporting, and Conformance, is an email authentication protocol that builds on SPF and DKIM. It gives domain owners the ability to tell receiving email servers what to do with messages that fail SPF or DKIM authentication. For BIMI to be enabled, your DMARC policy must be set to an enforcement level, either p=quarantine or p=reject. This strict policy signals to mailbox providers that your domain is secure and actively prevents unauthorized use (like spoofing).
The key concept here is that DMARC policies are published at the organizational (root) domain level and inherently apply to all subdomains unless a specific DMARC record is published at the subdomain level. This inheritance is what makes the organizational domain's DMARC policy so crucial for BIMI, even for messages sent from subdomains. An email sent from a subdomain, say marketing.yourdomain.com, will look for a DMARC policy at that subdomain first. If none is found, it will then look for and apply the DMARC policy of the organizational domain, yourdomain.com.
This tiered lookup process is fundamental to how BIMI assertion records work. Receivers first check the specific sending domain for a BIMI record. If no record is found there, they then check the organizational domain for a BIMI record. This means a subdomain can have its own explicit BIMI record, or it can inherit BIMI if one is set on the parent domain, provided all other conditions are met.

BIMI and DMARC requirements for subdomains

While a parent domain doesn't need its own BIMI record for subdomain BIMI, the DMARC policy of the organizational domain is a non-negotiable requirement. If your organizational domain's DMARC policy is not at p=quarantine or p=reject, BIMI will not display for any subdomains, even if they have their own, perfectly configured BIMI records. This is because the DMARC enforcement signals the trustworthiness needed for BIMI to activate.
The DMARC policy at the organizational level establishes the overarching security posture for your entire domain. Mailbox providers, such as gmail.com logoGmail and yahoo.com logoYahoo, adhere to these policies to protect their users from phishing and spam. BIMI is a visual trust signal built upon this security. If the underlying DMARC security isn't strong, the visual trust signal won't be displayed.

The DMARC enforcement requirement

For BIMI to work, the organizational domain's DMARC policy must be at an enforcement level (p=quarantine or p=reject). This applies even if you are only attempting to implement BIMI on a subdomain. The organizational domain provides the necessary trust anchor for your entire email sending infrastructure.
It's important to differentiate between DMARC inheritance and BIMI inheritance. DMARC policies cascade down to subdomains by default, meaning if you have a p=quarantine policy on yourdomain.com, it applies to marketing.yourdomain.com unless marketing.yourdomain.com has its own explicit DMARC record. BIMI records, however, are specifically looked for at the sending domain or the organizational domain if not found at the sending domain. They do not automatically trickle down from a subdomain to a sub-subdomain, unlike DMARC's default behavior.

Implementing BIMI on subdomains independently

Implementing BIMI on a subdomain without an explicit BIMI record on the parent domain is entirely possible, provided the organizational DMARC policy is met. This offers flexibility, allowing different subdomains to potentially display unique logos or for a marketing department to implement BIMI without needing access to the root domain's DNS for the BIMI record itself. You simply publish the BIMI TXT record directly at your chosen subdomain.
For example, if you send emails from newsletters.yourdomain.com, you would publish the BIMI TXT record at default._bimi.newsletters.yourdomain.com. This is how you can apply BIMI to a specific subdomain rather than the entire domain, allowing for granular control over brand presentation.
Example BIMI TXT record for a subdomainDNS
default._bimi.sub.yourdomain.com. IN TXT "v=BIMI1;l=https://cdn.yourdomain.com/yourlogo.svg;a=https://vmc.example.com/certificate.pem"
Remember, DNS changes can take time to propagate, so allow up to 48 hours for your BIMI record to fully update and for mailbox providers to pick it up. Using a BIMI lookup tool from an authoritative source like the BIMI Group can help verify that your record is correctly published and visible in the DNS.

Views from the trenches

Best practices
Ensure the organizational (root) domain has a DMARC policy of p=quarantine or p=reject.
Publish your BIMI TXT record directly on the subdomain you intend to use for sending.
Use a BIMI lookup tool to confirm your record is properly published and visible.
Allow sufficient DNS propagation time, typically up to 48 hours, for changes to take effect.
Common pitfalls
Forgetting that the parent domain's DMARC policy is a prerequisite for any subdomain BIMI.
Assuming BIMI will automatically inherit from a parent domain if a subdomain also has its own explicit record.
Not allowing enough time for DNS changes to propagate, leading to premature troubleshooting.
Using BIMI selectors other than 'default' as many providers do not yet support them.
Expert tips
BIMI selectors (like 's.') can be used for different logos, similar to DKIM selectors, but are not widely supported.
A subdomain's BIMI record will not cascade down to sub-subdomains, unlike DMARC policies.
Always verify your BIMI DNS entry if the logo isn't displaying as expected, as incorrect hostname or record values are common issues.
Focus on achieving DMARC enforcement first, as it is the absolute foundation for BIMI on any domain or subdomain.
Marketer view
A marketer from Email Geeks says that they finally got their BIMI string for their subdomain, but it's not replicating on the BIMI lookup tool because their parent domain, which is not under their control, doesn't have BIMI.
2022-07-21 - Email Geeks
Expert view
An expert from Email Geeks says if BIMI is done on the organizational domain, it will be inherited by any qualifying subdomain, and VMCs can be set similarly.
2022-07-21 - Email Geeks

Key takeaways for subdomain BIMI

The answer to whether a parent domain needs BIMI for subdomain BIMI to work is nuanced. While the parent domain does not require its own BIMI record to allow a subdomain to display a logo, it absolutely needs a DMARC policy at an enforcement level (p=quarantine or p=reject). This foundational DMARC setup provides the trust required for BIMI to function across your domain structure.
By understanding the distinct roles of DMARC inheritance and BIMI record placement, you can effectively manage your brand's presence in the inbox, ensuring your logo appears for emails sent from your primary domain or any specific subdomains. Always verify your DNS records and allow for proper propagation to avoid display issues.

Frequently asked questions

DMARC monitoring

Start monitoring your DMARC reports today

Suped DMARC platform dashboard

What you'll get with Suped

Real-time DMARC report monitoring and analysis
Automated alerts for authentication failures
Clear recommendations to improve email deliverability
Protection against phishing and domain spoofing