What is a stub BIMI record?

A stub BIMI record, also known as a 'declination to publish' record, is a valid DNS entry that explicitly indicates a domain owner's choice not to display a BIMI logo for that particular domain. It's often represented by a specific string that tells mail clients not to look for a logo.

Why doesn't Apple use a full BIMI record on icloud.com?

Apple uses a stub BIMI record on domains like icloud.com because these are primary user domains where personal avatars or user-specific branding typically takes precedence over a corporate logo. They do, however, use full BIMI records on corporate subdomains for official communications.

Is a stub BIMI record a valid configuration?

Yes, a stub BIMI record is a valid configuration according to the BIMI specification. It explicitly signals the sender's intent not to display a logo for that domain, preventing unexpected behavior from mail clients.

Is Apple Branded Mail the same as BIMI?

No, Apple's own Branded Mail feature (part of Apple Business Connect) is a separate system for displaying logos in Apple Mail. While Apple Mail supports BIMI, Apple's internal system can take precedence or offer an alternative path for logo display, particularly for verified businesses.

Why does Apple use a stub BIMI record on its primary user email domain? - Technical - Email deliverability - Knowledge base

Email deliverability professionals often wonder why some prominent domains choose not to fully implement Brand Indicators for Message Identification (BIMI). A common point of curiosity revolves around Apple, especially its primary user email domain, icloud.com. If you check its DNS records, you'll find what appears to be a 'stub' BIMI record, which is technically a 'declination to publish' record.

This setup might seem counterintuitive at first, given Apple's focus on user experience and security. Why would a company that champions strong email authentication and brand consistency opt out of a visible brand indicator on such a critical domain? The answer lies in a combination of technical strategy, user experience considerations, and the evolving landscape of email branding.

Understanding this decision requires a deeper dive into how BIMI works, Apple's own email branding initiatives, and the distinction between corporate communication domains and personal user domains. It’s a nuanced topic that highlights the flexibility available within email standards.

What is BIMI?

BIMI (Brand Indicators for Message Identification) is an email specification that allows organizations to display their brand logo next to authenticated email messages in the recipient's inbox. This visual cue helps recipients instantly recognize legitimate senders, enhancing trust and engagement. For BIMI to work, the sender's domain must have robust email authentication in place, specifically DMARC with a policy enforced at quarantine or reject. Many email clients actually support BIMI.

The primary goal of BIMI is to provide a standardized way for brands to display their logos, helping to combat phishing and improve the overall email experience. It adds another layer of visual authentication beyond the technical protocols like SPF, DKIM, and DMARC. The BIMI Group's FAQs outline these benefits clearly.

To implement BIMI, a DNS TXT record is published for the domain, pointing to the location of the brand's logo (an SVG file). In some cases, a Verified Mark Certificate (VMC) is also required, which cryptographically binds the logo to the authenticated domain, providing an even higher level of assurance. This is part of a comprehensive email authentication strategy that includes DMARC, SPF, and DKIM.

Sample BIMI DNS record

Example BIMI TXT record with VMCDNS

default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem;"

Apple's unique stance on brand indicators

Apple has its own system for displaying brand logos in Apple Mail, known as Apple Branded Mail, which is part of Apple Business Connect. While BIMI is a widely adopted standard, Apple's approach has some distinct differences. Apple Branded Mail relies on businesses verifying their identity and branding directly with Apple, rather than solely through BIMI DNS records. This often leads to questions about whether to use BIMI or Apple Branded Mail.

This separate system gives Apple granular control over which logos are displayed in their ecosystem, ensuring a consistent and secure user experience that aligns with their privacy and security policies. It's designed to protect users from spoofing and other malicious activities by linking brand identity directly to Apple's own verification processes. Apple's support documentation on BIMI in Apple Mail clarifies some of their criteria.

While Apple does support BIMI in a general sense, its own branded mail feature often takes precedence within its mail clients, or at least provides an alternative path for logo display. This dual approach means that even if a domain has a valid BIMI record, Apple might rely on its internal verification for logo display, particularly for its own services.

This strategic divergence allows Apple to maintain tight control over the visual presentation and security assurances within its native applications, reflecting its commitment to a curated user experience. It also means that businesses aiming to display their logos consistently across all mail clients need to consider both BIMI and Apple’s specific requirements. Many organizations find themselves troubleshooting Apple Business Connect logos when they don't appear.

BIMI

Relies on a DNS TXT record for logo publication.

Requires DMARC enforcement (p=quarantine or p=reject).

Standardized across participating mailbox providers.

Apple branded mail

Relies on business verification directly with Apple.

Integrates with Apple Business Connect for identity management.

Primarily affects logo display in Apple Mail clients.

Why a stub record for primary user domains?

The presence of a stub BIMI record on icloud.com (and other similar user domains) is a deliberate choice by Apple. This type of record, often referred to as a 'declination to publish,' signals that the domain owner has chosen not to publish a full BIMI record for that specific domain. This is perfectly valid within the BIMI specification, as noted in the IETF BIMI draft.

One key reason for this approach is the nature of a primary user domain like icloud.com. Emails sent from this domain are typically personal user emails, not corporate or marketing communications from Apple itself. For such domains, the user's profile picture or avatar often takes precedence over a generic brand logo. Overwriting user-specific branding with a corporate logo could detract from the personal experience Apple aims to provide.

Conversely, Apple does implement full BIMI records on its corporate and transactional subdomains, such as email.apple.com. This strategy allows them to control the branding where it's most relevant—for official communications that benefit from a clear, company-approved logo. This also aligns with best practices for implementing BIMI on subdomains.

By publishing a stub record on icloud.com, Apple is explicitly stating that they do not intend for a brand logo to appear via BIMI on emails originating from that domain. This prevents any ambiguity or potential misinterpretation by BIMI-compliant mail clients. It’s a clean way of saying, 'No logo here, please defer to other display mechanisms or user preferences'.

Views from the trenches

Best practices

Always align your BIMI strategy with your brand’s overall email authentication and branding goals.

Utilize subdomains for specific email types, applying BIMI where a corporate logo is most appropriate.

Ensure your DMARC policy is at quarantine or reject for the domains you intend to implement BIMI on.

Regularly monitor your DNS records to confirm they are correctly published and resolving for BIMI and other authentication.

Common pitfalls

Expecting BIMI to automatically display on all domains, especially consumer-facing ones, without a specific record.

Confusing Apple's proprietary logo display with universal BIMI support, leading to troubleshooting issues.

Failing to understand the difference between a full BIMI record and a 'declination to publish' stub record.

Overlooking the importance of DMARC enforcement as a prerequisite for BIMI implementation.

Expert tips

Expert from Email Geeks says: A 'declination to publish' record (stub BIMI) is like an explicit negative SPF record; it clearly states no BIMI is intended for that domain.

Expert from Email Geeks says: Consider the purpose of each domain when deciding on BIMI implementation; primary user domains often benefit from user-specific imagery.

Marketer from Email Geeks says: Apple's approach highlights that email branding isn't a one-size-fits-all, requiring a tailored strategy for different platforms.

Expert from Email Geeks says: Always verify the exact BIMI record type you are publishing to avoid unintended logo displays or lack of display.

Marketer view

Marketer from Email Geeks says that they have observed Apple setting up BIMI on key subdomains rather than the primary domain.

2024-08-16 - Email Geeks

Expert view

Expert from Email Geeks says that iCloud is a consumer domain, so it's unlikely to have a full BIMI record.

2024-08-16 - Email Geeks

Strategic BIMI choices

Apple's decision to use a stub BIMI record on icloud.com is a strategic one, reflecting a careful balance between universal standards and tailored user experiences. By explicitly declining to publish a full BIMI record on its primary user domain, Apple ensures that personal email experiences are not overridden by corporate branding, while still maintaining robust authentication and allowing for brand display on relevant corporate subdomains.

This approach highlights that a 'missing' or 'stub' record isn't necessarily a misconfiguration but often a deliberate choice within a broader email security and branding strategy. For email senders, it's a valuable lesson in understanding that not every domain needs a full BIMI implementation, especially when different types of email (e.g., personal vs. transactional) are involved, or when a platform has its own dedicated branding mechanism.