What is BIMI?

What BIMI does

BIMI (Brand Indicators for Message Identification) lets you publish your logo in DNS so that a mailbox provider can show it next to your messages, in the spot where a sender's initials or a generic avatar would otherwise sit. The BIMI Internet-Draft defines only how you publish the logo and how receivers find it. It leaves the display decision to each provider, so a perfect setup makes your logo eligible, never guaranteed.

BIMI is also a reward for finishing email authentication. A logo is considered only for mail that passes DMARC under a policy that quarantines or rejects failures, which is why it sits at the end of the SPF, DKIM and DMARC work rather than at the start.

Where the logo shows up, according to each provider's own documentation (checked on October 13, 2026):

• Gmail needs a mark certificate: Google's setup guide says the certification must be a Verified Mark Certificate (VMC) or a Common Mark Certificate (CMC), and that Gmail shows a checkmark next to senders verified with a VMC.
• Apple Mail supports BIMI in iOS 16, iPadOS 16 and macOS Ventura 13 or later, and on iCloud.com, according to Apple Support. Apple's guide for mail servers says BIMI works with VMCs and other forms of BIMI Evidence Documents. The VMC is the only certificate type it names.
• Yahoo says on its Sender Hub that it doesn't currently require a VMC, but uses one when the record includes it. It also limits logos to bulk mail from senders with sufficient reputation and engagement.
• The BIMI Group's provider list (last updated May 2025) shows these and other providers, such as Fastmail, LaPoste and Zoho Mail, as supporting BIMI.

The BIMI record

The record is a TXT record at default._bimi.yourdomain.com. The first label is the selector: receivers use default unless the message carries a BIMI-Selector header that names another one, which lets one domain publish more than one logo. A typical record looks like this:

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

• v=BIMI1 is required and must be the first tag.
• l= is the https URL of your logo file.
• a= is the https URL of your mark certificate, a PEM file. It is optional in the draft, but Gmail requires a certificate and Apple's documentation names one, as the section above shows.
• avp= is optional. With avp=personal you ask providers that support personal avatars to show the sender's own avatar instead of your logo; the default is brand.
• lps= is optional and new in draft -14. It lists comma-separated prefixes for the local part of the sender address, the bit before the @. When one matches, receivers look for a record whose selector is that local part, such as news._bimi.example.com, and fall back to this record if there is none. It lets an address pick its own logo without a BIMI-Selector header.

Write the record exactly as the draft spells it: v=BIMI1 in that case, and every tag name in lowercase. The draft says receivers must not try to fix syntax or capitalization errors, so a record that starts with V=BIMI1 or v=bimi1, or uses L=, may simply be ignored. The BIMI checker still shows what such a record says, but reports it as an error.

A subdomain doesn't need a record of its own. When default._bimi.news.example.com doesn't exist, receivers fall back to default._bimi.example.com on the organizational domain. If a name has more than one BIMI record, receivers ignore all of them. To opt out of BIMI on purpose, publish empty l= and a= values:

default._bimi.example.com.  TXT  "v=BIMI1; l=; a="

The logo: SVG Tiny PS

The l= file must be an SVG in the Tiny PS profile, a restricted version of SVG Tiny 1.2 defined in the SVG Tiny PS Internet-Draft. It strips out everything that could run code or load something from elsewhere, so a logo is safe to render inside a mail app. These are the rules Patchkit's checker applies:

• The root <svg> element declares version="1.2" and baseProfile="tiny-ps" in the SVG namespace.
• It contains exactly one <title> directly inside <svg>, and it isn't empty. The BIMI Group suggests your company name.
• The viewBox is square, and the <svg> element has no x= or y= attributes.
• No <script>, no animation, no embedded images, audio or video, no <switch> and no links. Event handler attributes such as onclick= aren't allowed either.
• No references to outside files: an href or a CSS url() may only point to an #id inside the same file. A DOCTYPE isn't allowed.
• The file is no larger than 32 KB. The SVG Tiny PS draft says it should not exceed 32 kilobytes, measured uncompressed, and the checker fails any logo above that.

Design tools rarely export this profile directly, so most logos need a manual cleanup or a conversion step. Google's guide also asks for a logo at least 96 pixels high and wide, given in absolute pixels; the checker doesn't measure that. It also isn't a full SVG Tiny PS schema validation: it covers the rules receivers most often reject a logo for.

VMC vs CMC

A mark certificate is the evidence behind the a= tag. A Mark Verifying Authority checks that you have the right to use the logo and issues a certificate that names your domain and embeds the logo itself, using the logotype extension from RFC 9399. Section 7.9 of the BIMI draft says that when a record has both a= and l=, receivers must check that the embedded logo is identical to the one at l=. There are two kinds, described in the BIMI Group's overview:

• Verified Mark Certificate (VMC): for a registered trademark, or a mark a government recognizes. Google puts it as: your logo must be trademarked with an intellectual property office that VMC issuers recognize.
• Common Mark Certificate (CMC): for a logo without a trademark registration. It covers prior use marks, which rest on a history of legitimate use, and modified versions of a registered mark.

Which one you need depends on where you want the logo to appear (checked on October 13, 2026). Apple's documentation names only the VMC, alongside "other forms of BIMI Evidence Documents", and never mentions the CMC, so a VMC is the safe choice for Apple Mail. Gmail accepts a VMC or a CMC, shows its checkmark only for a VMC, and recommends a VMC whenever possible. Yahoo doesn't currently require either.

The BIMI checker reads the certificate's content, but it doesn't tell a VMC from a CMC, so the result always says "VMC or CMC". It also doesn't check whether the issuer is an authority the BIMI Group approved, whether the certificate was revoked, or the trademark registration behind it.

The DMARC requirement

BIMI only works on top of an enforced DMARC policy. The message has to pass DMARC, and the policy has to tell receivers to act on failures:

• p=quarantine or p=reject. The draft says receivers must not process BIMI when the policy is p=none.
• Both the From domain and its organizational domain have to enforce. A p=none or an sp=none on the organizational domain also stops BIMI, and the BIMI Group's implementation guide says the policy must be at enforcement on the organizational domain and its subdomains.
• The policy applies to all mail. The BIMI draft still refers to the older pct tag and requires pct=100 with quarantine, and Google's guide says pct must be 100.
• No testing mode. RFC 9989, the current DMARC standard, removed pct and added t=y, which asks receivers not to apply the policy. Neither the BIMI draft nor the providers address t=y yet. Because RFC 9989's Appendix A.6 makes it the counterpart of pct=0, and the BIMI draft and Google require pct=100, the BIMI checker treats testing mode as not meeting the requirement.

So a record like this one meets the requirement, as long as the organizational domain enforces too:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com

If you are still at p=none, Moving from p=none to p=reject walks through each stage, and What is DMARC? explains the tags.

Check your setup

The BIMI checker runs the whole chain for one domain. It reads the record at your selector, with the fallback to the organizational domain, and flags syntax and capitalization errors. It downloads the logo and the certificate only over https on port 443, following at most 3 redirects, and applies the logo rules above. For the certificate, it checks the BIMI extended key usage, that it names your domain, that it is valid today and that the chain inside the file is internally consistent. It also compares the embedded logo with your l= file and shows each DMARC condition as its own line.

An internally consistent chain isn't the same as a trusted one. The checker doesn't verify the certificate's root against the authorities the BIMI Group approved, doesn't check revocation, and doesn't look at the trademark behind the certificate. It also can't tell whether a provider will actually show your logo, because that depends on each provider's own rules. To check the DMARC record on its own, use the DMARC checker.