# BIMI

BIMI is a DNS record pointing at a logo, which some mailbox providers show beside a message. It does nothing on its own: it is gated behind DMARC at enforcement, a tightly constrained SVG profile, and — at the providers most people want it for — a certificate proving the mark is yours. Connect neither publishes nor reads one.

- **Status:** Reference
- **Audience:** both
- **Channels:** email
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/technology/bimi/

## The record, and everything standing in front of it

The record itself is trivial. A TXT record at `default._bimi.example.com` carries `v=BIMI1`, an `l=` pointing at an HTTPS-hosted logo, and optionally an `a=` pointing at a certificate.

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

The gates in front of it are where the work is, and they are checked in roughly this order by a receiver that supports the scheme.

1. The message must pass DMARC with an aligned identifier — an unauthenticated message never reaches the logo question.
2. The domain's DMARC policy must be at enforcement, meaning `quarantine` or `reject` rather than `none`, applied to the whole domain rather than a sampled fraction.
3. The logo must be SVG Tiny Portable/Secure: a restricted SVG profile with no scripting, no external references, no animation, a square aspect ratio and an explicit background. An ordinary export from a design tool is not this.
4. For several major mailbox providers, the `a=` certificate must be present and valid — a Verified Mark Certificate, issued against a registered trademark, or in some programmes a Common Mark Certificate issued against prior-use evidence, which fewer clients honour.

## Is it worth doing?

It depends almost entirely on where you already are with authentication, and the honest answer for most small businesses is: not first.

| Situation | Sensible next move |
|---|---|
| No SPF or DKIM, or a broken one | Fix authentication. BIMI is unreachable from here and the effort spent on a logo buys nothing |
| DMARC at `p=none` | Read the aggregate reports and get to enforcement. That step has real deliverability value on its own |
| DMARC at enforcement, no registered trademark | A Common Mark Certificate route exists and is honoured by fewer clients; weigh it against the cost of the certificate |
| DMARC at enforcement, registered trademark, high-volume consumer mail | The clearest case for it — recognisable sender identity at scale |

> **Careful** A BIMI logo is not an input to spam filtering. It is a rendering decision made after a message has already been accepted and authenticated. Any deliverability benefit comes from the DMARC enforcement BIMI forces you to reach, not from the logo.

## Where it goes wrong

**The logo does not appear anywhere** — Almost always the DMARC gate: the policy is `none`, or the specific message failed alignment even though most do not.
**It appears in one client and not another** — Expected. Support is per-provider, each with its own certificate requirement and its own caching, and there is no standard that obliges any of them.
**The SVG is rejected** — The Tiny Portable/Secure profile is stricter than most people expect — a linked font, an embedded raster, a script node or a non-square viewBox is enough.
**It appeared, then stopped** — A certificate expiry, a logo URL that started answering with a redirect or a non-200, or a DMARC policy that was relaxed back to `none` during an unrelated incident.

## Does Connect use BIMI?

No — this page is background. Connect publishes no BIMI record for any workspace, holds no mark certificate, does not host or validate a logo, and does not read a BIMI record when it processes incoming mail. Nothing in the product changes because a domain has one or does not.

The reason it earns a page at all is that BIMI is the most common way a business first hears the phrase *DMARC enforcement*, usually from a marketing supplier. The underlying work is [DMARC](/docs/technology/dmarc/), and that work is worth doing on its own terms.

## Questions

### Will publishing BIMI improve where my mail lands?

Not directly. Filtering happens before rendering, and the logo is a rendering decision. What can improve placement is the DMARC enforcement BIMI requires — so if the logo is the argument that finally gets authentication finished, the outcome is good even though the reasoning was indirect.

### Do I need a registered trademark?

For a Verified Mark Certificate, the certificate authorities' terms are built around a registered mark. A Common Mark Certificate uses prior-use evidence instead and is accepted by fewer mailbox providers. Neither is required by the specification itself — the certificate requirement comes from individual providers, not from the record format.

### Does an AI-drafted reply carry my logo?

A reply Connect writes is sent through your own mailbox, so it is treated by receivers exactly like a reply you typed — same domain, same authentication, same logo or lack of one. There is no separate sending identity to configure.

## Related

- [DMARC](https://connectbyjbrh.com/docs/technology/dmarc/)
- [DKIM](https://connectbyjbrh.com/docs/technology/dkim/)
- [Email deliverability](https://connectbyjbrh.com/docs/technology/deliverability/)
- [DNS](https://connectbyjbrh.com/docs/technology/dns/)
- [Email in Connect](https://connectbyjbrh.com/docs/email/)

## What this page is based on

- BIMI Group — implementation requirements and the SVG profile (https://bimigroup.org/)
- IETF draft-brand-indicators-for-message-identification — the record format
- RFC 7489 — DMARC, the enforcement prerequisite (https://www.rfc-editor.org/rfc/rfc7489)
- Connect capability registry (`docs-source/facts.py`)