BIMI SVG and VMC basics: logo format rules, certificate requirements, and common validation mistakes

Once a domain is actually ready for BIMI, the next failures are usually not about DMARC anymore. They are about the logo file, the certificate path, or one small validation detail that looked harmless during setup.

If you need the bigger BIMI picture first, start with What is BIMI, how does it work, and what problem does it solve?, How BIMI relates to DMARC, and BIMI prerequisites for administrators.

The short version

For most real deployments, BIMI succeeds only when all three of these are true:

1. the published logo is a BIMI-compatible SVG, not just any marketing SVG
2. the certificate path matches the mailbox provider's expectations, often with a VMC or CMC delivered as a PEM chain
3. the DNS and HTTPS references are exact enough that validators do not have to guess what you meant

1. A BIMI SVG is not the same thing as a normal web SVG

This is the first trap.

Design teams often hand over a perfectly good SVG for websites, slide decks, or print workflows. That does not mean the file is valid for BIMI.

Current BIMI guidance points senders to SVG Tiny PS. Google also documents additional compatibility checks for Gmail. In practice, that means the logo file should be treated as a constrained delivery artifact, not as a general-purpose brand asset.

The format rules that matter most

At a minimum, the BIMI SVG should follow these rules:

• SVG format using the SVG Tiny PS profile
• baseProfile="tiny-ps"
• version="1.2"
• no scripts
• no animations or interactive elements
• no external references
• no x= or y= attributes on the root <svg> element
• dimensions declared in absolute pixels for Gmail compatibility

Google's current setup guidance also says the image must be at least 96x96 pixels, should be centered in a square, and should stay small enough to render reliably. Google recommends 32 KB or smaller and also recommends a <desc> element for accessibility.

Why ordinary SVG exports fail

Common graphics-tool exports often include things that are fine on the web but risky for BIMI validation:

• references to external assets
• editor-specific metadata or unsupported features
• relative sizing such as width="100%"
• transparency assumptions that render poorly in mailbox clients
• extra elements left behind by Illustrator or other export tools

So if someone says, "We already have the logo as SVG," that should be treated as the start of validation, not the end of it.

2. What a VMC actually proves

A Verified Mark Certificate (VMC) is the certificate-backed path for showing that the claimed logo is tied to a verified mark.

The current BIMI draft defines a broader Mark Certificate (MC) concept and distinguishes between:

• VMC for registered trademarks or government marks
• CMC for prior-use marks or allowed modifications of registered marks

The operational point is simple: the certificate is the evidence layer that helps mailbox providers decide whether the published logo should be trusted enough to display.

Why VMCs exist at all

Without a certificate-backed evidence path, BIMI would be much easier to abuse with lookalike domains and copied branding.

The BIMI draft is explicit that brand indicators are a potential abuse vector. It also leaves final display policy to mailbox providers, which is why providers can require stronger evidence than the DNS record alone.

Gmail's current position is stricter than "self-asserted BIMI"

Google's current admin guidance says BIMI requires third-party certification for the domain and logo, specifically a VMC or CMC. It also says Gmail and other email clients support BIMI only with PEM files when the certificate-backed path is used.

That means an organization can publish a syntactically valid BIMI record and still not meet Gmail's real-world deployment expectations.

3. Trademark readiness is usually the real VMC blocker

The technical work for BIMI often depends on legal readiness.

Google says VMC eligibility requires a trademarked logo from an intellectual property office recognized by VMC issuers, and notes that trademarking can take 6 to 12 months. The BIMI Group likewise describes VMCs as based on registered trademarks and positions CMCs as the alternative when the exact trademark path is not available.

This matters because many teams approach BIMI as a DNS project, when it is often partly a legal and brand-governance project.

A practical way to think about VMC vs CMC

Use this rough rule:

1. if the exact logo is trademarked and the brand wants the strongest mainstream path, plan around a VMC
2. if the logo is not trademarked or the published mark needs an allowed variation, investigate whether a CMC path is appropriate

Do not assume "certificate" automatically means VMC. For many organizations, the first real question is whether the logo is even eligible.

4. The PEM file matters more than many teams expect

For Gmail's certificate-backed BIMI flow, the PEM file is not just a wrapper you ignore after issuance.

Google documents a specific process:

1. obtain the entity certificate PEM from the issuing authority
2. append any intermediate CA certificates and the root CA certificate in the order issued
3. host that resulting PEM file on a public HTTPS server
4. reference that PEM URL in the BIMI a= tag

That is one of the most common places where implementations go wrong.

Common PEM-related mistakes

• hosting only the entity certificate and forgetting the rest of the chain
• appending the certificates in the wrong order
• serving the PEM file from an HTTPS path that is blocked, redirected badly, or not publicly reachable
• pointing the a= tag to the wrong file
• assuming the embedded logo alone is enough without the expected certificate path

If the certificate chain is incomplete or unreachable, a mailbox provider can reject the BIMI evaluation even when the logo file itself is fine.

5. The BIMI record syntax is easy to get almost right and still fail

BIMI TXT records are strict.

The BIMI draft says receivers MUST NOT attempt to fix syntax or capitalization mistakes in assertion records. If a required tag is missing or malformed, the record is an error.

That has two direct consequences:

1. close-enough syntax is not reliable
2. tiny mistakes can invalidate the entire record

The fields that admins most often break

For a basic certificate-backed record, the common shape is:

default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/brand/logo.svg; a=https://example.com/brand/certificate.pem"

For Gmail's documented PEM-based example, the l= tag can be empty while the a= tag points to the PEM file:

default._bimi.example.com. IN TXT "v=BIMI1; l=; a=https://example.com/brand/certificate.pem"

The mistakes that show up repeatedly are:

• publishing the record at the wrong DNS name instead of default._bimi.<domain>
• misspelling BIMI1
• confusing the number 1, uppercase I, and lowercase l
• using HTTP instead of HTTPS
• leaving off required separators or quotes in DNS
• pointing l= or a= at a non-public URL

Google explicitly warns that 1, I, and l look similar in BIMI syntax. That sounds trivial, but it is a real production mistake.

6. The validation failures you should expect first

When a new BIMI deployment does not work, these are the first failure classes to check.

SVG validation failures

• the file is not SVG Tiny PS
• root attributes are wrong
• width and height use percentages instead of pixel values
• unsupported elements, scripts, or external references are present
• the artwork is technically valid SVG but not acceptable for BIMI processing

Certificate and evidence failures

• the logo is not eligible for the certificate type being requested
• the PEM file does not include the needed chain
• the hosted certificate URL cannot be fetched cleanly
• the certificate path published in DNS does not match the intended hosted file

DNS and hosting failures

• the BIMI TXT record is published at the wrong host name
• the DNS content is malformed
• the referenced URLs are not HTTPS
• the public web server TLS setup or certificate chain is broken

Policy and expectation failures

• the domain still has DMARC at p=none
• pct is below 100
• the team assumes a self-asserted setup should work the same way at Gmail as a certificate-backed one
• the team assumes a valid setup guarantees display at every provider

7. A simple admin checklist before you validate BIMI

Before you spend time on mailbox-provider troubleshooting, verify these in order:

1. confirm the sending domain is already at DMARC enforcement with pct=100
2. confirm the BIMI record is published at default._bimi.<domain>
3. confirm every referenced URL is public and HTTPS-based
4. confirm the SVG is truly BIMI-compatible, not just viewable in a browser
5. confirm the certificate type matches the brand's eligibility path
6. confirm the PEM file contains the expected chain in the expected order
7. confirm your target mailbox provider actually supports the deployment model you are testing

That order prevents a common waste of time: trying to debug display behavior before validating the logo file, certificate chain, and DNS syntax.

Bottom line

BIMI success depends on precision.

The logo must be a BIMI-compatible SVG Tiny PS file, the evidence path must satisfy the provider's certificate expectations, and the DNS and HTTPS references must be exact enough to survive strict validation. In real deployments, the most common failures are ordinary ones: a non-compliant SVG export, a VMC eligibility assumption that was never true, an incomplete PEM chain, or a tiny record-syntax mistake that no receiver is willing to repair.