Summary
An organizational DMARC policy generally applies to all subdomains by default, unless a specific DMARC record is published for a subdomain. For BIMI (Brand Indicators for Message Identification) to display, your organizational DMARC policy (or a specific subdomain policy) must be set to an enforcement level, specifically "quarantine" or "reject".
Key findings
- Default DMARC inheritance: A DMARC policy published on the organizational domain (e.g., example.com) automatically extends to its subdomains (e.g., mail.example.com, marketing.example.com) unless explicitly overridden.
- BIMI requirements: For BIMI to display the brand logo, the DMARC policy for the sending domain (whether organizational or subdomain) must be at an enforcement level, meaning p=quarantine or p=reject.
- BIMI inheritance: Similar to DMARC, if a subdomain lacks its own BIMI record, the organizational domain's BIMI record is checked and applied if a compliant DMARC policy exists. The BIMI Group FAQs confirms this inheritance.
- Subdomain overrides: An explicit DMARC record on a subdomain (e.g., _dmarc.sub.example.com) will override the organizational domain's policy for that specific subdomain.
Key considerations
- Policy enforcement: Ensure your DMARC policy is set to p=quarantine or p=reject on the sending domain to enable BIMI. A p=none policy will not trigger BIMI display.
- Consistent branding: Leverage DMARC inheritance to maintain consistent brand representation across all subdomains that don't require unique BIMI logos.
- Subdomain specificity: If you need a different DMARC policy or a unique BIMI logo for a specific subdomain, publish a dedicated record for it. This will override the organizational policy.
- Monitoring and reporting: Regularly monitor your DMARC reports (RUA and RUF) to ensure that your emails are authenticating correctly across all subdomains and that your BIMI display is functioning as intended.
What email marketers say
Email marketers often approach DMARC and BIMI implementation with practical concerns about how policies cascade across their domain infrastructure. Many rely on the default inheritance of DMARC but seek clarification on how this translates to BIMI logo display, especially for traffic originating from subdomains.
Key opinions
- DMARC inheritance is a common assumption: Many marketers operate under the impression that an organizational DMARC record automatically covers all subdomains unless a specific subdomain record exists.
- BIMI's subdomain behavior uncertainty: There's often uncertainty about whether BIMI will follow the same inheritance pattern as DMARC, particularly regarding logo display for subdomain traffic.
- ISP discretion: Some marketers believe that ISPs retain significant control over BIMI display, potentially interpreting data independently of strict DMARC specifications.
- Push for subdomain policies: Clients often need to be persuaded to implement specific DMARC policies at the subdomain level to ensure BIMI functionality or meet broader deliverability goals.
Key considerations
- Clarify DMARC scope: Always verify how DMARC policies apply to subdomains, especially when integrating new protocols like BIMI. The understanding of DMARC authentication is key.
- Enforcement is critical for BIMI: Remember that a DMARC policy of p=quarantine or p=reject is a prerequisite for BIMI to work effectively across any domain or subdomain. Learn more about DMARC and BIMI policy requirements.
- Subdomain policy strategy: Decide if you need to set up explicit DMARC records for subdomains based on your sending practices and branding needs. This is especially relevant if you want specific subdomain policies.
Marketer view
Email marketer from Email Geeks asked if an organizational DMARC policy, without specific subdomain policies, would allow the BIMI logo to show on traffic originating from subdomains. They presumed it would, given DMARC's general application to subdomains, but sought confirmation.
Marketer view
Email marketer from Zoho Zeptomail emphasized that for BIMI adoption, both the organizational domain and any subdomains must be covered by a DMARC policy set to "reject" or 100% "quarantine".
What the experts say
Experts in email deliverability emphasize that while DMARC's inheritance model for subdomains is a core feature, BIMI's reliance on this model for logo display has specific conditions. They often highlight the enforcement policy requirement and the nuances of how receiving ISPs handle BIMI, considering its relationship (or lack thereof) to DMARC's original technical purpose.
Key opinions
- DMARC and BIMI alignment: BIMI's technical specification parallels DMARC's inheritance, meaning if a subdomain lacks a BIMI record, the organizational domain's record is checked.
- Separate purposes: BIMI's association with DMARC is often seen as a strategic move to encourage DMARC adoption, rather than a purely technical dependency rooted in email authentication.
- ISP interpretation: Receiving ISPs have discretion in how they interpret and display BIMI data, meaning strict adherence to specifications might not always guarantee display if their internal policies differ.
- Multiple BIMI images: The BIMI spec includes optional selectors, allowing for multiple logos per domain or subdomain to be defined.
Key considerations
- Enforcement policy necessity: A DMARC enforcement policy (p=quarantine or p=reject) is a non-negotiable requirement for BIMI to function, regardless of domain or subdomain. Learn about safely transitioning your DMARC policy.
- Strategic DMARC deployment: While DMARC's primary role is authentication, its link to BIMI provides an additional incentive for organizations to deploy or strengthen their DMARC policies. A simple guide to DMARC can help.
- Monitor ISP behavior: Even with correct configuration, ongoing monitoring is essential as ISP interpretations of BIMI can vary. This ensures your logo displays consistently.
Expert view
Expert from Email Geeks commented that BIMI has no inherent technical reason to be associated with DMARC, suggesting their connection primarily serves as a marketing strategy to promote DMARC deployment among organizations.
Expert view
Expert from Spamresource.com advised that DMARC's `sp` tag is crucial for managing subdomain policies, allowing for different rules compared to the organizational domain.
What the documentation says
Official documentation and technical guides consistently confirm that DMARC policies established at the organizational domain level apply by default to subdomains, a principle that BIMI is designed to leverage. However, for BIMI to function, these policies must be at an enforcement level, and the documentation details how specific subdomain records can override this inheritance.
Key findings
- Default DMARC application: By default, a DMARC policy set for an organizational domain will apply to its subdomains, as specified in the DMARC protocol.
- BIMI's DMARC dependency: BIMI requires the DMARC policy for the domain in use (organizational or subdomain) to be set to an enforcement policy, typically `p=quarantine` or `p=reject`.
- BIMI inheritance model: The BIMI specification is designed to work with inheritance; if a subdomain does not have a specific BIMI record, it will inherit the record from the organizational domain.
- Subdomain policy overrides: Organizations can define separate, explicit DMARC policies for subdomains using the sp= tag or a distinct DMARC record for the subdomain, which will override the parent domain's policy.
Key considerations
- Strict DMARC enforcement: To ensure BIMI display, verify that your DMARC policy is robust enough (e.g., at `p=quarantine` or `p=reject`) on both the organizational and relevant subdomains.
- Strategic BIMI placement: Publish the BIMI record at the organizational domain if you want it to apply broadly. For specific subdomains with unique branding, publish a separate BIMI record there.
- Understanding `sp` tag: Familiarize yourself with the DMARC sp tag, which dictates the policy for subdomains under an organizational domain. This is crucial for precise control over subdomain DMARC application.
Technical article
Documentation from BIMI Group FAQs specifies that a default BIMI record should be published at the organizational domain, allowing it to be inherited by all subdomains. This streamlines deployment for consistent branding.
Technical article
Documentation from Kickbox Blog clarifies that while BIMI can be published on the organizational domain or a subdomain, DMARC must always be published on the organizational domain if policy inheritance is desired.
Related resources
14 resources
Related pages
DMARC Policies for Organizational Domains and Subdomains Explained
Does BIMI require DMARC at the organizational level?
How do I implement BIMI for multiple brands with subdomains?
Should I add an explicit DMARC record for subdomains?
How do I set up DMARC records for subdomains?
Do subdomains need their own DMARC records?
How do DMARC records on subdomains override policies?
How does the DMARC sp tag affect policies?
A simple guide to DMARC, SPF, and DKIM
Which email clients actually support BIMI?
