Does BIMI require DMARC at the organizational level, and can it be implemented only at the subdomain level?
Michael Ko
Co-founder & CEO, Suped
Published 4 Aug 2025
Updated 16 Aug 2025
8 min read
BIMI (Brand Indicators for Message Identification) has become a key player in email authentication, allowing organizations to display their brand logo next to their emails in supported inboxes. It is an exciting prospect for brand recognition and trust. However, successfully implementing BIMI hinges entirely on a properly configured DMARC policy.
A common question that arises during implementation is whether DMARC needs to be set up at the organizational (root) domain level or if it can simply exist on a sending subdomain. Understanding this distinction is crucial for a smooth BIMI rollout and avoiding deliverability issues.
For BIMI to work, DMARC must be implemented and enforced. This means your DMARC policy, which dictates how receiving mail servers handle emails that fail authentication checks, needs to be set to either quarantine or reject, not just monitor (p=none). This strict requirement is foundational because BIMI relies on DMARC to verify the authenticity of your emails before displaying your brand logo. Without a robust DMARC policy, BIMI cannot confirm that the email truly originates from your brand, and thus, your logo will not appear.
The DMARC protocol works by checking the alignment of SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) authentication. If emails pass these checks and align with your DMARC policy, they are deemed legitimate. This layer of security is why BIMI mandates DMARC enforcement. It is not just about showing a logo, it is about signaling to mail providers that your domain is actively protected against spoofing and phishing attempts. You can read more about these requirements on the BIMI Group's FAQ page.
While DMARC enforcement is key, it is also important to remember that DMARC reports provide valuable insights into your email ecosystem, helping you identify legitimate sending sources and unauthorized senders. This information is critical for fine-tuning your DMARC policy and ensuring consistent email deliverability. For more details on setting up DMARC for BIMI, consult our guide on how to set up DMARC for BIMI.
BIMI's DMARC requirement
To activate BIMI, your domain's DMARC policy must be set to p=quarantine or p=reject. This signals to receiving mail servers that you are taking an active stance against unauthorized email and are ready for BIMI logo display. Some providers, like Google and other leading mail providers, strictly enforce this, requiring organizational-level DMARC for BIMI functionality.
Organizational domain DMARC policy
The BIMI specification is clear: DMARC must be enabled at the organizational (root) domain level. This means if your brand's main domain is example.com, your DMARC record needs to be published directly on example.com. While DMARC policies include a mechanism (the sp tag) to apply a policy to all subdomains, BIMI specifically checks for the DMARC record at the organizational level to ensure broad protection across your entire domain namespace. This approach ensures that your brand's security posture is consistent and verifiable.
Even if you send emails primarily from subdomains like marketing.example.com or transactions.example.com, the DMARC record on example.com must be present and at an enforced policy. This requirement exists to prevent a scenario where a malicious actor could spoof a subdomain if the root domain lacked DMARC protection. While some mail providers, like Yahoo, have historically shown some flexibility by accepting subdomain-only DMARC for BIMI, the overall trend is towards stricter adherence to the specification. Relying on such exceptions is not a sustainable long-term strategy.
The organizational-level DMARC policy applies to the primary domain and, by default, its subdomains, unless a specific DMARC record is published on a subdomain. This hierarchy is essential for comprehensive email security and brand reputation. For more on DMARC policies across domains, check out our article on DMARC policies for organizational and subdomains.
While DMARC must reside at the organizational level, the BIMI TXT record itself can be published on a subdomain. This offers flexibility, especially for organizations that manage different sending reputations or marketing campaigns on various subdomains. For instance, if your main corporate emails come from example.com but your marketing emails are sent from marketing.example.com, you can choose to apply the BIMI logo only to the marketing subdomain. This allows for targeted brand display without necessarily impacting your primary corporate email domain.
If a DMARC policy is published directly on a subdomain (e.g., _dmarc.sub.example.com), it will always override the policy set for that subdomain by the organizational domain's sp tag. This provides granular control, enabling specific enforcement policies for different subdomains while maintaining the overarching security umbrella of the organizational DMARC. This is particularly useful if you have transactional emails or other email streams that require a different DMARC enforcement level than your main domain. To learn how to implement BIMI for multiple brands with subdomains, refer to our guide on implementing BIMI.
Remember, even if your BIMI record is on a subdomain, the organizational domain's DMARC must still be compliant. This is the bedrock upon which BIMI's trust model is built. It's a balance of centralized security and distributed brand representation. Learn more about controlling subdomain BIMI display in our guide on BIMI trickle-down effects.
DMARC at organizational level
Requirement: Mandatory for BIMI. Must have an enforced policy, like p=quarantine or p=reject.
Scope: Covers the entire domain and its subdomains, ensuring comprehensive protection.
Effect: Provides the foundational trust needed for mail clients to display BIMI logos.
BIMI records on subdomains
Placement: Can be published at the subdomain level to apply logos specifically to those sending domains.
Dependency: Requires an enforced DMARC policy at the organizational domain.
Benefit: Offers flexibility for targeted brand display on specific email streams.
Troubleshooting BIMI and DMARC implementation
Implementing BIMI involves DNS changes, which can sometimes be tricky. One of the most common issues is misplacing the BIMI TXT record or encountering NXDOMAIN (non-existent domain) errors when checking. This typically means the record was not published correctly or is not yet propagated across DNS servers globally. Always double-check the exact hostname and value generated by BIMI tools. DNS changes can take time to propagate, sometimes up to 48 hours, though often it is much faster.
Another hurdle can be internal IT resistance to making DMARC policy changes, especially when it involves moving to an enforcement policy like quarantine or reject. This often stems from concerns about disrupting legitimate email flows if authentication is not perfectly configured. It is important to emphasize that DMARC is a critical email security standard, and its enforcement protects your brand from phishing and spoofing. Transitioning to an enforced policy should be a phased approach, starting with p=none to gather reports, and then gradually escalating the policy as you gain confidence in your email authentication. For more details on safe transitions, consult our guide on safely transitioning your DMARC policy.
To troubleshoot BIMI display issues, always start by verifying your DMARC record at the organizational level and then check your BIMI record's DNS entry. Use reliable DNS lookup tools to confirm propagation. If you're encountering persistent issues, it might be beneficial to review your entire email authentication setup, including SPF and DKIM. Sometimes, issues can cascade from these underlying protocols. Need help? Our BIMI requirements and implementation steps article provides further guidance.
Verify DNS: Ensure your BIMI TXT record is correctly published and propagated, checking for NXDOMAIN errors.
Check DMARC Policy: Confirm that your organizational domain's DMARC policy is at enforcement (p=quarantine or p=reject).
Review Authentication: Ensure SPF and DKIM are properly set up and aligned with your DMARC policy for all sending sources.
Views from the trenches
Best practices
Ensure a DMARC record exists at your organizational domain with an enforced policy.
Always verify DNS record propagation after publishing BIMI or DMARC records.
Consider a phased rollout for DMARC enforcement to monitor impact on legitimate email.
Work closely with your IT team to ensure correct DNS record placement and understanding of requirements.
Common pitfalls
Attempting to implement BIMI without an enforced DMARC policy at the organizational level.
Incorrectly publishing BIMI TXT records leading to NXDOMAIN errors or non-display.
Underestimating the time for DNS record propagation, leading to perceived failures.
Failing to monitor DMARC reports for authentication issues after policy changes.
Expert tips
For full BIMI support from major mail providers, ensure your DMARC policy is set to p=quarantine or p=reject.
While BIMI records can be placed on subdomains, the organizational DMARC remains a prerequisite.
Use dig commands with the TXT flag to verify DNS records, for example, `dig TXT default._bimi.yourdomain.com`.
A specific DMARC policy on a subdomain overrides the `sp` tag from the organizational domain.
Expert view
Expert from Email Geeks says DMARC is required at the organizational level for BIMI.
2021-06-14 - Email Geeks
Expert view
Expert from Email Geeks says BIMI requires an enforced DMARC policy, with p=quarantine as the minimum level.
2021-06-14 - Email Geeks
Achieving BIMI success
In conclusion, the answer is unequivocally yes: BIMI requires DMARC to be present and enforced at the organizational domain level. While you have the flexibility to publish your BIMI TXT records on specific subdomains to manage brand display, the underlying DMARC policy at your root domain is paramount for BIMI to function correctly across all supporting mail clients. This foundational requirement ensures that your brand’s visual identity is only displayed on authenticated and secure emails.
Navigating DMARC and BIMI implementation can seem complex, but understanding these core requirements simplifies the process. Prioritizing the establishment of a robust, enforced DMARC policy for your organizational domain is the most crucial step towards successfully leveraging BIMI for enhanced email visibility and trust. For further reading, explore our comprehensive guide to DMARC, SPF, and DKIM.
Google and other leading mail providers, strictly enforce this, requiring organizational-level DMARC for BIMI functionality.
Yahoo, have historically shown some flexibility by accepting subdomain-only DMARC for BIMI, the overall trend is towards stricter adherence to the specification. Relying on such exceptions is not a sustainable long-term strategy.
