# BIMI Email Authentication
Brand Indicators for Message Identification (BIMI) is an email specification that allows organizations to display a verified brand logo directly in the recipient's inbox alongside authenticated messages. It exists to solve a specific, practical problem: email recipients cannot easily distinguish legitimate messages from spoofed ones without inspecting technical headers. BIMI creates a visible, in-client trust signal by tying logo display to successful DMARC validation. The result is a system where strong authentication earns a brand reward, creating a business incentive that accelerates DMARC adoption across organizations that might otherwise deprioritize email security hygiene. BIMI does not replace authentication protocols; it surfaces their results in a human-readable, visually immediate format.
---
Brand Indicators for Message Identification (BIMI) is a DNS-based email specification governed by the AuthIndicators Working Group, a coalition that includes major mailbox providers such as Google, Yahoo, Fastmail, and others. BIMI defines a standard mechanism for publishing a logo URL in DNS and optionally attaching a Verified Mark Certificate (VMC) to confirm trademark ownership of that logo.
BIMI is not an authentication protocol. It does not replace or modify SPF, DKIM, or DMARC. It is a display layer that sits on top of a completed authentication stack. A domain that has not achieved DMARC at enforcement policy (p=quarantine or p=reject) cannot display a BIMI logo, because BIMI has no authentication work of its own to perform. It depends entirely on DMARC to confirm that the message genuinely originated from the claimed domain.
BIMI is also not an anti-phishing system in the general sense. It confirms that a message passed authentication for a specific domain. It says nothing about whether that domain is trustworthy, whether the organization behind it is legitimate, or whether the content of the message is safe. A domain could pass DMARC and display a BIMI logo and still send harmful content.
BIMI should be distinguished from email client branding features that predate it. Some providers historically displayed logos based on internal databases or sender reputation scores. BIMI standardizes this through open DNS records and cryptographic certificate verification, making the display process auditable and portable across compliant mailbox providers.
Subtypes worth noting: some mailbox providers support BIMI without requiring a VMC, displaying logos based on DMARC compliance alone. Gmail and Apple Mail require a VMC for logo display. This creates a two-tier deployment reality where organizations may see logos in some clients but not others depending on whether they have obtained a VMC.
---
BIMI operates as a chain of dependencies. Each step must succeed before the next is possible.
Step 1: Email Authentication Stack Completion
Before BIMI can function, the sending domain must have SPF and DKIM configured correctly and a DMARC policy published at p=quarantine or p=reject. DMARC at p=none, while useful for monitoring, does not qualify for BIMI. This requirement is intentional. BIMI's authors wanted the logo display benefit to be available only to senders who have committed to active enforcement, not just observation.
A practical example: a financial services company publishes DMARC at p=none for six months while auditing mail streams. During this period, BIMI cannot display their logo even if they publish a BIMI record. Only after they move to p=quarantine or p=reject and confirm no legitimate mail is being broken does BIMI become available to them.
Step 2: Logo Preparation in SVG Tiny PS Format
The brand logo must be prepared in SVG Tiny PS format, a restricted profile of the SVG specification developed specifically for BIMI. SVG Tiny PS prohibits script execution, external references, animations, and features that could introduce security risks when a mail client renders the image. The logo must be a standalone, self-contained vector file. Organizations that have logos in raster formats (JPEG, PNG) or full SVG must have their design teams produce an SVG Tiny PS compliant version. This is a common implementation friction point.
Step 3: Logo Hosting
The SVG Tiny PS file must be hosted at a publicly accessible HTTPS URL. The server must return a valid TLS certificate and the file must be directly accessible without redirects. Many organizations host this on their primary web infrastructure or a dedicated brand asset server.
Step 4: BIMI DNS Record Publication
The BIMI record is published as a DNS TXT record at the subdomain default._bimi.yourdomain.com. The record contains two primary tags: v=BIMI1 (the version identifier) and l= (the HTTPS URL pointing to the SVG Tiny PS logo file). A third optional tag, a=, points to the VMC. An example record looks like this:
default._bimi.example.com IN TXT "v=BIMI1; l=https://brand.example.com/logo.svg; a=https://brand.example.com/cert.pem"If a VMC is not required by the receiving mailbox provider, the a= tag can be omitted or left empty.
Step 5: Verified Mark Certificate (VMC) Issuance
For mailbox providers that require a VMC (currently Gmail and Apple Mail), the organization must obtain a certificate from a qualified Certificate Authority. As of this writing, Entrust and DigiCert are the primary VMC issuers. The VMC process requires the organization to hold a registered trademark for the logo in the relevant jurisdiction. The CA verifies trademark ownership before issuing the certificate. The certificate embeds the logo directly and is published at the URL referenced in the a= tag.
This step is the most significant barrier for smaller organizations. VMCs carry annual costs and the trademark requirement excludes entities that have not formally registered their marks.
Step 6: Message Receipt and Logo Display
When a message arrives at a BIMI-supporting mailbox provider, the receiving infrastructure checks whether the message passes DMARC validation. If it does, the server queries the DNS for the sending domain's BIMI record. It retrieves the logo file from the l= URL, optionally validates the VMC from the a= URL, and injects the logo into the inbox view for the recipient.
A concrete scenario: a bank sends a transaction alert email. The recipient uses Gmail. The message passes SPF, DKIM aligns, DMARC validates at p=reject, Gmail queries default._bimi.bank.com, retrieves the SVG, validates the VMC confirming the bank's trademark, and the bank's registered logo appears as a blue-checked avatar next to the message in the recipient's inbox. The recipient sees a consistent, recognizable brand mark that confirms the message is from the authenticated domain.
Implementation Considerations
BIMI records can be tested before full deployment using available validators from providers including BIMI Validator (bimigroup.org). DMARC reporting should be monitored closely before and after BIMI deployment to ensure alignment rates are stable. Organizations with multiple sending domains must publish separate BIMI records for each domain. Subdomains that send mail independently may also need their own records if BIMI inheritance is not supported by the mailbox provider.
---
BIMI matters because it converts an invisible technical control into a visible business outcome. Organizations have been slow to adopt DMARC at enforcement partly because enforcement can disrupt legitimate mail flows and there is no immediate, visible benefit to the effort. BIMI changes that calculus by giving organizations something their marketing and brand teams can point to: a logo in the inbox.
This is not a trivial incentive. Brand recognition in email affects open rates, customer trust, and perceived legitimacy. When organizations see that enforcing DMARC and deploying BIMI improves inbox presentation, they have a concrete reason to prioritize authentication work that might otherwise be deprioritized against competing IT projects.
From a security perspective, the DMARC enforcement prerequisite means that every domain displaying a BIMI logo has taken meaningful steps to prevent domain spoofing. Attackers cannot spoof a BIMI-equipped domain in a way that produces a logo display, because spoofed messages will fail DMARC and the logo will not appear. Recipients who are trained to look for the logo will notice its absence on spoofed messages.
A real-world consequence that illustrates the stakes: in 2020, the Anti-Phishing Working Group reported that phishing attacks against financial institutions frequently involved exact-domain spoofing or close lookalike domains. Institutions with DMARC at p=reject significantly reduced spoofed delivery of their domain name. BIMI takes this a step further by creating a positive confirmation signal rather than simply blocking negatives.
A common misconception is that BIMI itself is a security control. It is not. It is a display mechanism. The security work is done by DMARC. Organizations should not measure their email security posture by whether BIMI is deployed; they should measure it by DMARC enforcement rates, DKIM signing coverage, and SPF alignment. BIMI is a downstream benefit of that work, not a replacement for it.
Another misconception is that VMC acquisition guarantees deliverability or inbox placement. It does not. VMCs confirm trademark ownership of a logo. They have no influence on spam scoring, reputation systems, or content filtering.
---
CDA approaches BIMI through the Planetary Defense Model (PDM) under the SPH domain, which governs sending posture hygiene. The governing methodology is Autonomous Posture Command (APC): "Your posture adapts. Your hygiene never sleeps."
In the APC framework, BIMI deployment is not a one-time configuration task. It is a continuously monitored posture indicator. CDA treats the full BIMI stack (SPF, DKIM, DMARC, BIMI record, VMC validity, logo hosting availability) as a set of hygiene signals that are monitored on a scheduled basis. Any degradation in any component degrades the effective posture score for that domain.
What CDA does differently is operationalize the dependencies. Many organizations deploy BIMI and then treat it as done. CDA's approach maps each dependency as a separately monitored control point. If a VMC approaches expiration, APC flags it as a posture risk before it lapses. If the logo hosting URL becomes unreachable, APC detects the 4xx or 5xx response and triggers a remediation task. If a DMARC policy is inadvertently relaxed to p=none during a mail server migration, APC immediately identifies the loss of BIMI eligibility and escalates.
CDA also addresses the trademark-to-VMC pipeline operationally. Organizations with pending trademark registrations cannot yet obtain a VMC. CDA's SPH roadmap tracks trademark registration timelines and schedules VMC acquisition as a dependent task, so the moment a registration is confirmed, the VMC process begins without a gap.
For organizations that cannot yet obtain a VMC, CDA supports phased BIMI deployment: publishing the BIMI record with a logo URL but without the a= tag, enabling logo display in providers that do not require a VMC (such as Yahoo Mail and Fastmail), while tracking VMC acquisition for Gmail and Apple Mail compatibility as a pending milestone.
CDA's reporting surfaces BIMI posture alongside DMARC aggregate data, giving security and brand teams a unified view of authentication health and logo display eligibility across all managed domains. This eliminates the common organizational gap where IT owns DMARC and marketing owns brand assets but neither team has visibility into the combined BIMI posture.
---
---
---