Authindicators Working Group T. Loder
Internet-Draft Agari
Intended status: Informational T. Zink
Expires: October 18, 2017 Microsoft
P. Goldstein
S. Blank
April 16, 2017

Brand Indicators for Message Identification (BIMI)


Brand Indicators for Message Identification (BIMI) permits Domain Owners to coordinate with Mail User Agents (MUAs) to display brand-specific Indicators next to properly authenticated messages. There are two aspects of BIMI coordination: a scalable mechanism for Domain Owners to publish their desired indicators, and a mechanism for Mail Transfer Agents (MTAs) to verify the authenticity and reputation of the domain. This document specifies how Domain Owners communicate their desired indicators through the BIMI assertion record in DNS and how that record is to be handled by MTAs and MUAs. The domain verification mechanism and extensions for other mail protocols (IMAP, etc.) are specified in separate documents. By itself BIMI does not impose specific requirements for indicator display on MUAs. BIMI is just a mechanism to support coordination between mail-originating organizations and MUAs. MUAs and mail-receiving organizations are free to define their own policies for indicator display that makes use or not of BIMI data as they see fit.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on October 18, 2017.

Copyright Notice

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

This document defines Brand Indicators for Message Identification (BIMI), which permits Domain Owners to coordinate with Mail User Agents (MUAs) to display brand-specific Indicators next to properly authenticated messages.

Due to the amount of spam and forged email on the internet today, many mail receivers wish to benefit their users by clearly identifying authenticated email. For email-sending organizations, the belief is that clear indicators of their brand is the most effective way to accomplish this. This has in turn led receivers to build closed systems to manage brand indicators.

BIMI is an open system that works at internet scale, so that Domain Owners can coordinate with MUAs to display appropriate Indicators. BIMI has the added benefit of incentivizing Domain Owners to authenticate their email.

The approach taken by BIMI is nearly identical to the approach taken by DKIM, in that BIMI:

This document covers the BIMI mechanism for Domain Owners to publish their desired indicators and how Mail Transfer Agents (MTAs) and MUAs should handle this communication. This document does not cover how domains are verified, how MUAs should display the indicators, or how other protocols (i.e. IMAP) should be extended to work with BIMI. Other documents will cover these topics.

2. Overview

The Sender Policy Framework ([SPF]), DomainKeys Identified Mail ([DKIM]), and Domain-based Message Authentication, Reporting, and Conformance ([DMARC]) provide mechanisms for domain-level authentication for email messages. They enable cooperating email senders and receivers to distinguish messages that are authorized to use the domain name from those that are not. Given that not all senders employ these authentication mechanisms, many Mail User Agents (MUAs) make attempts to indicate to their end users when particular messages are or are not in fact authenticated.

It is currently possible for MUAs to indicate the validity of messages authenticated via these mechanisms through the use of generic visual indicators such as checkmarks if authenticated or questions marks otherwise. But there is a belief that the effectiveness of such generic indicators is limited, and that end users are better served through the use of brand indicators associated with the authenticated sender of the message.

To accomplish this, MUAs need to be able to effectively and meaningfully convey that messages being displayed are both authenticated and originate from a known organization. Brand-specific indicators are believed to be a more effective method of communicating message authenticity to end users. Thus there is a need for MUAs to have access to brand-specific indicators for a very large number of brands.

Due to this need for brand specific indicators, some mail-receiving organizations have developed closed systems for displaying brand indicators for some select domains. While this enabled these mail-receiving organizations to display brand indicators for a limited subset of messages, this closed approach has significant downsides:

  1. It puts a significant burden on each mail-receiving organization, because they must identify and manage a large database of brand indicators.
  2. Scalability is challenging for closed systems that attempt to capture and maintain complete sets of data across the whole of the Internet.
  3. A lack of uniformity across different mail-receiving organizations - each organization will have its own indicator set, which may or may not agree with those maintained by other organizations for any given domain.
  4. Domain Owners have limited ability to influence the brand indicator for the domain(s) they own, and such ability they do have is likely to require coordination with many mail-receiving organizations.
  5. Many Domain Owners have no ability to participate whatsoever as they do not have the appropriate relationships to coordinate with mail-receiving organizations.
  6. MUAs that are not associated with a particular mail-receiving organization are likely to be disadvantaged, because they are unlikely to receive indicators in a manner optimized for their user interfaces.

This all speaks to the need for a standardized mechanism by which Domain Owners interested in ensuring that their indicators are displayed correctly and appropriately can publish and distribute brand indicators for use by any participating MUA.

BIMI removes the substantial burden of curating and maintaining an indicator database from the MUAs, and allows each brand to manage its own indicators. As an additional benefit, mail-originating organizations are more likely to invest the time and effort to authenticate their email, should that come with the ability to influence how email from the organization is displayed.

The basic structure of BIMI is as follows:

  1. Domain Owners publish brand indicator assertions for domains via the [DNS].
  2. Then, for any message received by a Mail Receiver:

    a. Receivers authenticate the messages using [DMARC] and/or whatever other authentication mechanisms they wish to apply.

    b. If the message authenticates and has sufficient reputation per receiver policy, the receiver queries the DNS for a corresponding BIMI record.

    c. If a BIMI record is present, then the receiver adds a header to the message, which can be used by the MUA to determine the Domain Owner’s preferred brand indicator.
  3. The MUA retrieves and displays the brand indicator as appropriate based on its policy and user interface.

The purpose of this structure is to reduce operational complexity at each step and to consolidate validation and indicator selection into the MTA, so that Domain Owners only need to publish simple rules and MUAs only need simple display logic.

3. Requirements

Specification of BIMI in this document is guided by the following high-level goals, security dependencies, detailed requirements, and items that are documented as out of scope.

3.1. High-Level Goals

BIMI has the following high-level goals:

3.2. Security

Brand indicators are a potential vector for abuse. BIMI creates a relationship between sending organization and Mail Receiver so that the receiver can display appropriately designated indicators if the sending domain is verified and has meaningful reputation with the receiver. Without verification and reputation, there is no way to prevent a bad actor from using’s brand indicators and behaving in a malicious manner. This document does not cover these verification and reputation mechanisms, but BIMI requires them to control abuse.

3.3. Scalability

Scalability is a major issue for systems that need to operate in a system as widely deployed as current SMTP email. For this reason, BIMI seeks to avoid the need for pre-sending agreements between senders and receivers. This preserves the positive aspects of the current email infrastructure.

3.4. Out of Scope

Several topics and issues are specifically out of scope for the initial version of this work. These include the following:

4. Terminology and Definitions

This section defines terms used in the rest of the document.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [KEYWORDS].

Readers are encouraged to be familiar with the contents of [EMAIL-ARCH]. In particular, that document defines various roles in the messaging infrastructure that can appear the same or separate in various contexts. For example, a Domain Owner could, via the messaging mechanisms on which BIMI is based, delegate control over defining preferred brand indicators as the Domain Owner to a third party with another role. This document does not address the distinctions among such roles; the reader is encouraged to become familiar with that material before continuing.

Syntax descriptions use Augmented BNF [ABNF].

4.1. Author Domain

The domain name of the apparent author, as extracted from the RFC5322.From field.

4.2. BIMI Assertion

The mechanism through which a Protocol Client verifies the BIMI Assertion Record and constructs the URI(s) to the requested indicator(s) to be placed in the BIMI-Location header.

4.3. Domain Owner

An entity or organization that owns a DNS domain. The term “owns” here indicates that the entity or organization being referenced holds the registration of that DNS domain. Domain Owners range from complex, globally distributed organizations, to service providers working on behalf of non-technical clients, to individuals responsible for maintaining personal domains. This specification uses this term as analogous to an Administrative Management Domain as defined in [EMAIL-ARCH].

4.4. Indicator

The icon, image, mark, or other graphical representation of the brand. The Indicator is in a common image format with restrictions detailed in the Assertion Record definition [assertion-record-def].

4.5. Mail Receiver

The entity or organization that receives and processes email. Mail Receivers operate one or more Internet-facing Mail Transport Agents (MTAs).

4.6. Mark Asserting Entity (MAE)

A Domain Owner who publishes information via the protocol to facilitate distribution of its indicators in association with messages for which the domain they “own” is the Author Domain.

4.7. Mark Verifying Authority (MVA)

An entity of organization that can provide evidence of verification of indicators asserted by an MAE to Verifying Protocol Clients. The MVA may choose to uphold and confirm the meeting of certain indicator standards (ie. size, trademark, content, etc).

4.8. Mail User Agent (MUA)

An endpoint client that a user (a real human being) uses to access their and read their email.

4.9. Protocol Client

An entity that uses the BIMI protocol to discover and fetch published indicators.

4.10. Verifying Protocol Client

A Protocol Client that uses the optional verification capability to inquire about the verification status of published indicators.

5. BIMI DNS Records

BIMI policies are published by Domain Owners and applied by Protocol Clients.

A Domain Owner advertises BIMI participation of one or more of its domains by adding a DNS TXT record to those domains. In doing so, Domain Owners make specific requests of MUAs regarding the preferred set of indicators to be displayed with messages purporting to be from one of the Domain Owner’s domains.

A Domain Owner may choose not to participate in BIMI. In this case, the Domain Owner simply declines to advertise participation by not publishing any BIMI assertion record.

An MUA implementing the BIMI mechanism SHOULD make a best-effort attempt to adhere to the Domain Owner’s published BIMI policy. But MUAs have final control over the user interface published to their end users, and MAY use alternate indicators than those specified in the BIMI assertion record or no indicator at all.

BIMI’s use of the DNS is driven by BIMI’s use of domain names and the nature of the query it performs. Use of the DNS as the query service has the benefit of reusing an extremely well-established operations, administration, and management infrastructure, rather than creating a new one.

BIMI’s policy payload is intentionally only published via a DNS record and not an email header. This serves four purposes:

  1. There is one and only one mechanism for both simple and complex policies to be published.
  2. Operational complexity is reduced, and MTAs only need to check a single record in a consistent manner to enforce policy.
  3. MTAs that understand their MUAs have more control over which Indicators they choose for those MUAs.
  4. Indicators can be verified and/or cached in advance, so that malicious headers cannot be used as an attack vector.

Per [DNS], a TXT record can comprise several “character-string” objects. BIMI TXT records with multiple strings must be treated in an identical manner to SPF.

5.1. Assertion Record

All Domain Owner BIMI preferences are stored as DNS TXT records in subdomains named “_bimi”. BIMI allows the definition of multiple preferences associated with a single RFC5322.From domain. To distinguish between these different preferences, BIMI uses Section 5.2. Senders advertise which selector to use by specifying it in a BIMI-Selector header [bimi-selector].

For example, the Domain Owner of “” would post BIMI preferences in a TXT record at “”. Similarly, a Mail Receiver wishing to query for BIMI preferences regarding mail with an RFC5322.From Author Domain of “” and a selector “default” would issue a TXT query to the DNS for the subdomain of “”. The DNS-located BIMI preference data will hereafter be called the “BIMI Assertion Record”.

Assertion records are defined precisely, mail receivers MUST NOT attempt to fix syntactical or capitalization errors. If a required tag is missing, it is an error.

BIMI assertion records follow the extensible “tag-value” syntax for DNS-based key records defined in [DKIM].

This section creates a registry for known BIMI tags and registers the initial set defined in this document. Only tags defined in this document or in later extensions, and thus added to that registry, are to be processed; unknown tags MUST be ignored.

The following tags are introduced as the initial valid BIMI tags:

v= Version (plain-text; REQUIRED). Identifies the record retrieved as a BIMI record. It MUST have the value of “BIMI1” for implementations compliant with this version of BIMI. The value of this tag MUST match precisely; if it does not or it is absent, the entire retrieved record MUST be ignored. It MUST be the first tag in the list.


….bimi-version = %x76 *WSP “=” *WSP %x42.49.4d.49 1DIGIT

a= Trust Authorities (plain-text; OPTIONAL). A reserved value.


….bimi-authorities = %x61 *WSP “=” [bimi-location-uri]

f= Supported Image Formats (comma-separated plain-text list of values; OPTIONAL; default is “png”). Comma-separated list of three or four character filename extensions denoting the available file formats. Supported raster formats are TIFF (tiff, tif), PNG (png), and JPEG (jpg, jpeg). Supported vector formats are SVG (svg).


….bimi-format-ext = [FWS] 3*4(ALPHA / DIGIT) [FWS]

….bimi-formats = %x66 *WSP “=” bimi-format-ext *(“,” bimi-format-ext) [”,”]

l= locations (URI; REQUIRED). The value of this tag is a comma separated list of base URLs representing the location of the brand indicator files. All clients MUST support use of at least 2 location URIs, used in order. Clients MAY support more locations. Initially the supported transport is HTTPS only.


….bimi-location-uri = [FWS] URI [FWS]

….; “URI” is imported from [URI]

….; commas (ASCII ; 0x2C) MUST be encoded

….bimi-locations = %x6c *WSP “=” bimi-location-uri *(“,” bimi-location-uri) [”,”]

z= List of supported image sizes (comma-separated plain-text list of values; OPTIONAL). A comma separated list of available image dimensions, written in the form “WxH”, with width W and height H specified in pixels. Example: a image dimension listed as “512x512” implies a 1x1 aspect ratio image (square) of 512 pixels on a side. The minimum size of any dimension is 32. The maximum is 1024. If the tag is missing or has an empty value, there is no default image dimension. This lets a Domain Owner broadcast intent that no Indicator should be used. (See below.)


….bimi-dimension = [FWS] 2*4DIGIT [FWS]

….; min 32

….; max 1024

….bimi-size = bimi-dimension “x” bimi-dimension

….bimi-size-list = bimi-size *(“,” bimi-size) [”,”]

….bimi-image-sizes = %x7a *WSP “=” [bimi-size-list]

Therefore, the formal definition of the BIMI Assertion Record, using [ABNF], is as follows:

….bimi-sep = *WSP %x3b *WSP

….bimi-record = bimi-version (bimi-sep bimi-locations) [bimi-sep bimi-formats] [bimi-sep bimi-image-sizes] [bimi-sep]

….; components other than bimi-version

….; may appear in any order

5.1.1. An empty “z” tag

If the “z” tag is empty, it is an explicit refusal to participate in BIMI. This is critically different than not publishing a BIMI record in the first place. For example, an empty z= tag allows a subdomain to decline participation when its organizational domain has default Indicators available. Also, an empty z= tag in a selector would allow messages sent with this selector to decline the use of Indicators while messages with other selectors would display normally.

5.1.2. The “z” tag for vector formats

The “z” tag is defined as “WxH” which does not translate cleanly when using vector formats (SVG for this document). If a vector format is specified, and there are multiple z= values, then for each aspect ratio, an MTA SHOULD treat the smallest z value as the “small” vector graphic (for example, for thumbnails or mobile), and the largest z value as the “large” vector graphic. Any other z values should be ignored in conjunction with vector formats.

5.2. Selectors

To support multiple brand indicators per domain, the brand indicator namespace is subdivided for the publishing of multiple Assertion Records using “selectors”. Selectors allow the Domain Owner to better target the brand indicator by type of recipient, message source, or other considerations like seasonal branding. BIMI selectors are modeled after DKIM selectors.

The selector “default” is the default Assertion Record. Domain Owners can specify which other selector to use on a per-message basis by utilizing the BIMI-Selector Header [bimi-selector].

Periods are allowed in selectors and are component separators. When BIMI Assertion Records are retrieved from the DNS, periods in selectors define DNS label boundaries in a manner similar to the conventional use in domain names. In a DNS implementation, this can be used to allow delegation of a portion of the selector namespace.


….selector = sub-domain *( “.” sub-domain )

….; from [SMTP] Domain,

….; excluding address-literal

The number of selectors for each domain is determined by the Domain Owner. Many Domain Owners will be satisfied with just one selector, whereas organizations with more complex branding requirements can choose to manage disparate selectors. BIMI sets no maximum limit on the number of selectors.

6. BIMI Header Fields

Once BIMI policies are published in DNS via Assertion Records, additional guidance can be provided from Domain Owners to Mail Receivers, and Mail Receivers to their MUAs through the use of additional BIMI header fields.

BIMI header fields are case insensitive. If a required tag is missing, it is an error.

6.1. BIMI-Selector

BIMI DNS records are placed in <selector>._bimi.<domain>, and by default they are placed in default._bimi.<domain>. That is, for, the default location for all BIMI lookups is However, a Domain Owner may specify the selector using the RFC 5322 header ‘BIMI-Selector’. The BIMI-Selector header consists of key value pairs:

v= Version (plain-text; REQUIRED). The version of BIMI. It MUST have the value of “BIMI1” for implementations compliant with this version of BIMI. The value of this tag MUST match precisely; if it does not or it is absent, the entire retrieved record MUST be ignored. It MUST be the first tag in the list.


….bimi-header-version = “v” *WSP “=” *WSP “BIMI” 1DIGIT

s= Selector (plain-text; REQUIRED). The location of the BIMI DNS record, when combined with the RFC5322.From domain.


….bimi-selector = “s” *WSP “=” *WSP selector

And the formal definition of the BIMI Selector Header, using ABNF, is as follows:

….bimi-selector-header = bimi-header-version bimi-sep bimi-selector [bimi-sep]

6.2. BIMI-Location

BIMI-Location is the header a Mail Receiver inserts that tells the MUA where to get the BIMI indicator from. This is formed by combining the ‘l’ and ‘z’ values from the BIMI DNS record.

The syntax of the header is as following:

v= Version (plain-text; REQUIRED). The version of BIMI. It MUST have the value of “BIMI1” for implementations compliant with this version of BIMI. The value of this tag MUST match precisely; if it does not or it is absent, the entire retrieved record MUST be ignored. It MUST be the first tag in the list.

….The ABNF for bimi-header-version is imported exactly from the BIMI Selector Header [bimi-selector].

l: location of the BIMI indicator (URI; REQUIRED). Inserted by the MTA after parsing through the BIMI DNS record and performing the required checks. The value of this tag is a comma separated list of URLs representing the location of the brand indicator files. All clients MUST support use of at least 2 location URIs, used in order. Clients MAY support more locations. Initially the supported transport supported is HTTPS only.


….bimi-header-locations = “l” *WSP “=” bimi-location-uri *(“,” bimi-location-uri) [”,”]

And the formal definition of the BIMI Location Header, using ABNF, is as follows:

….bimi-location-header = bimi-header-version bimi-sep bimi-header-locations [bimi-sep]

6.3. Header Signing

The BIMI-Selector SHOULD be signed by DKIM, or it MAY be sufficient if the message passes SPF/DMARC alignment or some other email authentication mechanism that does not rely on DKIM but satisfies Receiver policy. Some MTAs will require DKIM/DMARC alignment, while others will only require SPF/DMARC alignment. Some receivers will require the domain to publish a DMARC record of p=quarantine or p=reject, while some receivers may only require alignment, absent a strong DMARC policy. BIMI leaves these decisions up to the mail receivers.

The BIMI-Location header MUST NOT be DKIM signed. This header is untrusted by definition, and is only for use between an MTA and its MUAs, after DKIM has been validated by the MTA. Therefore, signing this header is meaningless, and any messages with it signed are either coming from malicious or misconfigured third parties.

7. Domain Owner Actions

This section includes a walk through of the actions a Domain Owner takes when setting up Assertion Records and sending email messages.

7.1. Determine and publish Indicator(s) for use

Domain Owners should consider which Indicator file formats to choose when setting up their BIMI Assertion Records. Vector image formats (SVG for this document) have some advantages over raster formats, and vice versa. As a Sender, BIMI provides control over which Indicators are chosen for display, but not the ultimate manner in which the MUA will display the image.

Therefore, for any given Indicator, it is RECOMMENDED to provide several different versions (sizes, aspect ratios, and file types) of each Indicator so that the MUA may choose the most appropriate one for its layout.

Then publish these Indicator options somewhere world readable.

If publishing both vector and raster Indicators in the same Assertion Record, for each aspect ratio, only the smallest and largest z= size values will be used for vector Indicator retrieval, and those will be considered small and large vector Indicators respectively.

BIMI allows multiple comma separated l= values in the Assertion Record, so that a Domain Owner may publish the same Indicators in multiple world readable locations. This is so Indicators may still be available if there are service or DNS issues for a particular l= value.

7.2. Specify Domain Owner Preference

A Domain Owner’s preference is specified through the ordering of the l, z, and f tags in the Assertion Record. For example, if both png and jpeg indicators are specified, and the Domain Owner wishes the jpeg to have precedence, then the f= tag should specify jpeg first. Mail Receivers SHOULD respect the ordering in these tags as representative of Domain Owner preference.

This does not guarantee that the first tags specified will be selected as there may be DNS errors, or some clients may not support all formats. However, on average, the first tags specified SHOULD be used to construct the indicator passed to the MUA.

7.3. Publish Assertion Records

For each set of Indicators and domains, publish the appropriate Assertion Record as either “default” or a named selector as a DNS TXT record within the appropriate “_bimi” namespace.

7.4. Manage multiple uses of the same Indicator(s) within a trust boundary

For Domain Owners with multiple domains that wish to share the same set of Indicators within a trust boundary and only manage those Indicators from a single DNS location, it is RECOMMENDED to use DNS CNAMEs.

Using a CNAME here is functionally similar to the SPF redirect modifier. Since BIMI does not require l= tags to be aligned to the Author Domain, CNAMEs present a cleaner solution than extending the protocol.

7.5. Set the headers on outgoing email as appropriate

Once a default Assertion Record has been published for an Author Domain, all emails from this domain should display the appropriate Indicator in participating MUAs.

If a non-default Indicator is desired, the BIMI-Selector header should be set appropriately. If for some reason this selector cannot be accessed by the Protocol Client, the fallback is the default Assertion Record on the Organization domain.

The BIMI-Location header MUST NOT be set by email senders, and Protocol Clients MUST ignore it.

8. Receiver Actions

This section includes a walk through of the actions a Protocol Client takes when evaluating an email message for BIMI Assertion.

8.1. Indicator Discovery

Through the BIMI Assertion Record [assertion-record-def], the BIMI mechanism uses DNS TXT records to advertise preferences. Preference discovery is accomplished via a method similar to the method used for [DMARC] records. This method, and the important differences between BIMI and [DMARC] mechanisms, are discussed below.

Indicator Discovery MUST only be attempted if the message authenticates per Receiver policy.

To balance the conflicting requirements of supporting wildcarding, allowing subdomain policy overrides, and limiting DNS query load, Protocol Clients SHOULD employ the following lookup scheme for the appropriate BIMI record for the message:

  1. Start with the DNS domain found in the RFC5322.From header in the message. Define this DNS domain as the Author Domain.
  2. If the message for which the indicator is being determined specifies a selector value in the BIMI Selector Header [bimi-selector], use this value for the selector. Otherwise the value ‘default’ MUST be used for the selector.
  3. Clients MUST query the DNS for a BIMI TXT record at the DNS domain constructed by concatenating the selector, the string ‘_bimi’, and the Author Domain. A possibly empty set of records is returned.
  4. Records that do not start with a “v=” tag that identifies the current version of BIMI MUST be discarded.
  5. If the set is now empty, the Client MUST query the DNS for a BIMI TXT record at the DNS domain constructed by concatenating the selector ‘default’, the string ‘_bimi’, and the Organizational Domain (as defined in [DMARC]) corresponding to the Author Domain. A custom selector that does not exist falls back to default._bimi.<organizationalDomain>, and NOT <selector>._bimi.<organizationalDomain>. A possibly empty set of records is returned.
  6. Records that do not start with a “v=” tag that identifies the current version of BIMI MUST be discarded.
  7. If the remaining set contains multiple records or no records, indicator discovery terminates and BIMI processing MUST NOT be performed for this message.
  8. If the remaining set contains only a single record, this record is used for BIMI Assertion.

8.2. Stamp BIMI status in Authentication Results

Upon completion of Indicator Discovery, an MTA SHOULD stamp the result in the Authentication-Results header using the following syntax, with the following key=value pairs:

bimi: Result of the bimi lookup (plain-text; REQUIRED). Range of values are ‘pass’ (BIMI successfully validated), ‘none’ (no BIMI record present), ‘fail’ (syntax error in the BIMI record, or some other error), ‘temperror’ (DNS lookup problem), or ‘skipped’ (BIMI check did not perform, possibly because the message did not comply with the minimum requirements such as passing DMARC, or the MTA does not trust the sending domain). The MTA MAY put comments in parentheses after bimi result, e.g., bimi=skipped (sender not trusted) or bimi=skipped (message failed DMARC).

header.d: Domain used in a successful BIMI lookup (plain-text; REQUIRED if bimi=pass). If the first lookup fails for whatever reason, and the second one passes (e.g., using the organizational domain), the organizational domain should appear here. If both fail (or have no record), then the first domain appears here.

selector: Selector used in a successful BIMI lookup (plain-text; REQUIRED if bimi=pass). Range of values include the value in the BIMI-Selector header, and ‘default’. If the first lookup fails (or has no record) and second passes, the second selector should appear here. If both fail (or have no record), then the first selector should appear here.

8.3. Handle Existing BIMI-Location Headers

Regardless of success of the BIMI lookup, if the BIMI-Location header already exists it MUST be either removed or renamed.

This is because the MTA doing BIMI Assertion is the only entity allowed to specify the BIMI-Location header, and allowing any existing header through is a security risk.

Additionally, at this point, if the original email message had a DKIM signature, it has already been evaluated. Removing the header at this point should not break DKIM, especially because this header should not be signed per this spec.

8.4. Construct BIMI-Location URI(s)

The l= value of the BIMI-Location header is a comma separated list of URIs to Indicators the MTA believes are most applicable to its MUAs. From the options provided by the Assertion Record, MTAs SHOULD choose the Indicators to include based on Receiver policy for optimal performance and user experience for its MUAs from the.

The URIs in the list are created from the exact concatenation of the l= and appropriate z= and then f= tags from the BIMI Assertion Record. Concatenation MUST be exact, and a trailing slash MUST NOT be added to the l= tag from the BIMI Assertion Record. A period MUST be used for the concatenation of the z= and f= tags.

….INFORMATIONAL: The reason the concatenation must be exact and a trailing slash must not be added, is if concatenation required a trailing slash, that would create the operational overhead of requiring all indicators for all selectors to potentially require subdirectories of their own on servers hosting the indicators, which is not a requirement for Domain Owners that BIMI seeks to establish.

MTAs MAY add as many comma separated URIs to the l= tag in the BIMI-Location header as they wish, MUAs MUST support at least 2 location URIs in the header, and MAY support more.

8.5. Set appropriate flags on the mail store

Once an MTA has finished BIMI Assertion, it needs to deposit the email somewhere where the user can eventually access it with an MUA. Users typically access their email on mail stores through either POP3, IMAP, and MAPI. Separate documents will define protocol-specific BIMI extensions for mail stores.

If a mail store is BIMI-compliant, the MTA SHOULD set a flag on the message when depositing in the mail store. This is to communicate between the MTA and its MUA that the BIMI-Location header was set locally and can be trusted.

If an MUA has a BIMI-compliant mail store, and no appropriate flag is set, the MUA SHOULD ignore the BIMI-Location header.

If a mail store ingests a message from another mail store through some other means, the ingesting mail store may or may not set the protocol-specific BIMI flag when it pulls down the relayed message. If it trusts the other mail store, it may simply set the same flag. Or, it may perform BIMI Assertion from scratch, create or replace the BIMI-Location header, and set its own flag appropriately. Or, it may simply choose not to set the flag at all.

9. Security Considerations

The consistent use of brand indicators is valuable for Domain Owners, Mail Receivers, and End Users. However, this also creates room for abuse, especially for determined malicious actors.

9.1. Lookalike Domains and Copycat Indicators

Publishing BIMI records is not sufficient for an MTA to signal to the MUA to load the BIMI indicator. Instead, the Domain Owner should have a good reputation with the MTA. Thus, BIMI display requires passing BIMI, and passing email authentication checks, and having a good reputation at the receiver. The receiver may use a manually maintained list of large brands, or it may import a list from a third party of good domains, or it may apply its own reputation heuristics before deciding whether or not to load the BIMI indicator.

9.2. Large files and buffer overflows

The MTA or MUA should perform some basic analysis and avoid loading indicators that are too large or too small. The Receiver may choose to maintain a manual list and do the inspection of its list offline so it doesn’t have to do it at time-of-scan.

9.3. Slow DNS queries

All email Receivers already have to query for DNS records, and all of them have built-in timeouts when performing DNS queries. Furthermore, the use of caching when loading images can help cut down on load time. Virtually all email clients have some sort of image-downloading built-in and make decisions when to load or not load images.

9.4. Unaligned indicators and asserting domains

There is no guarantee that a group responsible for managing brand indicators will have access to put these indicators directly in any specific location of a domain, and requiring that indicators live on the asserted domain is too high a bar. Additionally, letting a brand have indicator locations outside its domain may be desirable so that someone sending legitimate authenticated email on the Domain Owner’s behalf can manage and set selectors as an authorized third party without requiring access to the Domain Owner’s DNS or web services.

9.5. Unsigned BIMI-Selector Header

If a Domain Owner relies on SPF but not DKIM for email authentication, then adding a requirement of DKIM may create too high of a bar for that sender. On the other hand, Receivers doing BIMI assertion may factor in the lack of DKIM signing when deciding whether to add a BIMI-Location header.

9.6. CGI scripts in Indicator payload

MTAs and MVAs should aggressively police Indicators to ensure they are the Indicators they claim to be, are within appropriate size limits, and pass other sanity checks. Additionally, MTAs might cache good Indicators and serve them directly to their MUAs, which would in practice bypass any malicious dynamic payload set to trigger against an end user but not an MTA.

9.7. Metadata in Indicators

Domain Owners should be careful to strip any metadata out of published Indicators that they don’t want to expose or which might bloat file size. MTAs and MVAs might wish to inspect and remove such data from Indicators before exposing them to end users.

10. IANA Considerations

IANA will need to reserve two new entries to the “Permanent Message Header Field Names” registry.

Header field name: BIMI-Selector

Applicable protocol: mail

Status: standard

Author/Change controller: IETF

Specification document: This one

Header field name: BIMI-Location

Applicable protocol: mail

Status: standard

Author/Change controller: IETF

Specification document: This one

11. Normative References

[ABNF] Overell, Crocker,., "Augmented BNF for Syntax Specifications: ABNF", January 2008.
[Authentication-Results] Kucherawy, M, ., "Message Header Field for Indicating Message Authentication Status", August 2015.
[DKIM] Kucherawy, Ed, Crocker,., "DomainKeys Identified Mail (DKIM) Signatures", September 2011.
[DMARC] Zwicky, Ed, Kucherawy,., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", March 2015.
[DNS] Mockapetris, P, ., "Domain names - implementation and specification", November 1987.
[EMAIL-ARCH] Crocker, D, ., "Internet Mail Architecture", July 2009.
[KEYWORDS] Bradner, S, ., "Key words for use in RFCs to Indicate Requirement Levels", March 1997.
[SMTP] Klensin, J, ., "Simple Mail Transfer Protocol", October 2008.
[SPF] Kitterman, S, ., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", April 2014.
[URI] Masinter, Berners-Lee,., "Uniform Resource Identifier (URI): Generic Syntax", January 2005.

Appendix A. Example Selector Discovery (INFORMATIVE)

This section shows several examples of how a receiving MTA should determine which Assertion Record to use depending on the BIMI-Selector header.

A.1. No BIMI-Selector Header

The domain does not send with a BIMI-Selector header.


The MTA would lookup for the BIMI DNS record.

A.2. With BIMI-Selector Header

The domain sends with a BIMI-Selector header:

BIMI-Selector: v=BIMI1; s=selector;

The MTA would lookup

A.3. MISSING EXAMPLE - TZINK WHAT WAS IT - Malformed header?


A.4. Invalid BIMI-Selector Header

The domain sends with a BIMI-Selector header, but does not include the required field ‘v=’:

BIMI-Selector: s=selector;

The MTA would ignore this header, and lookup

Appendix B. Example Authentication-Results stamps (INFORMATIONAL)

This section shows example Authentication-Results stamps based on different BIMI lookup statuses.

B.1. Successful BIMI lookup

BIMI-Selector: v=BIMI1; s=selector;
Authentication-Results: bimi=pass selector=selector;

B.2. No BIMI record

Authentication-Results: bimi=none;

In this example, does not have a BIMI record at, nor does

B.3. Subdomain has no default record, but organizational domain does

Authentication-Results: bimi=pass selector=default;

B.4. Subdomain has no record for selector, but organization domain has a default

BIMI-Selector: v=BIMI1; s=selector;
Authentication-Results: bimi=pass selector=default;

In this example, the sender specified a DNS record at but it did not exist. The fallback is to use, not even if that record exists.

Appendix C. Example Indicator Selection (INFORMATIONAL)

A Domain Owner may have multiple BIMI indicators for the MUA to select from, and they are permitted to publish all of them in a BIMI DNS record. To pick between them:

C.1. Simple Indicator Selection

Look up the Assertion Record for the Author Domain and selector which tells the location of the suggested Indicators: IN TXT "v=bimi1; f=png; z=512x512; l="

Here, the Domain Owner has only published a single Indicator. The location is the z= tag with the f= tag extension, e.g.,

C.2. Indicator preferences and precedence

The MTA can check the various file at the remote location in any order, but SHOULD give precedence to the order in which they are listed. For example, if the following record were published: IN TXT "v=bimi1; f=png,tif,jpg; z=256x256,512x512; l="

This means that there are at least six different files. They will be prioritized by taking the first z= tag and appending all the f= extensions, then taking the next z= tag and appending the f= extensions:

It is NOT done this way (interweaving the sizes):

C.3. Indicator preference and precedence with vector formats

For example, if the following record were published: IN TXT "v=bimi1; f=png,svg; z=256x256,512x512,1024x1024; l="

This means that there are at least six different files. They will be prioritized by taking the first z= tag and appending all the f= extensions, then taking the next z= tag and appending the f= extensions, but only using the smallest and largest z= values for the vector format:

Appendix D. Example BIMI-Location Construction (INFORMATIONAL)

This section shows how an example MTA might evaluate an incoming email for BIMI participation, and how it could share that determination with its MUA(s).

D.1. MTA Receives an email

The MTA receives the following DKIM signed message:

DKIM-Signature: v=1; s=myExample;; h=From;BIMI-Selector;Date;bh=...;b=...
BIMI-Selector: v=BIMI1; s=brand;
Subject: Hi, this is a message from the good folks at Example Learning

D.2. MTA does its authentication checks

The receiving MTA receives the message and performs an SPF verification (which fails), a DKIM verification (which passes), and a DMARC verification (which passes). The domain is verified and has good reputation. The Receiver proceeds to perform a BIMI lookup.

D.3. MTA performs BIMI Assertion

The MTA sees that the message has a BIMI-Selector header, and it is covered by the DKIM-Signature, and the DKIM-Signature that passed DKIM is the one that covers the BIMI-Selector header. The MTA sees the header validates and contains ‘v=BIMI1’, and ‘s=brand’. It performs a DNS query for and retrieves: IN TXT "v=BIMI1; z=64x64,512x512; f=png,jpg; l="

The MTA verifies the syntax of the BIMI DNS record, and it, too passes.

D.4. MTA Stamps Authentication-Results

It stamps the results of the BIMI to the Authentication-Results header:

Authentication-Results: spf=fail;
  dkim=pass (signature was verified);
  dmarc=pass action=none;
  bimi=pass selector=brand;

D.5. MTA Constructs BIMI-Location header

The MTA knows its MUAs are optimized for pngs, and prefer images of 128x128 or larger. It decides to use the first suggested Indicator it finds which matches these requirements first, and the Domain Owner’s first preference second.

Finally, the MTA removes the existing BIMI-Location header, and stamps the new one:

BIMI-Location: v=BIMI1; l=,

That the original sender signed a BIMI-Location header is irrelevant. It was used for DKIM validation and then thrown out by the MTA.

The MTA then sets any relevant BIMI flags on the mail store when it deposits it.

D.6. The MUA displays the indicator

The mail is opened from the mail store in an MUA. The MUA checks to make sure the appropriate BIMI mail store flag has been set, so that it knows it can trust the BIMI-Location header. Finally, the MUA makes a simple determination of which image to show based upon the URI(s) in the BIMI-Location header.

Authors' Addresses

Thede Loder Agari EMail:
Terry Zink Microsoft EMail:
Peter Goldstein ValiMail EMail:
Seth Blank ValiMail EMail: