What Is BIMI? Brand Logos in the Inbox, DMARC Enforcement and MTA-STS

BIMI (Brand Indicators for Message Identification) is a DNS TXT record, published at default._bimi.yourdomain.com, that lets participating mailbox providers display a verified brand logo next to mail that has already passed DMARC. It adds no authentication of its own and requires DMARC at quarantine or reject first. Once DMARC is enforced, BIMI and MTA-STS are two records a domain commonly adds next: one for recognition in the inbox, one for encryption on the wire.

What is BIMI, and what it is not: a recognition signal, not a security check

BIMI is a way for a domain owner to point mailbox providers at a logo, and for the provider to show that logo only when the message has already authenticated under DMARC. The IETF draft says so in its overview: BIMI relies on existing authentication protocols and is not a new authentication protocol itself (draft-14, section 2).

The provider keeps the final say: section 4.1 gives mail clients final control over the user interface, including showing no indicator at all.

The BIMI DMARC requirements, stated precisely

BIMI requires a DMARC policy at quarantine or reject, applied to the whole mail stream, on both the domain in the From header and its organizational domain. The receiver-side rules are in section 7.1 of the IETF draft.

The organizational-domain rule catches a common setup: news.example.com at p=reject while example.com is still at p=none fails the organizational-domain check. The BIMI Group's implementation guide states the same requirement from the sender's side.

DMARC passes on either aligned SPF or aligned DKIM, so a working DKIM signature on the organizational domain is in practice part of the BIMI prerequisite. The companion posts on what DKIM is and how SPF, DKIM and DMARC work together cover the alignment rules.

How a BIMI record is built: the default._bimi name and the v, l and a tags

A BIMI record is a single TXT record at <selector>._bimi.<domain>, where the selector is default unless a message names another one, and it carries at most a handful of tags. A record with a certificate looks like this:

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

Section 4.3.1 adds that a record with both l= and a= empty is an explicit refusal to participate. The draft admits only SVG and SVGZ in l= and defers further restrictions to other documents; the BIMI Group's SVG Tiny PS profile is where those live.

BIMI logo requirements: SVG Tiny PS, square, solid background, 32 KB

The BIMI logo must be an SVG file in the SVG Tiny Portable/Secure (Tiny PS) profile, served over HTTPS, and the BIMI Group's guidance on creating the file sets these constraints:

• The <svg> root carries a baseProfile of tiny-ps and a version of 1.2, and includes a <title> element.
• The image should be a square aspect ratio, with the artwork centered.
• The background should be a solid color; transparent backgrounds may not display as expected.
• The file should be as small as possible and should not exceed 32 kilobytes.
• No scripts, animation or interactive elements, no external links or references beyond the XML namespaces, and no x= or y= attributes on the root element.

The BIMI Group sets no required pixel size, though its sender FAQ advises testing recognizability at 20 to 40 pixels; it also publishes conversion tools, because a standard SVG export often fails the profile.

Verified Mark Certificates, Common Mark Certificates and which providers require them

A Verified Mark Certificate (VMC) or Common Mark Certificate (CMC) is the authority evidence named in the a= tag: a certificate stating that an independent Mark Verifying Authority has confirmed the domain owner's rights to the logo. The BIMI Group's implementation guide describes VMCs as based on registered trademarks of the logo, and CMCs as used in place of trademarked logos; its sender FAQ says registered trademarks are typically accepted and some issuers may accept other legally protected marks.

The BIMI Group lists three issuers, DigiCert, GlobalSign and SSL.com, and notes that a listed certificate is no guarantee a provider will honor it.

Which providers require one is stated in the BIMI Group's sender FAQ: some, with Yahoo as the example, accept a self-asserted record and may display the logo without a certificate; others, with Gmail and Apple as the examples, require a VMC. The BIMI Group's support infographic lists Apple, Google, Yahoo, Fastmail, Zoho Mail and others as supporting providers, and shows Microsoft as not supporting BIMI.

Whether BIMI is worth doing: a modest branding gain and a larger forced security gain

BIMI is worth doing when a domain already has DMARC at enforcement and the certificate cost is acceptable; it is rarely the right first project for a domain that does not. The BIMI Group's own FAQ describes the logo as a signal that can improve recognition and engagement rather than a guarantee of trust.

The anti-phishing value is indirect. A logo does nothing to a spoofed message, and the draft's security considerations (section 8.2) note that BIMI alone cannot prevent lookalike-domain misuse and expect receivers to apply reputation, allowlists or heuristics before displaying an indicator. What BIMI does do is force DMARC to quarantine or reject on the sending domain and its organizational domain, with no sp=none. For many domains that enforcement step is the real security outcome, and it costs nothing beyond the DMARC work itself.

The main barrier is the certificate. A common sequence is to publish a self-asserted record first, which costs nothing beyond the SVG work and which the BIMI Group's guide notes has limited provider support, and add the certificate when the budget exists.

MTA-STS: the other record a domain adds after DMARC enforcement

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461, September 2018) lets a receiving domain declare that mail sent to it must arrive over TLS, to MX hosts it names, with a valid certificate. SPF, DKIM and DMARC say nothing about whether the connection was encrypted; without MTA-STS, SMTP TLS is opportunistic.

RFC 8461 section 1 names the two attacks that leaves open: stripping the STARTTLS offer to downgrade the session to plaintext, and redirecting the session, for example by overwriting the resolved MX record.

MTA-STS has two parts. The DNS record is a TXT entry at _mta-sts.<domain> with two fields (section 3.1): v=STSv1 and an id, a short string senders use to detect that the policy changed.

_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20260920120000Z"

The policy is a plain-text file served over HTTPS at https://mta-sts.<domain>/.well-known/mta-sts.txt (section 3.2). Its fields are version (only STSv1), mode, one mx line per allowed MX host (a leading wildcard covers one label), and max_age, the seconds senders cache the policy, capped at 31557600 and expected to be weeks or greater once stable.

version: STSv1
mode: testing
mx: mail.example.com
mx: *.example.net
max_age: 604800

A sending server that honors MTA-STS checks that the MX host matches an mx line and presents a valid certificate for that name (sections 4.1 and 4.2); what happens on failure depends on the mode (section 5).

TLSRPT (RFC 8460) is the feedback channel: a TXT record at _smtp._tls.<domain> with v=TLSRPTv1 and a rua= address (section 3) asks senders to deliver aggregate reports of TLS failures (section 4) by email or HTTPS POST (section 5).

The staged rollout is: publish TLSRPT, publish the policy in testing with a modest max_age (RFC 8461's example uses 15 days), read the reports until every MX host validates, then switch to enforce and lengthen max_age. Change the id on every policy update so senders refetch it.

The order to add BIMI and MTA-STS after DMARC reaches enforcement

Truvo's recommended order puts MTA-STS before BIMI, because it closes a transport gap while BIMI adds a logo.

1. Confirm DMARC is enforced on the sending domain and its organizational domain. p=quarantine or p=reject, no pct below 100, sp not none, and clean aggregate reports.
2. Publish TLSRPT, then MTA-STS in testing mode. Host the policy file over HTTPS, list every MX host, and keep max_age modest while testing.
3. Move MTA-STS to enforce once the TLSRPT reports show every MX host validating, and raise max_age.
4. Prepare the BIMI logo as SVG Tiny PS, host it over HTTPS, and publish a self-asserted record (v=BIMI1; l=...) to reach providers that accept one.
5. Add a VMC or CMC when the budget allows and publish it in the a= tag.

For companies under SOC 2 or ISO 27001 review, Truvo's checkers map DMARC, BIMI and MTA-STS findings to SOC 2 CC6.1, CC6.7 and CC7.2 and to ISO 27001:2022 A.5.14 and A.8.20; the enforced DMARC and MTA-STS policies are the evidence, while BIMI itself is a trust signal rather than a control.

How to check a BIMI record and an MTA-STS record without sending mail

Both records are public DNS entries, so a passive lookup confirms them. The BIMI checker reads the record at default._bimi.<domain>, confirms v=BIMI1, checks that l= points to an HTTPS SVG logo and whether a= names a Verified Mark Certificate, and flags a DMARC policy still at none.

The MTA-STS checker confirms the record at _mta-sts.<domain> carries v=STSv1 and an id; it does not fetch the policy file, which should be tested separately. A DMARC checker shows whether the prerequisite policy is none, quarantine or reject, and the free security tools hub collects the rest of the mail lookups.

Frequently asked questions about BIMI and MTA-STS

What is a BIMI record?

A BIMI record is a DNS TXT record at default._bimi.<domain> containing v=BIMI1, an l= tag with the HTTPS URL of an SVG Tiny PS logo, and optionally an a= tag with the URL of a Verified Mark Certificate or Common Mark Certificate.

Does BIMI require a VMC?

The IETF draft treats the a= tag as optional, so a record without a certificate is valid. Display is up to each provider: the BIMI Group's sender FAQ says some providers, such as Yahoo, accept a self-asserted record, while others, such as Gmail and Apple, require a Verified Mark Certificate.

Does BIMI work with DMARC quarantine?

Yes, provided the policy applies to the whole mail stream. Section 7.1 of the BIMI draft allows p=quarantine only when any pct tag is 100, and requires that neither the From domain nor its organizational domain is at p=none or carries sp=none. p=reject meets the requirement without the pct condition.

What is MTA-STS?

MTA-STS (RFC 8461) lets a receiving domain publish a DNS record and an HTTPS policy file telling sending servers to deliver only over TLS, to the listed MX hosts, with a valid certificate. In enforce mode a compliant sender must not deliver to a host that fails those checks, which blocks STARTTLS downgrade and MX redirection for that hop.

Does BIMI stop phishing?

No. BIMI displays a logo next to mail that has already passed DMARC; it adds no check and blocks nothing. Its indirect contribution is that it requires DMARC at quarantine or reject, and that enforced policy is what stops From-header spoofing of the domain.