FAQs For Marketers and ESPs

Brand Indicators for Message Identification (BIMI) is an emerging email specification designed to enhance email authentication and brand recognition within supporting email clients. BIMI leverages the existing DMARC protocol, ensuring that email messages pass DMARC authentication checks before displaying brand-controlled logos. Additionally, BIMI relies on the foundation laid by SPF and DKIM protocols, requiring successful SPF and DKIM authentication to validate the sender’s domain and the integrity of the message content. By connecting BIMI with DMARC, SPF, and DKIM, the protocol aims to provide a comprehensive solution for preventing domain impersonation, improving email security, and enhancing brand identification in the inbox.

BIMI allows an organization to publish a new, standardized DNS record for a domain they own. This record contains a URL to a logo that may require proof that the logo has been validated with a VMC. An organization will publish a BIMI record containing these URLs. A supporting mailbox provider (MBP) will check the sending domain’s DMARC policy and verify that it is configued with an enforcement policy (p=quarantine or p=reject) before completing the BIMI validation. If both checks are successful, the MBP may use the logo from the URL in the BIMI record to populate the BIMI image of the qualifying email sent from that domain to the MBP.

BIMI plays a role in anti-abuse efforts by helping to combat email impersonation. It allows companies to display their logos next to authenticated emails in the recipient’s inbox, providing a visual indicator. This can make it more difficult for attackers to impersonate trusted brands with fraudulent emails.

Sender Policy Framework (SPF) is an email authentication protocol designed to address email spoofing by allowing domain owners to specify which mail servers are authorized to send emails on behalf of their domain. SPF works by adding a DNS record to the domain’s DNS information, listing the IP addresses of authorized mail servers. When an email is received, the recipient’s mail server checks the SPF record to verify that the source IP address is legitimate. If the check fails, the email may be flagged as potentially fraudulent. SPF helps prevent unauthorized senders from exploiting a domain by impersonating it in email communication, enhancing email security through sender validation.

DomainKeys Identified Mail (DKIM) is an email authentication method that adds a digital signature to outgoing emails. This signature is generated using cryptographic keys, and the public key is published in the sending domain’s DNS records. When the recipient’s email server receives a DKIM-signed message, it can use the public key to verify the signature. If the signature is valid, it indicates that the email hasn’t been tampered with during transit and that it originated from an authorized source. DKIM helps enhance email security by providing a mechanism for recipients to verify the legitimacy of the sender, reducing the risk of email forgery and phishing attacks.

DMARC, or Domain-based Message Authentication, Reporting & Conformance, is a comprehensive email authentication protocol aimed at bolstering the security of email communication. It builds upon the existing SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) protocols, adding an additional layer of protection. SPF verifies the sender’s IP address, while DKIM ensures the integrity of email content through cryptographic signatures. DMARC combines these methods, allowing domain owners to set policies that dictate the actions to be taken when SPF or DKIM authentication fails. This three-pronged approach significantly reduces the risk of domain spoofing, phishing, and unauthorized use, enhancing overall email security and trustworthiness.

DMARC enforcement represents a particular attribute of a DMARC record “p=”. This attribute indicates how the record holder authorizes the mail receiver to handle mail that fails DMARC and authentication checks. Enforcement can be “p=quarantine” which indicates failed messages should be quarantined, or “p=reject” which indicates failed messages should be rejected. The policy must be either “p=quarantine” or “p=reject” on the organizational domain, without gaps such as sp=none or pct less than 100.

Senders will need an email sending domain with a DMARC policy of at least quarantine or reject. Some mailbox providers may require senders to obtain a verified mark certificate (VMC). Senders will need a logo, for which they own the mark, hosted on a URL that follows the specification parameters requirements. The final step is to build a simple BIMI DNS record and publish it to DNS. Follow our Guide found here.

Compared to senders who do not implement BIMI, your brand logo may appear with your messages. Recipients may better recognize and interact with your messaging by making a visual connection to your brand logo and increase your brand’s engagement through direct customer response. BIMI may potentially improve email opens or clicks, as compared to messages sent without logo impressions in the user’s mailbox.

When BIMI is set up, the primary logo or symbol associated with your brand will be displayed alongside your email address. This BIMI logo serves as a visual representation of your brand and recognition among recipients. However, it’s important to note that the display of user profile photos in internal mail may vary among different mailbox providers. While BIMI implementation does not replace or override the user profile photos in general, some mailbox providers might have their own policies or interfaces that could affect the visibility or presentation of user profile photos alongside the BIMI logo. In most cases, the user contact card or similar interface will continue to display individual user profile photos as usual, ensuring that recipients can easily identify and connect with the specific sender.

Currently, BIMI supports one logo for multiple domains and subdomains. BIMI certificates (VMCs) – which some mail systems may require – each only support a single logo, which must be a trademark. Read more about Selectors here and here.

A default BIMI record should be published at the Organizational Domain, allowing it to be inherited by all subdomains. The domain administrator may publish a BIMI record on a subdomain. If a BIMI record is found at that subdomain, the mailbox provider can use it (even if it differs from the BIMI record published at the Organizational Domain).

To correctly assert logo association to a given message, the current BIMI specification relies on a successful validation of the BIMI record, relative to a sending domain. It is up to the domain and mark owner to reference the correct logo to use in a BIMI record for a domain.

BIMI’s strong authentication requirement – DMARC at enforcement – provides brands the opportunity to prevent their domain(s) from abuse, therefore potentially improving trust with their customers. BIMI builds on this foundation of trust and authentication.

Receivers will attempt to retrieve a BIMI record from the domain identified by DMARC alignment for the RFC5322.From Author Domain. In the case of DKIM alignment, the BIMI record would be retrieved from the domain identified within the DKIM “d=” value.

A BIMI record has three attributes:

• v = bimi1 – the record declaration indicating that this is a BIMI record
• l = URL – the hosting location of the SVG image.
• a = URL – the hosting location of the VMC/Assertion record

Each attribute is separated by a semicolon (;) and the final record will look similar to this:

BIMI relies on a scale vector format, specifically described as an SVG profile (currently defined as SVG Tiny PS). Logos should be square, high-resolution image with a solid background color and enough space that it that will display in a circle. Being a vector graphic BIMI logos are not defined by pixel size, please consult your graphic designer for help in creating a proper SVG file.

The BIMI group has published an infographic here showing the current status of BIMI in use by a number of large Mailbox Providers. Some mailbox providers may be publishing logos using proprietary image hosting mechanisms which will have their own requirements. The intention of BIMI is to centralize and streamline the support of logos in these providers by implementing strong authentication and validation of ownership with a VMC.

You can read about which types of Mark are acceptable in Appendix B of the VMC Guidelines document. Currently, VMCs are available from Digicert, and Entrust DataCard. More providers are expected to be added in the future.

I represent a government agency which has a logo that is not a registered trademark, how do we get a Verified Mark Certificate (VMC)?

Is it a problem if I want to have BIMI on my email domain but the images (the image path) is myimagehost.com?

Where should I publish the BIMI Record?

I want to exclude a specific subdomain?

We have published our BIMI record; how do we verify it’s working?

I’m not seeing my logos

Why is a mailbox provider or testing tool reporting issues retrieving my SVG/VMC file?

My ESP doesn’t provide the ability for us to modify the SMTP.from (ex: bounce.esp.com, RFC 5321) domain when they send email on behalf of our domain. Will this be a problem for BIMI?

Why is “Brand” logo showing while they don’t have a BIMI record?

How will BIMI impact Annotations?

How is Yahoo different from other BIMI implementations?

How do I get support at [mailbox provider]?