The BIMI Standard

BIMI displays verified brand icons in email clients when authentication and policy requirements are met.

---

Three Requirements

BIMI (Brand Indicators for Message Identification) operates at the intersection of three technical controls. First, the sending domain must publish and enforce a DMARC policy at quarantine or reject. Second, a DNS TXT record at default._bimi.[domain] must reference an SVG image via HTTPS. Third, that SVG must conform to the SVG Tiny Portable/Secure profile. All three are mandatory. Failure of any component prevents indicator display.

---

DMARC Enforcement Prerequisite

BIMI requires p=quarantine or p=reject in the organisational domain’s DMARC record. The p=none policy does not qualify. Subdomain policies (sp=) are evaluated separately if a subdomain publishes its own BIMI record. DMARC authentication must pass using either SPF or DKIM with identifier alignment. The requirement establishes that unauthenticated mail cannot trigger indicator display, reducing impersonation risk.

---

SVG Tiny Portable/Secure Profile

SVG Tiny P/S is defined in RFC 9345 and restricts SVG to a security-hardened subset. The profile prohibits script, external resource references, animation, and complex filter effects. Permitted elements include basic shapes (<path>, <circle>, <rect>), <title>, <desc>, and static gradients. All styles must be presentation attributes or internal <style> blocks — no external CSS. The <svg> root must declare the Tiny 1.2 or 2.0 namespace and should include baseProfile="tiny-ps". Images must be square with a viewBox attribute. File size is recommended below 32 KB.

---

Why These Constraints Exist

The profile eliminates entire classes of client-side attack vectors. Scripts could execute in the context of the mail client. External references could leak recipient data via HTTP requests or introduce malicious payloads. Animations could trigger photosensitive seizures or mask phishing content. Filters could exploit rendering engine vulnerabilities. By restricting SVG to declarative geometry and gradients, the profile allows brand expression while maintaining a parseable, auditable format that can be safely rendered in security-sensitive contexts.

---

BIMI Record Structure

The DNS TXT record at default._bimi.[domain] contains two components: v=BIMI1 declares version 1 of the specification. l=https://example.com/logo.svg specifies the SVG location, which must be served over HTTPS with a valid certificate. An optional a= tag references a Verified Mark Certificate (VMC) for trademarked logos. Receivers may require VMCs for display. The record format is strictly defined; extraneous tags or syntax errors cause lookup failure.

---

Receiver Implementation Variability

BIMI is a receiver-side decision framework, not a guaranteed display protocol. Gmail, Yahoo, Fastmail, and others maintain independent policies regarding VMC requirements, caching duration, image rendering, and fallback behaviour. Some receivers display indicators only for mail passing both SPF and DKIM. Others implement additional reputation signals or manual review. A valid BIMI record does not guarantee indicator visibility. Receivers may reject images for reasons beyond technical compliance, including content policy violations or trademark disputes.

---

Validation Scope of This Tool

makeBIMI validates syntactic conformance to SVG Tiny P/S: document structure, element whitelist, attribute restrictions, namespace declarations, and viewBox geometry. It checks for prohibited elements, external references, scripts, and animations. It does not validate DMARC record syntax, DNS propagation, HTTPS certificate validity, VMC authenticity, trademark rights, or receiver-specific acceptance criteria. It does not guarantee that any email receiver will display your indicator. Validation confirms technical eligibility, not deployment success.

Watch: What is BIMI?

---

For a source-verified implementation overview that distinguishes BIMI requirements from receiver policy, read BIMI: how it works.