Guide
BIMI, Brand Indicators for Message Identification, is a DNS record that tells a mailbox provider where to fetch your brand logo so it can be shown next to your messages. It is not an authentication method. It is a reward for authentication already being in order: the logo appears only for mail that passes DMARC under a policy of quarantine or reject, and at Gmail and Apple Mail only when a certificate vouches for your right to the logo. This page covers what has to be true before anything displays, the record and SVG format, the two certificate types, and which providers show the logo at all.
Last reviewed September 2026
Before BIMI, a mailbox provider that wanted to show a brand's logo next to its mail had to build and maintain its own database of logos, one provider at a time, with no way for the brand to influence what appeared. BIMI replaces that with a record the domain owner publishes in DNS. A participating receiver checks that the message is authentic, looks up the record for the From domain, fetches the logo it points to, and hands the logo to the mail client to display. The domain owner controls the image; the receiver controls whether it is shown.
The specification says of itself that it "relies on these authentication protocols, but is not a new authentication protocol itself." That sentence is the whole design. BIMI adds no signature, no policy and no verification of the message. What it adds is a visible consequence of authentication that already passed, which is why every provider that supports it makes DMARC a hard precondition.
Two things follow for anyone deciding whether to bother.
The specification is an Internet-Draft, draft-brand-indicators-for-message-identification, at revision 14 as of May 2026. It has been an individual draft rather than a working group document for its whole life, and it is not an RFC. That has not stopped deployment: the large consumer mailbox providers implemented it from the draft, and what they require in practice is set by their own published rules, which this page treats as the operative ones.
The specification lists the authentication requirements a receiver must verify before it will even look for a BIMI record. Every one of them is about DMARC.
none. The specification's own phrasing is that the record "MUST express either a Requested Mail Receiver policy of quarantine with an effective percentage of 100%, or a Requested Mail Receiver policy of reject". A monitoring-only policy disqualifies the domain, however cleanly its mail authenticates.none. An sp=none tag on the organizational domain's record disqualifies mail from any subdomain.quarantine policy has no partial percentage. Under the draft, p=quarantine with a pct tag below 100 disqualifies the message. What this means under the 2026 revision of DMARC, which removed the pct tag entirely, is covered below.Gmail's and Yahoo's published requirements say the same thing in their own words: the policy must be quarantine or reject, and Gmail adds that pct must be 100. Both also say something the specification leaves to receiver policy: the sending domain has to have a reputation with them. Yahoo states that it displays logos only for bulk mail from senders with "sufficient reputation and engagement", not for personal email, and the specification's security section is explicit that without verification and reputation "there is no way to prevent a bad actor" from borrowing a brand's logo. A new domain with a perfect record and no history will not see its logo on day one.
If your domain is at p=none, BIMI is not the next step. Enforcement is.
RFC 9989 describes the path: publish p=none with a reporting address for at least a month, read the aggregate reports until every legitimate source of mail authenticates and aligns, spend an equal period at quarantine, then move to reject. The logo is what you get at the end of that, not a way around it. Our position, set out in the authentication guide, is that every sending domain should be making that journey now regardless of whether a logo is wanted, because the mailbox providers' requirements are moving toward enforcement.
A BIMI record, which the specification calls an Assertion Record, is a DNS TXT record published at a name built from a selector, the label _bimi, and the domain. The selector default is what receivers look up unless a message asks for another one, so for almost every domain the record lives at:
default._bimi.example.comIts value uses the same tag and value syntax as DKIM and DMARC records:
v=BIMI1; l=https://example.com/brand/logo.svg; a=https://example.com/brand/vmc.pemv=BIMI1 - required, and it must be the first tag. A record whose version tag is missing, misplaced or not exactly BIMI1 is ignored in its entirety.l= - required. The HTTPS URL of the logo file. Only HTTPS is permitted, and the certificate the logo server presents must chain to a root the receiver trusts, or the logo is not displayed. An empty value means the domain declines to publish a logo.a= - optional. The HTTPS URL of the evidence document, in practice a Verified or Common Mark Certificate in PEM format, that vouches for the domain's right to use the logo. Gmail and Apple Mail will not display a logo without it. Yahoo will.lps= - optional. Lets the local part of the From address, the part before the @, select a different record, so orders@ and news@ can carry different logos from the same domain.avp= - optional. Whether a receiver that also supports personal avatars should prefer the brand logo, the default, or the sender's avatar.Receivers are told not to repair a malformed record: the specification says they "MUST NOT attempt to fix syntactical or capitalization errors", and a missing or malformed required tag is an error. Unknown tags are ignored, as with DMARC.
A domain can publish more than one record under different selectors and choose between them per message with a BIMI-Selector header, for seasonal branding or different product lines. If no record is found at the From domain, receivers fall back to the same selector at the organizational domain, so one record at default._bimi.example.com covers news.example.com and orders.example.com too. Yahoo says it honors records on subdomains but prefers them at the organizational domain.
The fallback also has an off switch. A record of v=BIMI1; l=; a=; is an explicit declination: it tells receivers that this subdomain, or this selector, does not want a logo even though the organizational domain publishes one. That is different from having no record, and it is the right tool for a subdomain that sends mail you would rather not brand.
Once the record is live, receivers cache what they fetch. Gmail says it can take up to 48 hours for a new logo to appear.
The logo is not any image. The specification permits only SVG, either plain or gzip-compressed, and requires that a URL ending in any other image suffix, or a file that turns out to be another format, be treated as a permanent error. On top of that, the SVG has to conform to a restricted profile defined in a companion draft, draft-svg-tiny-ps-abrotman, called SVG Tiny Portable/Secure.
The restriction exists because an SVG is a document, not a picture. Ordinary SVG can contain scripts, external references, links and animation, none of which a mailbox provider is going to render from an arbitrary domain next to a message. The Tiny PS profile strips the format down to static shapes so the file is safe to fetch, cache and display at scale. Gmail's published requirements for the file are the practical checklist most senders work to:
baseProfile="tiny-ps".Receivers validate the file after fetching it. The specification has them check the size against recommended maxima, reject anything that is not valid SVG, run the profile validation, and only then display the logo "per receiver policy". A design agency's export will almost never pass unmodified; most logos need to be flattened, have text converted to paths, and have anything interactive removed before the profile validator accepts them. Do that before publishing the record, because a record pointing at an invalid file produces a BIMI failure rather than a fallback.
If a certificate is involved, the same SVG is embedded in the certificate at issuance, and the file served at the l= URL has to match it. Changing the logo later means reissuing the certificate, not just replacing the file.
A BIMI record on its own is a self-assertion: the domain says this is its logo. Some providers accept that. Others want a third party to have checked that the domain has a right to the image, and the mechanism for that is a Mark Certificate, issued by a Mark Verifying Authority, published at the record's a= URL, and containing the logo itself.
The BIMI Group, the industry body behind the specification, lists three authorities qualified to issue them: DigiCert, GlobalSign and SSL.com. There are two certificate types.
A VMC is issued for a logo that is a registered trademark, or a government mark, with a trademark office the issuers recognize. The authority verifies the organization, verifies the trademark registration, checks that the SVG matches the registered mark, and issues a certificate binding the logo to the domain. Gmail's guidance is blunt: "To be eligible for a VMC, your logo must be trademarked with an intellectual property office that's recognized by VMC issuers." This is the certificate that unlocks the blue checkmark next to the sender name in Gmail.
A CMC, introduced by the BIMI Group in September 2024 and accepted by Gmail from the same month, exists for brands that do not hold a registered trademark for the logo they use, or whose trademark differs from the logo as used. It is issued on the basis of a documented history of public use of the mark instead of a registration. The same organization verification applies. In Gmail, a CMC gets the logo displayed but not the checkmark, which Google reserves for VMCs. Gmail is the only provider the BIMI Group's announcement names as accepting CMCs.
Both certificate types are issued with a validity of 12 months. That makes renewal part of the operating cost rather than a one-time step: an expired certificate at the a= URL fails validation, and the logo disappears at every provider that requires evidence until it is replaced. Put the renewal date somewhere that outlives the person who set it up.
The practical conclusion is that a self-asserted record gets you Yahoo, and a certificate gets you everyone. Whether that certificate can be a VMC depends on whether the logo is a registered trademark. If it is not, a CMC covers Gmail today, and registering the mark is the route to the rest.
Omnivery is a DigiCert reseller for both Verified and Common Mark Certificates.
Whichever type you need, we are happy to help you obtain one, with the 12-month renewal tracked alongside the domain, and the BIMI status of each sending domain is visible in the platform's domain view, so whether the record, the logo and the evidence resolve is something you can see rather than infer from which recipients report seeing a logo.
Who shows the logo
From the BIMI Group's published support list and each provider's own documentation. The list runs to fifteen providers; the ones below are those most senders will care about. Requirements beyond the specification are the provider's own.
| Provider | Displays BIMI logos | Certificate | Published conditions |
|---|---|---|---|
| Gmail | Yes | VMC or CMC required. Checkmark shown for VMC only | DMARC quarantine or reject with pct 100; SVG Tiny PS 1.2, at least 96 pixels, square; up to 48 hours to appear |
| Yahoo, AOL | Yes | Not required | DMARC quarantine or reject; valid SVG; bulk mail only, from a sender with "sufficient reputation and engagement"; subdomain records honored, organizational domain preferred |
| Apple Mail, iCloud.com | Yes, since iOS 16, iPadOS 16 and macOS Ventura 13 | Works with VMCs and other BIMI Evidence Documents | DMARC required; both the sender and the recipient's mail service must meet Apple's requirements |
| Fastmail, Zoho Mail, Comcast, GMX, Web.de, La Poste | Yes | Per provider | Listed by the BIMI Group as supporting BIMI; conditions are each provider's own |
| Microsoft: Outlook.com, Exchange Online | No | Not applicable | Listed by the BIMI Group under "does not support BIMI". The largest gap in coverage, and the reason a logo project should not be sold internally as universal |
BIMI Group support list, Google Workspace Admin Help "Set up BIMI", Yahoo Sender Hub BIMI page and Apple Support "About BIMI support in Apple Mail", all checked September 2026.
The BIMI draft was written against RFC 7489, and revision 14 from May 2026 still cites it throughout, including the requirement that a quarantine policy carry an effective percentage of 100. In the same month the IETF published RFC 9989, which replaced RFC 7489 and removed the pct tag altogether, replacing its one useful behavior with a test-mode tag, t=y, that asks receivers to apply the policy one level down. The authentication guide covers the full set of changes.
The two documents have not been reconciled yet, and the BIMI draft's authors are the same community that will have to do it. Until then the safe reading is the one that satisfies both: publish p=quarantine or p=reject, publish no pct tag, and publish no t=y. A record in test mode is asking receivers to treat quarantine as none, and none is exactly the policy BIMI excludes. Whether a given receiver reads t=y that way for BIMI purposes is not something either document currently says, which is a reason not to find out with your logo.
The other 2026 change matters less here than it might seem. RFC 9989 replaced the Public Suffix List with a DNS Tree Walk for finding the Organizational Domain, and BIMI's fallback from the From domain to the organizational domain depends on that determination. A domain with a BIMI record at its own organizational domain and one level of sending subdomain gets the same answer either way. The cases where it could differ, deep subdomain hierarchies and unusual suffixes, are the same cases the authentication guide already tells you to solve by publishing explicit records at every sending name.
BIMI is the one part of the authentication stack that a sending platform cannot do for you, because the logo and the trademark are yours. What a platform can do is make sure the preconditions hold and stay held, and take the certificate procurement off your list.
The records a sending domain needs and how alignment is enforced at submission are documented under domain setup and domain detail.
At a glance
Questions
Brand Indicators for Message Identification is a DNS record that lets a domain owner tell mailbox providers where to fetch the brand's logo, so it can be displayed next to the domain's messages in the inbox. A participating provider checks that the message passes DMARC, looks up the record at default._bimi.yourdomain, fetches the SVG logo it points to and, where the provider requires it, checks a certificate vouching for the domain's right to the logo. It is not an authentication method. It is a display feature that becomes available once authentication is fully in place and enforced.
A DNS TXT record at selector._bimi.domain, almost always default._bimi.example.com, with a value of the form v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem. The v tag must come first and must be exactly BIMI1. The l tag is the HTTPS URL of the logo, in SVG Tiny Portable/Secure format. The a tag, optional in the specification but required by Gmail and Apple in practice, is the HTTPS URL of a Verified or Common Mark Certificate. Two further optional tags let the local part of the From address pick a different record and set a preference between the brand logo and a personal avatar. Receivers ignore records with a missing or misplaced version tag and do not repair syntax errors.
Yes, and at an enforcement policy. The specification requires the message to pass DMARC and requires the domain's policy to be quarantine, with an effective percentage of 100, or reject. A policy of none disqualifies the domain, and a subdomain policy of none disqualifies its subdomains. Gmail and Yahoo state the same requirement in their own documentation. This is why BIMI is best understood as the last step of an authentication project rather than a project in its own right: publishing the record takes minutes, and reaching enforcement without breaking legitimate mail is the work.
Not directly. Whether a message reaches the inbox is decided before BIMI is evaluated, and the specification forbids a receiver from even looking up the record for a message that failed authentication. What BIMI gives you is recognition in the inbox and, at Gmail with a VMC, a visible verified checkmark, both of which can affect whether a message is opened. The deliverability benefit, such as it is, comes from the DMARC enforcement you had to reach to qualify, which protects the domain from being spoofed. Treat the logo as a brand outcome and the enforcement as the deliverability outcome.
A VMC is a certificate issued by one of the mark verifying authorities the BIMI Group qualifies, currently DigiCert, GlobalSign and SSL.com, which binds a specific SVG logo to a domain after verifying the organization and confirming that the logo is a registered trademark or government mark with a recognized intellectual property office. It is published at the a= URL of the BIMI record in PEM format, contains the logo itself, and is issued with a 12-month validity, so it has to be renewed annually or the logo stops displaying. Gmail requires a VMC or CMC to display any logo and shows its verified checkmark only for VMCs. Omnivery is a DigiCert reseller for both VMCs and CMCs, so the certificate can be arranged alongside the domain setup.
The basis for issuance. A Verified Mark Certificate requires the logo to be a registered trademark. A Common Mark Certificate, introduced by the BIMI Group in September 2024, is issued instead on documented prior public use of the logo, for brands that have no registration or whose registration does not match the logo as used. The same organization verification applies to both. In Gmail, both get the logo displayed, but only a VMC earns the checkmark next to the sender name. Gmail is the only provider the BIMI Group's announcement names as accepting CMCs, so for the widest coverage a VMC remains the target.
At Yahoo, yes. Yahoo displays logos from a self-asserted record, one with a valid l= tag and no a= tag, and states that it does not currently require a VMC, provided the domain is at DMARC quarantine or reject, sends bulk mail and has sufficient reputation and engagement. Gmail does not accept a self-asserted record and requires a VMC or CMC. Apple describes BIMI as working with VMCs and other BIMI Evidence Documents. So a record without a certificate is a Yahoo-only deployment, and adding a certificate is what extends it to Gmail and Apple Mail.
SVG, plain or gzip-compressed, conforming to the SVG Tiny Portable/Secure profile defined in a companion Internet-Draft. Any other image format is a permanent error under the specification. Gmail's published requirements, which most senders work to, are SVG version 1.2 with baseProfile set to tiny-ps, absolute pixel dimensions of at least 96 pixels each way, a square shape with a solid background, and a file of 32 KB or under. Scripts, external references, links and animation are not permitted. Most logo files exported from design tools need text converted to paths and everything interactive removed before they validate, and when a certificate is used the certificate embeds the same SVG, so changing the logo means reissuing it.
The BIMI Group lists fifteen providers with support, including Gmail, Yahoo and AOL, Apple Mail and iCloud.com, Fastmail, Zoho Mail, Comcast, GMX, Web.de and La Poste, plus Japanese carriers KDDI and NTT docomo. Each sets its own conditions on top of the specification. The significant absence is Microsoft: the BIMI Group lists it under "does not support BIMI", so Outlook.com and Exchange Online recipients see no logo. For a business-to-business sender whose recipients are largely on Microsoft 365, that limits the audience considerably.
No. As of September 2026 the BIMI Group lists Microsoft as the one named provider that does not support BIMI, and this covers Outlook.com, Hotmail and Exchange Online mailboxes. Recipients there see whatever Outlook shows for any sender, regardless of the record. This does not change the case for the DMARC work BIMI requires, which protects the domain at Microsoft as much as anywhere, but it does mean a logo project should be presented internally as reaching consumer inboxes rather than every inbox.
Gmail says up to 48 hours after the record is published. Beyond propagation, receivers apply reputation: Yahoo states that logos are shown only for bulk mail from senders with sufficient reputation and engagement, and the specification's security section says BIMI depends on the sending domain having meaningful reputation with the receiver. A newly registered domain, or one that has just moved to enforcement, may see the logo appear at some providers before others as that history accumulates.
Yes, in two ways. Publish a record at the sending subdomain itself, which takes precedence over the organizational domain's record. Or publish records under different selectors, such as seasonal._bimi.example.com, and name the selector per message with a BIMI-Selector header. The lps= tag additionally lets the local part of the From address choose the record, so orders@ and news@ can differ. A subdomain that should show no logo despite the parent's record publishes v=BIMI1; l=; a=; which is an explicit declination.
Under the BIMI draft, yes: a quarantine policy with a pct value below 100 disqualifies the message, and Gmail requires pct to be 100. Under RFC 9989, the May 2026 revision of DMARC, the pct tag no longer exists and receivers ignore it as an unknown tag. The two documents have not been reconciled. The safe record satisfies both: p=quarantine or p=reject, no pct tag, and no t=y test-mode tag, since test mode asks receivers to treat quarantine as none and none is the policy BIMI excludes.
Three things. Every message sent through the platform has SPF and DKIM aligned to the sending domain by construction, so the DMARC pass BIMI requires is met for the mail Omnivery sends. The BIMI status of each sending domain is shown in the platform alongside its other records and re-checked with them multiple times per day, so a record, logo URL or certificate that stops resolving is visible before recipients stop seeing the logo. And Omnivery is a DigiCert reseller for both Verified and Common Mark Certificates, so whichever type you need, we are happy to help you obtain one. The logo and the trademark remain yours to provide.
Every external claim on this page traces to one of these. Statements about Omnivery's own platform link to the relevant documentation where they are made, rather than being listed here.
The BIMI and SVG Tiny PS drafts are the revisions current in September 2026; the datatracker links resolve to whatever revision is current when you read this, so check the number before quoting. Provider requirements change without notice and were checked at the same date. No duration is stated for the prior use a Common Mark Certificate requires, because the BIMI Group and Google pages cited do not state one; the issuers' own documentation does. No claim is made about how many domains have deployed BIMI or how often logos are displayed.
BIMI is the visible end of work that happens elsewhere. These cover the parts that decide whether a logo can appear at all.
Every message aligned to your sending domain at submission, DMARC validated against the current standard, and the BIMI record, logo and certificate checked with the rest of your domain records multiple times a day. DigiCert Verified and Common Mark Certificates available through Omnivery when the domain is ready for one.