How to prevent BIMI and Apple Branded Mail logos from displaying on subdomains without affecting deliverability?
Matthew Whittaker
Co-founder & CTO, Suped
Published 5 Jul 2025
Updated 19 Aug 2025
8 min read
Managing email branding across multiple domains and subdomains can be complex, especially when you need granular control over logo display. Many organizations want their brand logo to appear prominently on their primary sending domain for marketing and corporate communications, but prefer to suppress it on subdomains. This is often the case for transactional emails, client-specific sending domains, or internal communications, where a generic or client-specific logo might be more appropriate. The challenge then becomes how to achieve this without inadvertently damaging your email deliverability or risking your messages landing in the spam folder.
I often see questions about whether suppressing logos, particularly Brand Indicators for Message Identification (BIMI) and Apple Branded Mail logos, on subdomains will negatively impact deliverability. The good news is that with the right approach to DNS configuration and understanding how these protocols work, you can maintain control over your brand's appearance without affecting your sender reputation or inbox placement. This guide will walk you through the necessary steps and considerations.
Understanding BIMI and subdomain behavior
Brand Indicators for Message Identification, or BIMI, allows your brand's logo to appear next to your authenticated emails in supported inboxes like Gmail and Yahoo Mail. It works by leveraging your DMARC authentication, ensuring that only legitimately authenticated messages can display your logo. For BIMI to work, you need to publish a TXT record in your DNS for each specific domain or subdomain where you want the logo to appear. This record points to the SVG file of your logo and, optionally, to your Verified Mark Certificate (VMC).
Crucially, BIMI records are specific to the domain or subdomain they are published on. Unlike some other DNS records, BIMI does not automatically 'trickle down' from a parent domain to its subdomains. This means if you have BIMI set up on example.com, it will not automatically apply to marketing.example.com or app.example.com. If you want to prevent a logo from appearing on a subdomain, you simply don't publish a BIMI record for that specific subdomain. However, for domains or subdomains where a BIMI record might have been previously published, or if you want to explicitly signal a non-logo preference, you can use a valid BIMI 'declination to publish' record. This is an empty BIMI record that signals to mailbox providers that no logo should be displayed for that specific sending identity.
Example of a BIMI declination recordDNS
default._bimi.sub.example.com. IN TXT "v=BIMI1; a=; l=;"
This blank record is a legitimate part of the BIMI specification, signifying a deliberate choice not to display a logo. It has no negative impact on your email deliverability. The core requirement for BIMI, which also underpins secure email delivery, is a robust DMARC policy set to quarantine or reject. You can learn more about how to implement DMARC with BIMI on multiple subdomains.
Handling Apple Branded Mail on subdomains
Apple Branded Mail, introduced with iOS 18, is a separate mechanism from BIMI for displaying logos in Apple Mail. While BIMI relies on DNS records and DMARC authentication, Apple Branded Mail leverages Apple Business Connect to verify and display logos. This means the control over which domains and subdomains show a logo primarily resides within your Apple Business Connect account. To prevent the logo from appearing on subdomains, you simply do not register those specific subdomains within Apple Business Connect for Branded Mail.
Unlike BIMI, which uses a DNS record for each specific domain or subdomain, Apple Branded Mail's control is more centralized within the Apple Business Connect portal. This allows for a more direct management of which sending identities are approved for logo display within their ecosystem. It's important to understand the fundamental differences between BIMI and Apple Branded Mail to effectively manage your email branding strategy.
BIMI subdomain control
DNS-based: Control is achieved by publishing (or not publishing) a BIMI DNS TXT record for each specific subdomain.
Explicit declination: Use a blank record (v=BIMI1; a=; l=;) to explicitly prevent logo display, as specified in the BIMI specification.
Apple Branded Mail subdomain control
Platform-based: Control is managed within your Apple Business Connect account by registering specific domains and subdomains.
Omission is prevention: If a subdomain is not registered for Branded Mail in Apple Business Connect, its logo will not display. No special TXT record is needed to prevent display, unlike BIMI.
For both BIMI and Apple Branded Mail, the core principle for preventing logo display on subdomains is about explicit configuration rather than a trickling-down effect. For BIMI, it's about not publishing a record or publishing a blank one. For Apple Branded Mail, it's about selectively registering domains within their platform. These methods are designed to be safe and will not negatively affect your email deliverability.
Ensuring deliverability remains unaffected
A common concern when modifying DNS records related to email is the potential impact on deliverability. Rest assured, explicitly preventing BIMI or Apple Branded Mail logos from displaying on your subdomains using the methods described will not harm your email deliverability. Mailbox providers do not penalize domains for the absence of a brand logo. Their primary concern is whether your emails are authenticated correctly and adhere to anti-spam policies.
The true pillars of email deliverability are your underlying email authentication protocols: SPF, DKIM, and DMARC. These records verify that your emails are legitimately sent by your domain and protect against spoofing and phishing. If these are correctly configured for all your sending domains and subdomains, your deliverability should remain strong, regardless of logo display. Maintaining a DMARC policy of quarantine or reject is essential for both logo display and general email security, and it signals to receiving servers that your domain is serious about authentication. You can read more about safely transitioning your DMARC policy.
Key authentication requirements for deliverability
SPF: Ensure your SPF record lists all authorized sending IPs and services for each domain and subdomain. An incorrectly configured SPF record can lead to emails being marked as spam or even being blacklisted.
DKIM: Confirm that DKIM signatures are properly generated and attached to your emails, with corresponding public keys published in your DNS.
DMARC enforcement:A DMARC policy of p=quarantine or p=reject should be in place for your root domain and any subdomains that send mail.
Implementation best practices and common pitfalls
When managing BIMI and Apple Branded Mail on subdomains, adherence to best practices is key to avoiding unforeseen deliverability issues or blocklisting (or blacklisting). Always verify your DNS changes with a BIMI validator or DMARC record checker after making changes. Proactive monitoring of your email channels is also crucial for maintaining optimal performance. Consider using DMARC monitoring to keep an eye on your authentication results across all sending domains and subdomains. This gives you visibility into how mailbox providers are treating your emails and helps identify any potential problems quickly.
Do
Don't
Ensure DMARC is set to p=quarantine or p=reject for all sending domains and subdomains.
Forget to set up SPF and DKIM for all subdomains, as they are essential for email authentication.
Publish a blank BIMI record (v=BIMI1; a=; l=;) on subdomains where you wish to suppress the logo.
Assume BIMI or Apple Branded Mail logos automatically propagate or trickle down to subdomains.
Neglect to test email delivery after making any changes to your DNS records or branding configurations.
A common pitfall is the expectation that a BIMI record on the root domain will somehow apply to subdomains. This is incorrect. Each subdomain requires its own explicit BIMI record if a logo is desired, or an explicit blank record if suppression is preferred. For Apple Branded Mail, the pitfall often lies in not knowing that control is exercised via their portal, potentially leading to unintended logo displays if subdomains are auto-registered or not excluded. Another issue arises when DMARC is not properly configured for all subdomains, as both BIMI and Apple Branded Mail depend heavily on strong DMARC authentication.
Views from the trenches
Best practices
Always use a DMARC policy of p=quarantine or p=reject on all domains and subdomains that send email.
Regularly monitor DMARC reports to detect authentication issues and ensure proper logo display or suppression.
Explicitly publish blank BIMI records for subdomains where you want to prevent logo display.
Common pitfalls
Assuming BIMI records from the root domain automatically apply to or are inherited by subdomains.
Neglecting to configure DMARC, SPF, and DKIM for all sending subdomains, which are foundational for deliverability.
Not understanding the distinct differences in how BIMI and Apple Branded Mail manage logo display.
Expert tips
Confirm that the blank BIMI record is correctly formatted: 'v=BIMI1; a=; l=;'.
Be aware that Apple Business Connect offers granular control over which subdomains display branded mail logos.
Ensure your DNS provider supports the necessary record types for BIMI (TXT record) and allows for quick updates.
Expert view
Expert from Email Geeks says that a blank BIMI record, specifically an empty l= tag, is a perfectly valid declination to publish a logo and aligns with the BIMI specification.
2024-03-10 - Email Geeks
Marketer view
Marketer from Email Geeks confirms that using an empty l= tag for a BIMI record is a legitimate way to decline publishing a logo and should not cause issues.
2024-03-10 - Email Geeks
Navigating subdomain branding
Controlling the display of BIMI and Apple Branded Mail logos on your subdomains is entirely possible without compromising your email deliverability. The key is to understand the specific mechanisms for each protocol: using explicit DNS records (including declination to publish) for BIMI, and careful management within your Apple Business Connect account for Apple Branded Mail. By focusing on robust email authentication—SPF, DKIM, and DMARC enforcement—you ensure that your messages are delivered securely, regardless of whether a logo appears alongside them. This targeted approach allows you to maintain consistent branding where it matters most, while preventing unintended logo displays on other sending identities.
Gmail and 
Yahoo Mail. It works by leveraging your DMARC authentication, ensuring that only legitimately authenticated messages can display your logo. For BIMI to work, you need to publish a TXT record in your DNS for each specific domain or subdomain where you want the logo to appear. This record points to the SVG file of your logo and, optionally, to your Verified Mark Certificate (VMC).
Apple Mail. While BIMI relies on DNS records and DMARC authentication, Apple Branded Mail leverages Apple Business Connect to verify and display logos. This means the control over which domains and subdomains show a logo primarily resides within your Apple Business Connect account. To prevent the logo from appearing on subdomains, you simply do not register those specific subdomains within Apple Business Connect for Branded Mail.
