What are the DMARC requirements for BIMI and how does pct affect the policies?
Michael Ko
Co-founder & CEO, Suped
Published 1 May 2025
Updated 16 Aug 2025
8 min read
Brand Indicators for Message Identification (BIMI) allows organizations to display their registered brand logo next to their sender name in the recipient's inbox. This visual verification significantly enhances brand recognition and helps recipients identify legitimate emails, fostering trust and improving engagement. However, unlocking this powerful branding opportunity isn't as simple as just uploading a logo. BIMI relies heavily on strong email authentication, specifically DMARC, to ensure the sender's legitimacy and prevent fraudulent use of brand logos.
The core of BIMI's security framework is DMARC (Domain-based Message Authentication, Reporting, and Conformance). DMARC builds upon SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) to verify that emails are truly from the domains they claim to be from. For your brand logo to be displayed, your domain's DMARC policy must meet specific enforcement requirements. Many organizations often start with a p=none policy for monitoring, but for BIMI, a stricter stance is necessary. This is where the intricacies of DMARC policies, and particularly the pct tag, become critical. Understanding these requirements is key to successfully implementing BIMI and boosting your email's visual impact.
I’ve seen firsthand how confusing these DMARC requirements can be. It's not just about having a DMARC record, but about having one that's configured precisely for BIMI eligibility. We’ll delve into the specific DMARC policy requirements for BIMI and clarify how the pct tag impacts these policies, ensuring your domain is ready to display your brand's logo.
To participate in BIMI, your domain needs a DMARC policy that is in enforcement mode. This means your DMARC record's p tag, which defines the policy for emails that fail DMARC authentication, must be set to either quarantine or reject. A p=none policy, while useful for initial monitoring, is not sufficient for BIMI enablement. This is a critical point that the BIMI specification explicitly states.
The enforcement applies to both the organizational domain and the specific RFC5322.From domain of the email. This means if you're sending emails from a subdomain, that subdomain's DMARC policy (or the organizational domain's policy if no explicit subdomain policy exists) must also be at an enforcing level. This dual requirement ensures a strong security posture, which is essential for brand trust. You can learn more about BIMI requirements and implementation steps.
Achieving DMARC enforcement requires a thorough understanding of your email ecosystem, ensuring all legitimate sending sources are properly authenticated with SPF and DKIM. This process can be complex, involving careful monitoring of DMARC reports from Google and Yahoo to identify any unauthorized senders or misconfigurations. Only once you have a clear picture of your email traffic and have remediated issues can you confidently transition to an enforcing policy.
Best practice for DMARC rollout
Transitioning your DMARC policy from p=none to p=quarantine or p=reject should be a gradual process. Start with p=quarantine; pct=10 and slowly increase the pct value as you gain confidence in your DMARC compliance. Regularly review your DMARC aggregate reports to identify and address any legitimate email streams that are failing authentication. This methodical approach minimizes disruption and helps maintain email deliverability while working towards BIMI eligibility. For a detailed guide, see Dotdigital's setup advice.
The role of the pct tag in DMARC policies
The pct tag in a DMARC record specifies the percentage of messages that should be subjected to the DMARC policy. For instance, pct=50 means only 50% of non-compliant emails will be subjected to the defined policy (quarantine or reject), while the remaining 50% will be treated as if the policy were p=none. However, for BIMI, there's a specific requirement regarding this tag.
When your DMARC policy is set to p=quarantine, BIMI requires that the pct tag must be set to 100. This ensures that all non-compliant messages are quarantined, providing a consistent and strong signal of authentication. If pct is less than 100 for a p=quarantine policy, your domain will not be BIMI eligible because a percentage of failed messages would effectively be treated as p=none policy.
Interestingly, if your DMARC policy is set to p=reject, the pct tag doesn't necessarily need to be 100 for BIMI eligibility. This is because any percentage not subjected to reject will default to quarantine. Since both reject and quarantine are considered enforcing policies for BIMI, any pct value with p=reject will still satisfy the enforcement requirement. The key takeaway is to avoid p=none in any capacity for BIMI-eligible domains.
BIMI's DMARC requirements apply to both your organizational domain (e.g., yourdomain.com) and any subdomains from which you send email (e.g., mail.yourdomain.com). This can sometimes lead to confusion, especially when different policies are in place across various parts of your domain.
If your organizational domain has a DMARC policy of p=reject, but one of your subdomains has an explicit DMARC policy of p=none, this particular subdomain will not be BIMI-capable. However, it will not affect the BIMI capability of your organizational domain or other subdomains that maintain enforcing policies. The mail receiver performing the DMARC/BIMI validation will primarily focus on the DMARC policies of the RFC5322.From domain and its organizational parent. Understanding this hierarchy is crucial for ensuring all your sending domains comply.
This highlights the importance of granular DMARC management, especially for organizations with complex email infrastructures. You need to ensure that every domain and subdomain used for sending emails has a DMARC record that aligns with BIMI's enforcement requirements. If a subdomain is used for marketing emails, its policy needs to be just as robust as your main domain. For more details, consider whether an organizational DMARC policy covers subdomains for BIMI.
Scenario: organizational domain at reject
Main domain DMARC: p=reject; pct=100
Subdomain 1 (sales): p=quarantine; pct=100
Subdomain 2 (newsletters): p=none; rua=...
BIMI impact
Only emails sent from Subdomain 2 will not be eligible for BIMI due to its p=none policy. The organizational domain and Subdomain 1 (sales) will still be able to display their logos. The individual subdomain's policy directly impacts its own BIMI status, not the overarching domain's or other subdomains'.
Scenario: specific subdomain at none
Main domain DMARC: p=quarantine; pct=100
Subdomain 1 (support): p=reject; pct=100
Subdomain 2 (marketing): p=none; rua=...
BIMI compliance implication
In this scenario, emails from the organizational domain and Subdomain 1 (support) will be BIMI-eligible. However, emails from Subdomain 2 (marketing) will not, due to its explicit p=none policy. This illustrates that subdomains require independent assessment for BIMI readiness, even if the main domain is compliant. It's crucial to review DMARC policy settings for BIMI.
Preparing your domain for BIMI
Achieving BIMI readiness involves more than just setting your DMARC policy. It's about a holistic approach to email authentication and brand management. First, ensure your SPF and DKIM records are correctly configured and aligned with your DMARC policy. Without proper alignment, DMARC will fail, regardless of your policy. Once you are confident that your legitimate emails are consistently passing DMARC, you can move towards stricter policies.
Regularly monitoring your DMARC reports is essential during this process. These reports provide invaluable insight into your email traffic, showing you which emails are passing or failing DMARC authentication and why. This data allows you to identify any legitimate sending sources that might not yet be authenticated or any malicious activity (spoofing) targeting your domain. Effective DMARC monitoring is critical for a smooth transition to enforcement and for maintaining a strong email security posture.
Finally, ensure your BIMI SVG logo is correctly formatted and accessible via a BIMI Assertion Record in your DNS. Some Mail User Agents (MUAs) like Gmail also require a Verified Mark Certificate (VMC) for logo display, adding another layer of trust and verification. While the pct tag will eventually be removed in future DMARC specifications (DMARCbis), for now, adhering to the current pct requirements is vital for your BIMI implementation.
Key considerations for BIMI implementation
Consistent DMARC enforcement: Ensure all domains and subdomains used for sending have a policy of p=quarantine or p=reject.
Pct tag accuracy: For p=quarantine, pct must be 100. For p=reject, any pct value is acceptable.
SVG logo and VMC: Prepare your SVG logo according to BIMI specifications. Consider obtaining a Verified Mark Certificate for broader support, especially for Google and Yahoo.
Continuous monitoring: Keep an eye on your DMARC reports to detect and resolve any authentication issues promptly, ensuring consistent BIMI display.
Views from the trenches
Best practices
Ensure DMARC is set to an enforcing policy (quarantine or reject) at 100% for all relevant sending domains.
Use a methodical approach to DMARC policy deployment, gradually increasing enforcement percentages.
Always align your SPF and DKIM records with your DMARC policy for robust authentication.
Regularly monitor DMARC aggregate reports to identify and fix any authentication failures.
Keep an eye on the BIMI specification for any updates, as it is an evolving standard.
Common pitfalls
Leaving DMARC at p=none, which prevents BIMI logo display.
Not setting pct=100 for p=quarantine policies, causing BIMI failure.
Assuming an organizational domain's reject policy automatically covers all subdomains for BIMI, ignoring explicit subdomain policies.
Overlooking unauthenticated legitimate email sources, leading to deliverability issues when enforcing DMARC.
Neglecting to validate the BIMI SVG image and ensuring it meets all technical requirements.
Expert tips
Transition to p=quarantine with a low pct first, then increment. This allows for careful monitoring.
If your organizational domain is at reject, remember that any pct value below 100 will default to quarantine for the remaining percentage, which is still BIMI-compliant.
Be aware that DMARCbis aims to remove the pct tag, but its adoption is still a long way off.
If a subdomain has an explicit p=none policy, it will prevent BIMI for that specific subdomain, regardless of the organizational domain's policy.
Trust the official BIMI specification over informal documentation for the most accurate requirements.
Marketer view
Marketer from Email Geeks says they were confused about the DMARC policy requirements for BIMI, specifically the pct tag for organizational and subdomain policies, and why p=quarantine needs pct=100 while p=reject does not.
2023-02-01 - Email Geeks
Expert view
Expert from Email Geeks says that the BIMI specification requires a strong DMARC policy (quarantine or reject) for both the organizational domain and the RFC5322.From domain, and quarantine policies must have a pct of 100.
2023-02-01 - Email Geeks
Summary of BIMI DMARC requirements
Implementing BIMI can significantly boost your brand's visibility and trust in the inbox, but it hinges entirely on a robust DMARC implementation. The key takeaway is that both your organizational domain and the specific RFC5322.From domain must have DMARC policies set to quarantine or reject. Furthermore, if you opt for a p=quarantine policy, the pct tag must be at 100.
By diligently monitoring your DMARC reports, ensuring SPF and DKIM alignment, and carefully transitioning your DMARC policies, you can successfully navigate the requirements and unlock the full potential of BIMI for your brand's email presence. This commitment to email security not only enables BIMI but also significantly improves your overall email deliverability and protects your domain from phishing and spoofing attacks.