Publishing a BIMI record takes about five minutes. One TXT record, three tags, done. Everything the record depends on takes somewhere between three weeks and eighteen months.

BIMI, or Brand Indicators for Message Identification, is the standard that puts your logo in the avatar slot next to your messages in Gmail, Yahoo Mail, Apple Mail, and Fastmail. The DNS record is the last step, not the first. Reverse that order and you get a syntactically perfect record that displays nothing, forever, with no error anywhere to tell you why.

The record, and what its three tags actually do

The record lives at a selector beneath a _bimi subdomain. For a domain using the default selector, that is a TXT record at default._bimi followed by the domain name. A sender can point a specific message at a different selector using a BIMI-Selector header.

Three tags matter:

  • v=BIMI1 is the version. It is required and it must come first.
  • l= is the location of the logo file. The specification permits exactly one transport: HTTPS. Plain HTTP is not a degraded option, it is not an option at all.
  • a= is the authority evidence location, meaning the URL of your mark certificate in PEM form. It is optional, and if it is absent the specification treats it as empty.

A complete record carries the version, then an l= pointing at an HTTPS URL for the SVG, then an a= pointing at an HTTPS URL for the certificate.

An empty pair is meaningful rather than broken. A record of v=BIMI1 with empty l= and a= values is how a domain explicitly declines to participate for that selector, which is worth publishing on subdomains you never send mail from. Google's admin documentation adds a detail people skip: the web server hosting the logo and the certificate must itself use HTTPS. A redirect from HTTPS down to HTTP breaks the fetch.

DMARC at enforcement is a gate, not a suggestion

The specification requires a strong DMARC policy, quarantine or reject, on both the organizational domain and the From domain of the message. It also states plainly that quarantine policies must not carry a pct value below 100.

The BIMI Group's implementation guide spells out the same thing as a pair: p=quarantine with sp=quarantine, or p=reject with sp=reject. A policy of none does not qualify. Neither does partial enforcement. Google's requirement is identical, with the percent option set to 100 so the policy applies to all outgoing mail.

Two configurations fail here that look fine on a dashboard. The first is p=reject with pct=50, a common halfway state during rollout that reads as enforcement in most reporting tools and disqualifies you outright. The second is an organizational domain at p=reject with sp=none, which leaves every sending subdomain unprotected and therefore ineligible.

An ordinary SVG export will not do

The logo must be an SVG in the Tiny Portable/Secure profile. This is a real profile with real rules, not a naming convention. The root element must carry the SVG namespace, a version of 1.2, and a baseProfile of tiny-ps. A title element must be present, must not be empty, must appear exactly once as a child of the svg element, and should stay under 64 characters.

Then come the removals. The profile forbids the image element entirely, so you cannot wrap a raster file inside an SVG and call it done. It also disallows the switch element, multimedia, interactivity, linking, scripting, and animation. Path and shape attributes must not be animated. The zoomAndPan attribute should be absent, and must be set to disable if present.

Receivers layer their own limits on top. Google requires a minimum height and width of 96 pixels, expressed in absolute pixels rather than percentages, with the logo centered in a square, and a file of 32 KB or smaller. Fastmail's documentation sets its ceiling at 16 KB. Build to the smaller number.

This is where a normal design workflow breaks. A default export from a vector editor produces SVG 1.1 with no baseProfile, no title element, CSS classes and style blocks, often an embedded raster image, and frequently a viewBox with no absolute width and height. Every one of those is a validation failure. Converting a logo usually means hand-editing the file or running it through a purpose-built converter, then validating it before it goes anywhere near DNS.

The certificate fork: registered trademark or documented prior use

The governing document is the Minimum Security Requirements for Issuance of Mark Certificates, version 1.8, dated June 11, 2026. It defines five certificate types across two families.

Verified Mark Certificate

A VMC covers Registered Mark Certificates and Government Mark Certificates. For a registered mark, you give the certificate authority the registration number and the name of the trademark office that granted it. The CA verifies it against that office's official database, or alternatively through the WIPO Global Brand Database. The registration must be in good standing, and the owner on record must be the same organization as the certificate subject, or a parent, subsidiary, affiliate, or verified licensee. Unregistered marks are not eligible in this profile. No exceptions, no substitutes.

Common Mark Certificate

A CMC covers three routes: prior use, a modified registered trademark, and a provisional mark. The prior-use route is the one that matters if you have no registration, and its test has two legs.

First, a mark matching the SVG you submitted must currently be displayed on a website whose domain you control, with that control verified through an approved domain validation method. Second, a matching mark must have been displayed on that same domain at least 12 months earlier than the date of verification, and that historical display must be confirmed through an approved Archive Webpage Source. As of version 1.8, exactly one source is approved: archive.org.

Read that again, because it determines your timeline. Your evidence of prior use is the Wayback Machine. Internal brand guidelines, dated invoices, and old email templates do not count. If you rebranded nine months ago, or if archive.org simply never crawled the page carrying your logo, the twelve-month leg fails and there is nothing to appeal.

The other two CMC routes both require an existing registration anyway. The modified-registered-trademark route lets you rearrange word elements, remove up to 49 percent of a design element, and render the mark in any font or color on any background. The provisional route requires a registered mark that was registered at least three years before the request. Any mark certificate, of any type, has a maximum validity of 398 days.

Who honors what, and which certificate earns the checkmark

This is the part that decides whether you need a trademark at all.

  • Gmail requires third-party certification, either a VMC or a CMC, plus DMARC at quarantine or reject with the percent option at 100.
  • Yahoo states directly that it does not currently require VMCs for BIMI logos to appear in Yahoo applications. It still requires DMARC at quarantine or reject, a valid SVG, and adequate volume and sender reputation.
  • Fastmail does not require a certificate either, and its own documentation warns that some receivers, Gmail among them, will not display a logo without one.
  • Apple Mail names VMCs and refers generically to other forms of BIMI evidence documents, without publishing a CMC commitment. Support covers macOS Ventura 13, iOS 16, iPadOS 16 or later, and iCloud.com.

Apple's model differs from the others in a way worth understanding. Apple pushes verification onto the receiving mail provider, which must appear on the BIMI Group's list of supporting providers, be separately verified by Apple, validate the evidence document, and add the required headers. If your recipient's provider has not done that work, your logo does not appear in Apple Mail regardless of what you published.

On the checkmark, the documentation is unambiguous. Google states that in Gmail you will see a checkmark next to senders verified with a VMC, and notes that non-Gmail web apps do not support the feature. DigiCert's own product page says the same thing: VMCs enable the blue authenticated checkmark in Gmail. A CMC gets your logo into the avatar slot. It does not get you the checkmark. If the checkmark is the goal, the registered trademark is not optional.

What it costs

DigiCert lists both its Verified Mark Certificate and its Common Mark Certificate on a 12-month auto-renewing subscription at $1,416.00. SSL.com lists a VMC at $1,500 per year for a one-year term, $1,350 per year on two years, and $1,275 per year on three. SSL.com describes CMC eligibility as twelve or more months of common-law use and does not publish a CMC price. Budget roughly $1,300 to $1,500 per year, per certificate, and treat it as recurring rather than one-time, because that 398-day validity ceiling forces annual revalidation.

If you have no registered trademark and want one, the United States Patent and Trademark Office fee schedule sets the base application fee at $350 per class filed electronically. Surcharges stack on top: $100 per class for insufficient information, $200 per class for using the free-form text box instead of the Trademark ID Manual to identify goods and services, and $200 per affected class for each additional group of 1,000 characters beyond the first 1,000 in that box. A clean single-class filing that uses the ID Manual is $350 in government fees. Attorney fees, if you use one, are entirely separate.

Timing is the bigger cost. The USPTO's trademark dashboard sets a current fiscal year target of five months from filing to first action, with a long-term goal of 4.5 months, and a total pendency target of 11 months or less on average, rising to 14 months for applications involving suspensions or inter partes proceedings. Those are targets, not guarantees. An office action resets your planning: you get three months to respond, extendable by another three. Starting from zero, a year to registration is an optimistic assumption, and only then can you apply for the VMC. That gap is precisely why the Common Mark Certificate exists.

The trap: it fails silently

The specification states that if the SVG indicator is missing, or is not a valid SVG or SVGZ document, then validation has failed and the indicator must not be displayed.

Nothing bounces. No non-delivery report is generated. Your DMARC aggregate reports will not flag it, because DMARC reports cover authentication results, not indicator validation. The message delivers normally and lands in the inbox. The avatar slot simply shows whatever it showed before: an initial, a colored circle, a stock image. There is no failure signal anywhere in your own telemetry.

The recurring causes are mundane:

  • The l= URL returns a 404, or the host redirects HTTPS to HTTP, or serves the file with the wrong content type.
  • The SVG is an ordinary export with no tiny-ps baseProfile, no title element, or an embedded raster image.
  • The file clears one receiver's size ceiling and not another's, so the logo appears in Gmail and not in Fastmail.
  • DMARC sits at p=quarantine with pct=50, or the organizational domain is at p=reject with sp=none.
  • The a= URL points at a certificate that quietly expired after 398 days.

The only reliable detection is active: fetch the l= URL yourself from outside your network, validate the SVG against the Tiny P/S profile with a checker rather than by eye, and send test mail to seed addresses at each provider you care about after every change.

Sequence it backward

The order that works is the reverse of the order it is usually attempted. Get DMARC to full enforcement first and leave it there long enough to be confident nothing legitimate is being rejected, since that alone can take weeks of report review. Build and validate the Tiny P/S file before spending a dollar on a certificate. Then look up your own domain on archive.org and find out when your current logo first appeared there, because that single lookup tells you whether the CMC path is open to you today or twelve months from now, and whether the trademark filing needs to start immediately. Decide last whether the Gmail checkmark justifies a registered trademark, since that is the only thing the extra cost and the extra year actually buy. The DNS record goes at the very end, because it is the one step in the whole chain that cannot tell you it went wrong.