If you have noticed a company logo displayed next to emails in your GMail or Yahoo! Mail account and wondered how to do that for your company; this article will show you how by using BIMI.
Brand Indicators for Message Identification, or BIMI (pronounced: Bih-mee), allows the owner of a domain name to allow participating e-mail clients to display a specified logo next to authenticated e-mails. Early trials claim a 10% increase in open rates on e-mails displayed alongside a BIMI image.
There are two parts to BIMI: a method for domain owners to publish the location of their logo image file, and a means for mail servers to verify the authenticity of that logo.
At the time this article was written, only Google’s GMail, Yahoo! Mail, Verizon Media (including AOL and Netscape Mail), and FastMail support BIMI. A working group made up of several companies and named “BIMI Group” has formed to develop a draft IETF standard for BIMI.
Although the draft standard is currently in use by the mail services listed above, the standard has not been completely fleshed out yet. For example, BIMI is supposed to provide a means for mail servers to authenticate that the company logo belongs to the sender of the e-mail. Proposed methods include connecting to an API endpoint on a web site to retrieve validation data, or a VMC (Verified Mark Certificate, a.k.a. MVC or Mark Verified Certificate) which is a resurrection of the failed Extended Validation Certificate standard. There is also a proposal for BIMI data be used in generating DKIM signatures for e-mails.
Mail service providers cache BIMI records and images to reduce network traffic and processing time. But, do not expect your logo to starting showing up immediately in e-mail clients that support BIMI. Even if test tools confirm that your BIMI configuration is correct, it may take months for your BIMI data to be cached. It could take longer if your domain does not send a lot of e-mail. Caching BIMI data could be the downfall of the standard since cache size and management could quickly get out of hand if BIMI becomes popular.
To implement BIMI in its simplest form, you need:
- An SPF record for your domain.
- DKIM e-mail signing must be set up for your domain.
- A valid DMARC DNS record for your domain with a policy of either quarantine or reject. For example:
_dmarc TXT "v=DMARC1; p=quarantine;"
- An exact square logo for your brand/web-site/company in SVG Tiny Portable/Secure format (a more secure subset of the SVG Tiny 1.2 format, and still a draft standard).
- A DNS TXT record for your domain to provide a BIMI record with the URI location of the SVG file. The only supported transport for the SVG URI is HTTPS. The BIMI DNS record is in the following format:
default._bimi TXT "v=BIMI1; l=https://mydomain.com/logo.svg;"
The draft standard has a proposal for BIMI selectors so that e-mail campaigns can specify one of several logos to be displayed alongside the e-mail by adding a BIMI-Selector: header to email being sent. In this case, the default in default._bimi of the DNS TXT record would be replaced with a different selector name. Not specifying a selector in the e-mail headers would result in the default logo being selected. Specifying selectors might look like the following TXT records:
default._bimi TXT "v=BIMI1; l=https://mydomain.com/logo.svg;" promos._bimi TXT "v=BIMI1; l=https://mydomain.com/promos-logo.svg;" helpdesk._bimi TXT "v=BIMI1; l=https://mydomain.com/helpdesk-logo.svg;"
A Trust Authority, like VMC, can be specified to authenticate the ownership of the logo, by adding the a= parameter to the DNS TXT record. This part of the standard is not clear yet, and is currently optional, so it is best to leave it out.
Specifying a=;, or leaving the parameter out of the TXT record, or specifying a=self; all indicate non-participation in authenticating the logo. In the future, not providing a trust authority, or self validating, might result in your logo not being displayed however.
The a= Trust Authority parameter might specify the URI for a certificate, or the URI for an API where Trust Authority data can be retrieved, or a hash value of the SVG file. Using the Trust Authority parameter might look like any of the following TXT records, but this isn’t clearly defined yet:
default._bimi TXT "v=BIMI1; l=https://mydomain.com/logo.svg; a=;" secondary._bimi TXT "v=BIMI1; l=https://mydomain.com/secondary-logo.svg; a=self;" promos._bimi TXT "v=BIMI1; l=https://mydomain.com/promos-logo.svg; a=https://registar.com/vmc/mydomain/promos.pem;" helpdesk._bimi TXT "v=BIMI1; l=https://mydomain.com/helpdesk-logo.svg; a=https://mydomain.com/api/get-pem?helpdesk;" service._bimi TXT "v=BIMI1; l=https://mydomain.com/service-logo.svg; a=3fde56e60e62a2fc9271225c69353d15;"
- More detailed information is available in the BIMI Group Implementation Guide.
- You can test your implementation using the BIMI Group’s LookUp & Generator Tool.
- You can convert your SVG logo to SVG Tiny Portable/Secure format with these free tools.
- Domain Registrars will no doubt push for requiring a Verified Mark Certificate. Extended Validation Certificates were a failed standard and web browsers have stopped displaying any special indicators for web sites with an EVC. VMCs have the same verification requirements as EVCs, plus a requirement that your logo have a registered trademark with the US Patent and Trademark Office. No other country’s trademarks are proposed to be accepted. US domain registrars seem to have forgotten that the internet is world-wide, and most of it exists outside the United States. The pricey and months-long VMC validation process might slow down e-mail spoofers. But it is just as likely to create an unfair advantage for large corporations, and result in most businesses not bothering to adopt BIMI due to the time and expense involved.