Brand Indicators for Message Identification

Brand Indicators for Message Identification (BIMI) is an emerging industry standard that will allow email receivers to display brand logos in user agents alongside DMARC authenticated messages. Email receivers can display BIMI brand logos only for senders whose domains have implemented DMARC quarantine or reject policies. The idea is to associate brand recognition with DMARC authentication.

Like DMARC (and SPF and DKIM), BIMI instructions are added to a domain's DNS records. DMARC Protection simplifies the creation of BIMI instructions for one or more domains by providing a workflow with validation. If Agari hosts your BIMI records, DMARC Protection also automates the management of the logos being displayed.

The RFC for Brand Indicators for Message Identification is currently (as of mid 2019) in draft state with the IETF (Internet Engineering Task Force), which you can read at https://datatracker.ietf.org/doc/draft-blank-ietf-bimi/. However, it is both thorough and specific and is already being adopted. This draft specifies the BIMI mechanism as follows:

  • Domain owners publish brand indicator assertions for domains via DNS.
  • Then, for any message received by a mail receiver:
    1. Receivers authenticate the messages using DMARC, as well as internal reputation indices and other proprietary authentication mechanisms they wish to apply.
    2. The receiver queries the DNS for a corresponding BIMI record and proof of indicator validation.
    3. If both the email and the logo authenticate, then the receiver adds a header to the message, which can be used by the MUA (mail user agent) to determine the domain owner’s preferred brand indicator.
  • The MUA retrieves and displays the brand indicator as appropriate based on its policy and user interface.

    • The proof of indicator validation is provided by a Mark Verified Certificate.

    BIMI Record Syntax

    BIMI records (assertion records) are DNS TXT records in subdomains named _bimi and follow the tag-value syntax for DNS-based key records. BIMI records are constructed with the following tags:

    Tag Description Value(s) Notes
    v= Version. BIMI1 This tag is required. 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.
    a= BIMI trust authorities.
    • self
    • cert
    • mva

    NOTE: These options are not yet available and the a= tag should be left blank (as a=) or not included.

    This tag is optional and takes one of the three values. The values represent:

    • self - No validation option (the same as omitting the tag).
    • cert - An https URL to a Mark Verified Certificate that can be used to validate the indicator.
    • mva - An https URL to an API endpoint that can be queried for validation information.
    l= URL(s) to image resource(s). http URL

    This tag is required, but its value may be empty. The tag is a lowercase "L." The image resource must be an SVG (scalable vector graphics) file. The protocol must be https.

    The graphic file should conform to:

    • Square
    • SVG
    • White/transparent background
    • Logo/mark centered and as large as possible in the space
    • Iconography instead of text

    An example BIMI record:

    v=BIMI1; a=; l=https://www.mycompany.com/bimi/brandlogo.svg;

    A BIMI record can be used to indicate refusal. From the recommendation:

    If both the “a” and “l” tags are 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, this allows a subdomain to decline participation when its organizational domain has default Indicators available. Furthermore, messages sent using a selector that has declined to publish will not show an Indicator while messages with other selectors would display normally.

    An explicit declination to publish looks like:

    v=BIMI1; a=; l=;

    NOTE: The BIMI record syntax is exact, including capitalization. Mail receivers are not allowed to attempt fixing syntax or capitalization errors in BIMI records. Missing required tags are errors. Records that do not start with a v= tag, or that start with a v= tag that does not identify the current BIMI version must be discarded.

    BIMI Implementation

    While the recommendation is rigid in how BIMI DNS records are formed, it is flexible in how BIMI can be implemented. Domain owners can ask that receivers display brand indicators, but receivers have the option to display them or not, or even to display alternate indicators. From the recommendation:

    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. However, 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.

    The BIMI record should be published in a zone named default._bimi, located directly under the second-level domain. For example, if the desired second-level domain is foo.com, the BIMI TXT record for that domain would be published at default._bimi.foo.com.