Suped

Does an organizational DMARC policy cover subdomains for BIMI?

Michael Ko profile picture
Michael Ko
Co-founder & CEO, Suped
Published 24 Jun 2025
Updated 18 Aug 2025
8 min read
When deploying Brand Indicators for Message Identification (BIMI), a common question arises regarding how DMARC (Domain-based Message Authentication, Reporting, and Conformance) policies interact with subdomains. Specifically, if you have an organizational DMARC policy in place, will it automatically extend to cover your subdomains, allowing your brand logo to display on emails sent from those subdomains? This is a crucial consideration for maintaining a consistent brand presence and ensuring email authentication across all your sending domains.
The short answer is yes, generally, an organizational DMARC policy can cover subdomains for BIMI. DMARC inherently includes a mechanism for subdomain inheritance. This means that a DMARC record published at your organizational (root) domain, such as _dmarc.example.com, will apply to all its subdomains like news.example.com or marketing.example.com, unless a specific DMARC record is explicitly published for a subdomain.
This default behavior is facilitated by the DMARC protocol itself. When an email receiver checks for a DMARC policy for a sending subdomain, and no specific DMARC record is found for that subdomain, the receiver will look for a DMARC record at the organizational domain. This principle of inheritance is fundamental to how DMARC operates across a domain hierarchy.
Suped DMARC monitoring
Free forever, no credit card required
Learn more
Trusted by teams securing millions of inboxes
Company logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logo

How DMARC policy inheritance works

DMARC policies are defined using tags within the DNS record. The primary policy tag, p=, specifies the policy for the organizational domain itself. To explicitly control subdomain policies, the sp= (subdomain policy) tag can be used. If the sp= tag is omitted, the p= policy applies to all subdomains by default. This is why a single DMARC record can effectively cover your entire domain space for authentication purposes.
Organizational DMARC record (applies to subdomains by default)DNS
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com;
However, you can choose to define a specific DMARC record for a subdomain. For instance, if you have a subdomain marketing.example.com, you can publish a DMARC record directly under _dmarc.marketing.example.com. This subdomain-specific record would then override the organizational policy for that particular subdomain. This flexibility allows for granular control over how different parts of your domain hierarchy handle DMARC enforcement.
For a deeper dive, consider understanding DMARC policies for organizational domains and subdomains, as well as whether subdomains need their own DMARC records or if the main domain's record suffices. The interaction between root and subdomain DMARC policies, including how subdomain records override root domain policies, is key to advanced configurations.

BIMI's reliance on DMARC enforcement

For BIMI to display your brand logo, the underlying DMARC policy for the sending domain, whether organizational or subdomain-specific, must be set to an enforcement policy. This means the p= tag must be either quarantine or reject, with the pct= tag, if present, set to 100%. This strict policy ensures that the email is properly authenticated and aligned with the domain, building trust with mailbox providers.

BIMI enforcement policy requirements

BIMI relies on DMARC's enforcement to verify the legitimacy of the sender. If your DMARC policy is set to p=none (monitoring mode), the BIMI logo will generally not be displayed. This is because p=none instructs receivers not to take action on unauthenticated mail, which doesn't meet BIMI's trust requirements. The BIMI Group's implementation guide emphasizes this requirement.
It's important to understand that if your organizational DMARC policy is p=quarantine or p=reject, and no specific DMARC record exists for a subdomain, that enforcement policy will automatically apply to the subdomain. This then allows BIMI to work on emails sent from that subdomain, assuming all other BIMI requirements (like a Verified Mark Certificate and SVG logo) are met for the organizational domain. For more context on the policy types, consider our guide on simple DMARC examples.

BIMI and subdomain behavior

The BIMI specification is designed to work with DMARC's inheritance model. If a subdomain sends an email and does not have its own specific BIMI record (a TXT record starting with v=BIMI1), the receiving mail server will then check for a BIMI record on the organizational domain. If found, and the DMARC policy for the sending domain (whether inherited or explicit) is at enforcement, the organizational domain's BIMI logo should display. This is a crucial aspect of how the BIMI specification works, allowing for broad applicability with a single BIMI setup.
This means that for many organizations, publishing a single BIMI record at the organizational domain level can be sufficient to enable BIMI for all their subdomains, provided their DMARC configuration supports this inheritance for enforcement. This simplifies the deployment process considerably, especially for companies with numerous subdomains used for different email sending purposes (e.g., transactional, marketing, support).
However, some organizations might prefer to apply a specific BIMI logo to a particular subdomain, or even exclude certain subdomains from BIMI display. In such cases, you can publish a dedicated BIMI record for that subdomain. This allows for tailored branding strategies across different email streams. For scenarios involving complex branding needs, you might want to explore how to implement BIMI for multiple brands or apply BIMI to a specific subdomain.

Important considerations for BIMI and subdomains

While DMARC's default inheritance is convenient, it's crucial to ensure that your DMARC policy is robust enough for BIMI to function correctly on subdomains. This means having a p=quarantine or p=reject policy that covers the subdomains from which you send email. If your organizational DMARC is still in p=none mode, you will need to progress to an enforcement policy for BIMI to activate. Zoho emphasizes this DMARC enforcement for BIMI adoption.

Scenario 1: Organizational DMARC covers subdomains

Your primary domain (example.com) has a DMARC record set to p=quarantine. No specific DMARC record for marketing.example.com.
  1. DMARC Policy: The organizational policy of p=quarantine inherits down to marketing.example.com.
  2. BIMI Logo Display: If a BIMI record exists for example.com, the logo can display on emails from marketing.example.com, provided SPF/DKIM align.

Scenario 2: Subdomain has explicit DMARC and BIMI

Your primary domain (example.com) has p=none, but marketing.example.com has its own p=reject policy and a BIMI record.
  1. DMARC Policy: The specific p=reject policy for marketing.example.com takes precedence.
  2. BIMI Logo Display: The specific BIMI record for marketing.example.com will be used, overriding any organizational BIMI record.
Furthermore, ensuring proper SPF and DKIM alignment is paramount. DMARC relies on these underlying authentication protocols, and if they fail alignment checks, the DMARC policy (and thus BIMI display) will not be successful, regardless of your subdomain configuration. Some email providers, like Fastmail, highlight this requirement for BIMI to work. Consistent authentication across all your sending domains and subdomains is the foundation of good email deliverability and brand presence.

Understanding DMARC and BIMI alignment

To illustrate the interaction between DMARC policies and BIMI display across different domain levels, here's a table summarizing common scenarios:

Domain Type

DMARC Policy Configuration

BIMI Record Location

BIMI Logo Display (assuming valid VMC)

Organizational Domain
p=quarantine or p=reject
Organizational domain
Yes, for emails from the organizational domain
Subdomain (inherited DMARC)
Organizational p=quarantine or p=reject (no sp= or specific subdomain DMARC)
Organizational domain
Yes, as DMARC and BIMI records inherit by default
Subdomain (explicit DMARC)
Specific subdomain DMARC record set to p=quarantine or p=reject
Subdomain (specific record)
Yes, using the subdomain's specific logo
Any Domain/Subdomain
p=none
Anywhere
No, BIMI requires an enforcement policy
While the default DMARC inheritance is a powerful feature, careful planning and ongoing monitoring are essential. You need to verify that all your sending IPs and domains (including subdomains) are correctly authenticated with SPF and DKIM to achieve DMARC alignment. This is critical for avoiding deliverability issues and ensuring your BIMI logo appears as intended.

Views from the trenches

Best practices
Ensure your organizational DMARC record uses an enforcement policy (quarantine or reject) for BIMI to display on subdomains.
Always maintain strong SPF and DKIM authentication records for all sending domains and subdomains to ensure DMARC alignment.
Use DMARC aggregate reports to monitor email authentication results for all subdomains and verify policy enforcement.
Consider a dedicated BIMI record for a subdomain if you require a different logo for that specific sending entity.
Regularly check your DNS records for accuracy and ensure no conflicting DMARC or BIMI records exist.
Common pitfalls
Assuming DMARC "p=none" is sufficient for BIMI display, which it is not.
Forgetting to align SPF and DKIM for subdomain email sources, leading to DMARC authentication failures.
Not monitoring DMARC reports, missing issues where subdomain emails fail authentication despite an organizational policy.
Failing to update your BIMI record if your logo or VMC (Verified Mark Certificate) changes, causing logo display issues.
Overlooking the impact of the "sp=" tag or specific subdomain DMARC records on overall policy inheritance.
Expert tips
Start with a DMARC monitoring policy ("p=none") and gradually move to enforcement (quarantine/reject) once you're confident in your authentication setup.
For complex environments, strategically use subdomain-specific DMARC records to fine-tune policies without impacting the entire organizational domain.
If using multiple logos across subdomains, implement BIMI selectors to manage them effectively under a single organizational BIMI record.
Regularly test your email setup by sending emails from various subdomains to major mailbox providers to confirm BIMI logo display.
Be aware that some mailbox providers may have unique interpretations or slower adoption rates for BIMI, affecting logo display.
Marketer view
Marketer from Email Geeks says DMARC generally applies to all subdomains, but it's important to confirm this behavior for specific implementations.
2019-08-29 - Email Geeks
Marketer view
Marketer from Email Geeks says they were under the impression DMARC would apply to all subdomains unless a specific record existed for the subdomain itself.
2019-08-29 - Email Geeks

Final thoughts on BIMI and DMARC subdomain coverage

In conclusion, an organizational DMARC policy does indeed cover subdomains for BIMI by default. This inheritance means that if your root domain's DMARC record is set to an enforcement policy ("p=quarantine" or "p=reject"), and you have a valid BIMI record at the organizational level, your logo should display on emails sent from subdomains, provided those emails pass DMARC authentication (via SPF and DKIM alignment).
However, the flexibility of DMARC and BIMI allows for more granular control. You can publish specific DMARC records for individual subdomains to override the organizational policy, and similarly, implement distinct BIMI records for subdomains if different branding is required. The key is to ensure consistent DMARC enforcement across all sending domains and subdomains that you wish to enable for BIMI, as proper authentication is the bedrock of this visual branding standard.
Staying on top of your DMARC reports and ensuring all your sending sources are properly authenticated will help guarantee your BIMI logo consistently appears, reinforcing your brand's legitimacy and improving trust with your recipients.

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