The marketing team comes back from a conference with a simple request: we want our logo next to our emails in Gmail, just like the bank has. The mail administrator checks and finds that the logo is the smallest problem. The domain has a DMARC policy of p=none, invoices go out through an external accounting system, and the newsletter runs on a marketing platform set up by an agency that no longer exists.
That is how many BIMI projects start. The standard looks like a branding add-on, but it is really a reward for well-ordered email: the logo appears only when the domain tells receivers to quarantine or reject messages that impersonate it. In May 2026 the rules of the DMARC record itself were changed by the new RFC 9989, which also matters for BIMI as part of email cybersecurity.
What is BIMI and what does the recipient actually see?
BIMI (Brand Indicators for Message Identification) is a mechanism that lets a domain owner point to a logo that the recipient’s mailbox displays next to messages sent from that domain. The recipient sees the brand logo instead of an initial or a blank avatar, provided the message passed authentication and the mailbox supports the standard.
As of 12 November 2026 the BIMI specification is an individual Internet-Draft in version 15, last updated on 31 October 2026. The IETF Datatracker page states that the document has no formal standing in the IETF standards process. In practice BIMI is developed by the AuthIndicators Working Group, known as the BIMI Group, and mailbox providers decide whether to support it.
The most visible implementation is Gmail. Google Workspace Admin Help (as of 26 October 2026) also describes a verification checkmark next to senders whose logo is backed by a VMC certificate. The distinction matters, because the two certificate types described below produce different results in Gmail.
It is worth setting expectations right away. BIMI is not a feature you switch on in a mail console. It is a chain of dependencies: a DMARC policy, a DNS record, a logo file in a strictly defined format and, for Gmail, a certificate issued by an external certification authority. Each link has a different owner inside the company.
Why does BIMI work only with DMARC at enforcement?
BIMI works only with DMARC at enforcement because the draft explicitly requires the domain owner to have a quarantine or reject policy on both the organizational domain and the domain in the From header. A p=none policy, which only collects reports, rules out displaying the logo. The same applies to an sp=none subdomain policy.
The logic is simple: the logo is meant to help the recipient recognize the real sender. If the domain tolerated messages that fail DMARC, a fraudster could send a fake, and the mailbox would have no basis to tell it apart. BIMI therefore requires the domain to first tell receivers what to do with forgeries. What DMARC is and how it works with SPF and DKIM is explained in the DMARC glossary entry, and configuration details in the guide to DMARC, SPF and DKIM.
Google describes the same requirements from the Gmail side: the p option must be set to quarantine or reject, and the pct option to 100, meaning the policy covers all outgoing mail from the domain. The BIMI draft adds that with a quarantine policy and an explicit pct tag, that tag must be exactly 100.
In practice this requirement is the hardest part of the project. Moving from p=none to quarantine means that every message from a system not properly configured for SPF or DKIM may land in the recipient’s spam folder. Before you tighten the policy, DMARC aggregate reports must show every source of mail sent on behalf of the domain, including the ones IT did not know about.
Key takeaways:
- BIMI requires a DMARC policy of
quarantineorrejecton the sender domain and the organizational domain.- A
p=noneorsp=nonepolicy rules out displaying the logo.- Most of the work is the inventory of systems sending email, not the logo itself.
- The definition and configuration of DMARC are covered by the glossary and a separate guide; here we focus on what BIMI requires.
What does RFC 9989 change in the DMARC record for BIMI?
RFC 9989, published in May 2026, replaced the previous RFC 7489 and removed the pct tag from DMARC. Its useful function was taken over by a new t tag (for “testing”) with the values y and n. Meanwhile, version 15 of the BIMI draft and Google’s help still describe the pct=100 requirement, referring to the old RFC.
For an administrator this has one practical consequence. Under RFC 9989, t=y means the domain owner is testing the policy, and the receiver applies one level lower: with p=quarantine it applies a policy of none to failing messages, and with p=reject it applies quarantine. Version 15 of the BIMI draft does not describe the t tag, so it is unclear how mailboxes will treat a p=quarantine; t=y record. It is safer to publish the policy without t=y.
What about pct, if the new RFC no longer knows it? In RFC 7489 the tag was optional and its default value was 100. A record without pct and without t=y therefore meets both the old and the new understanding of full policy application. An explicit pct=100 does no harm for receivers working under RFC 7489, but it has no meaning in the new standard. The BIMI specification is still a draft, and mailbox provider requirements catch up with the DMARC change with a delay. A configuration that is correct today needs a review whenever the source documents change.
What does a BIMI DNS record look like?
A BIMI record is a TXT record published in the _bimi subdomain, by default under the name default._bimi.yourdomain.com. It contains the protocol version, the address of the logo file and, optionally, the address of the document confirming the right to the logo, that is the certificate. A sample record looks like this:
default._bimi.yourdomain.com. IN TXT "v=BIMI1; l=https://yourdomain.com/bimi/logo.svg; a=https://yourdomain.com/bimi/vmc.pem"The l= tag points to the logo location and, according to the draft, allows HTTPS transport only. The a= tag points to the evidence document issued by the authority that verified the mark, in practice a PEM file with the certificate. An empty a= means a self-asserted logo with no verification.
The draft also provides selectors, meaning different records for different mail streams. The default selector default is enough for most companies, but an organization sending transactional and marketing mail separately can point each stream to a different logo. The sender chooses the selector in a message header, and the receiver looks up the record under the matching name.
Typical mistakes at this step are mundane: a typo in the subdomain name, a logo file served through a redirect, or a TLS certificate with an incomplete chain. Google’s help recommends a server with TLS 1.2 or later and requires a TLS certificate that references a trusted root authority.
How do VMC and CMC certificates differ and who issues them?
A VMC (Verified Mark Certificate) confirms a logo that is a registered trademark or a government mark, while a CMC (Common Mark Certificate) covers a logo with a history of prior use without registration or a modified version of a registered mark. Both are types of Mark Certificate and, according to the draft, they are issued by a Mark Verifying Authority, an authorized verifying entity.
The BIMI Group announced CMCs on 26 September 2024, and Google began supporting them in Gmail as an alternative to VMCs. This is an important change for smaller companies, because for a VMC the logo must be registered with an intellectual property office recognized by VMC issuers. Google estimates that trademark registration alone usually takes 6 to 12 months (as of 26 October 2026).
The difference is also visible to the recipient. Gmail shows the verification checkmark only for senders backed by a VMC. The BIMI Group notes that the way a logo is displayed depends on the mailbox provider and that the working group does not define how VMC and CMC presentation should differ.
A VMC or CMC is issued by a certification authority from the list maintained by the BIMI Group, which Google’s help points to. The list changes, so before choosing an issuer it is worth checking its current version rather than articles from several years ago. The choice of certificate is first a legal decision, depending on whether and where the logo is registered, and only then a technical one.
How do you prepare a logo in SVG Tiny PS format?
A BIMI logo must be an SVG file in the SVG Tiny Portable/Secure profile, known as SVG Tiny PS. The BIMI Group requires the baseProfile="tiny-ps" attribute, version 1.2 and a <title> element with the company name. The file must not contain scripts, animations, external references or x= and y= attributes in the root <svg> element.
Gmail adds its own requirements. According to Google Workspace Admin Help (as of 26 October 2026), the image must be at least 96 by 96 pixels, and its size must be given in absolute pixels, not percentages. Google also recommends a logo centered in a square, on a solid background, with a <desc> element for accessibility and in a file no larger than 32 KB.
The most common trap is the export from a design tool. The BIMI Group points out that an SVG Tiny 1.2 export from Adobe Illustrator adds x= and y= attributes, which must be removed by hand or with a script. A logo with a transparent background may not display as expected, and the mailbox may show it in a circle or a square with rounded corners.
The file approved by the certificate issuer goes into a PEM file together with the certificate. Google stresses that Gmail and other email clients support BIMI only with PEM files, completed with the intermediate and root certificates. Any later logo change therefore means a new certificate, not swapping the image on the server.
Which mailboxes display BIMI logos?
BIMI logos backed by a VMC or CMC are displayed by Gmail, among others, while self-asserted logos without a certificate are supported by only a few providers. The BIMI Group lists Yahoo, Fastmail and La Poste among them. The difference comes from the fact that some mailboxes do not trust a logo whose right of use nobody independent has checked.
Supporting the standard does not guarantee that the logo is displayed. The BIMI Group explains that a mailbox provider is not required to show the logo of a domain that uses BIMI and can make local decisions, for example based on sender reputation. A domain with a correct setup may therefore still appear with an initial for some recipients.
For a company this boils down to a simple question: where are our customers’ mailboxes? If most recipients use Gmail and Google Workspace, a certificate is a prerequisite. If mailboxes that do not support BIMI dominate, the visual benefit will be limited, and the main value of the project will remain the DMARC clean-up.
Does BIMI protect against phishing?
BIMI protects against phishing only indirectly: it enforces a DMARC policy that blocks messages impersonating that specific domain and makes it easier for the recipient to recognize the genuine sender. The logo itself does not assess message content. It confirms the sender’s domain, not the sender’s intentions.
This distinction has real consequences. If a criminal takes over a real mailbox of an employee or a supplier, a message sent from it will pass SPF, DKIM and DMARC, because it is technically authentic, and yet it may contain a fake bank account number. A compromised account will pass DMARC and get the logo, which is why BIMI does not replace content inspection.
BIMI also does not protect against lookalike domains in which one letter is swapped. A fraudster can configure a valid DMARC record for such a domain, but will not get a certificate for someone else’s trademark, so for recipients using Gmail those messages will show neither the logo nor the verification checkmark. That is a real, though limited, benefit.
Full protection comes only from layers working together: DMARC at enforcement, an email filter that analyzes content, attachments and links, a procedure for confirming payment detail changes through another channel, and employees who know whom to report a suspicious message to. The email security hub covers mail protection against ransomware and phishing in a wider context.
Where should a company start a BIMI rollout?
A BIMI rollout starts with checking whether the domain is ready for DMARC at enforcement, not with ordering a certificate. The order matters, because a certificate without a quarantine or reject policy has no effect at all. The checklist below arranges the conditions in the order in which it makes sense to meet them.
| Readiness condition | How to check | Typical trap | Who is responsible |
|---|---|---|---|
| You know every source of mail from the domain | DMARC aggregate reports from several weeks | a forgotten invoicing system, CRM or survey platform | mail administrator |
| Every source passes aligned SPF or DKIM | DMARC reports, headers of test messages | a marketing platform signing with its own domain | mail administrator and system owners |
quarantine or reject on the domain and the organizational domain | the _dmarc record of the main and sending domains | sp=none for subdomains or t=y added with p=quarantine | DNS administrator |
| Logo in SVG Tiny PS format | BIMI Group validator, Gmail requirements | x= and y= attributes from the export, transparent background | marketing and designer |
| Legal basis for the logo | trademark register | the logo differs from the registered mark | legal department |
| VMC or CMC certificate and PEM file | certificate details, certificate chain | missing intermediate certificates in the file | administrator and certificate issuer |
default._bimi record and HTTPS hosting | DNS query, file download test | a redirect or an incomplete TLS chain | DNS and server administrator |
| Review after standards change | date of the last check in the documentation | a record with pct below 100 replaced by t=y | domain owner |
The first three rows take the most time: from a few weeks to many months, depending on the number of systems that send email. The remaining steps go faster, provided the trademark already exists. If the logo is not registered, the choice between registering a trademark for a VMC and getting a CMC stretches the schedule the most.
Key takeaways:
- Order: mail sources, aligned SPF and DKIM, DMARC policy, and only then the logo and certificate.
- Check that
t=yhas not been added withp=quarantine(e.g. to replacepctbelow 100).- The choice between VMC and CMC depends on trademark status, not on technology.
How can nFlo help protect email against domain impersonation?
nFlo implements and maintains email protection solutions that work alongside DMARC and BIMI: Check Point Email Security (formerly Harmony Email & Collaboration) protects Microsoft 365 and Google Workspace through an API, and Barracuda Email Protection combines email filtering with protection against account takeover and BEC attacks. These tools analyze content, links and attachments and detect signs of account takeover, which is exactly what BIMI, by definition, does not assess.
During an implementation we also put email authentication in order: we inventory sending sources, analyze DMARC reports and prepare a plan for moving to an enforcement policy. The VMC or CMC certificate is ordered by the trademark owner from an issuer on the BIMI Group list, and we support the preparation of technical data at that step.
If you want to check whether your domain is ready for BIMI and how to close the gaps in email protection, contact us.
What else is worth knowing about BIMI?
Is BIMI an official IETF standard?
No. As of 12 November 2026 the BIMI specification is an individual Internet-Draft in version 15, and the IETF Datatracker page states that the document has no formal standing in the standards process. Even so, Gmail and some other mailboxes support BIMI in practice.
Do I need a trademark for BIMI?
For a VMC, yes: the logo must be a registered trademark. Without a trademark, Gmail accepts a CMC, issued for a logo with a history of prior use or a modified registered mark. According to Google, trademark registration alone can take many months.
Does BIMI work with a DMARC policy of p=none?
No. The BIMI draft explicitly forbids BIMI processing when the domain has a p=none or sp=none policy. You need a quarantine or reject policy applied to all messages, on both the organizational domain and the sender domain.
Does BIMI replace an anti-phishing filter?
No. BIMI confirms that a message passed DMARC for a given domain and lets the mailbox display its logo. It does not assess message content or detect compromised accounts. Protection against phishing still comes from email filters, procedures and user training.
How long does a BIMI rollout take?
The technical part, the DNS record and the logo file, takes little time. The longest part is reaching DMARC enforcement, because it requires an inventory of every system sending email for the domain, plus a possible trademark registration for a VMC.
