BIMI Record Generator

Mail apps have put a small circle beside each sender for years. Usually it holds an initial, sometimes a photograph, and now and then a company logo that the mail provider found somewhere and decided to show. The sender had no say in it. Brand Indicators for Message Identification, BIMI for short, is an attempt to give the owner of a domain that say, on one condition: the mail has to be provably theirs first.

The mechanism is modest. A domain publishes one DNS record that points to a logo file, and a receiver that takes part may show that logo beside messages from the domain. The specification is careful about what this is. It says BIMI relies on the existing authentication protocols and is not a new authentication protocol itself. Everything interesting about it follows from that sentence.

A draft, not yet a standard

BIMI is not an RFC. It is described in Internet-Drafts, documents that carry a standing warning that they may be updated, replaced or made obsolete at any time and should be cited only as work in progress. The main one is at its fourteenth version, dated 1 May 2026, and expires on 2 November 2026 unless it is renewed. The datatracker lists it as an individual submission, intended for the standards track but not adopted by a working group of the standards body.

Its authors come from mail providers and mail security companies. The effort also has a home outside the standards body, the AuthIndicators Working Group, which publishes guidance for senders alongside the drafts. The draft explains why they bothered. Receivers had been building closed logo systems of their own, each with its own database, each disagreeing with the others, and a domain owner could influence them only by negotiating with every provider in turn. Most owners could not take part at all.

Because the text is still moving, a careful tool has to say which version it follows. The current draft defines two tags that earlier versions lacked, and the working group’s own help pages still spell one of them differently from the draft. When the two disagree, the draft is the specification.

The chain underneath

Three older protocols carry the weight. The Sender Policy Framework lets a domain publish which hosts may send mail using its name, and a receiving host checks the connecting machine against that list. It looks at the envelope sender and the greeting of the mail session, neither of which a reader ever sees.

DomainKeys Identified Mail works on the message itself. The sending system adds a cryptographic signature, and the receiver fetches the matching public key from the signer’s domain in DNS. A valid signature shows that the named domain took responsibility for the message and that the signed parts were not changed on the way. The standard is explicit that the signer need not be the author.

That gap is what DMARC closes. It takes the domain in the visible From line as the identity that matters and asks whether SPF or DKIM passed for a domain that matches it, which it calls alignment. The domain owner publishes a policy for mail that fails: none, quarantine or reject. A percentage tag lets the owner apply the policy to only a share of failing mail while rolling it out.

BIMI adds its conditions on top. A receiver must not do any BIMI processing unless the message passed DMARC, and the draft then rules out three kinds of DMARC record. A policy of none stops it. A record that carries a subdomain policy of none stops it. A policy of quarantine with a percentage tag is acceptable only when that tag is pct=100. The working group’s guide goes further and says that any percentage under 100 is not accepted, and that subdomains should be at enforcement too.

This is the homework. For most organisations it means months of reading DMARC reports until every legitimate source of mail is signed and aligned, and only then tightening the policy.

One TXT record

The record itself is small. It is a TXT record at a name built from a selector, the fixed label _bimi and the domain, and the selector called default is used when a message asks for no other. Its text follows the tag and value syntax that DKIM introduced: pairs joined by an equals sign and separated by semicolons. The version tag must come first and must be exactly v=BIMI1. Receivers are told not to repair syntax or capitalization, so a lower-case version is simply not a BIMI record.

Two more tags do the work. The tag l gives the location of the logo and a gives the location of an evidence document; both must be single https addresses when they are present. Take example.org with its logo at https://www.example.org/brand/logo.svg and a certificate at https://www.example.org/brand/mark.pem. The record goes at default._bimi.example.org and its value is v=BIMI1; l=https://www.example.org/brand/logo.svg; a=https://www.example.org/brand/mark.pem;. Typing those three values into the generator on this page produces exactly that text.

Leaving both locations empty is meaningful as well. The value v=BIMI1; l=; a=; is an explicit refusal to take part, different from publishing nothing, and it lets a subdomain opt out when its parent domain has a logo. A domain that wants several logos publishes several records under different selectors and names the one it wants in a BIMI-Selector header, which should be covered by the aligned DKIM signature.

The newest tags are about people. The tag avp states whether a receiver that also shows personal pictures should prefer the brand logo or the sender’s own avatar. The tag lps turns the local part of the sender’s address into a selector after a fixed clean-up: anything from a plus sign onward is dropped, dots and underscores become hyphens. A message from news.letter+october at example.org would therefore send a receiver to look for news-letter._bimi.example.org.

Why the logo is so restricted

An ordinary SVG file is closer to a small program than to a picture. It can hold scripts, links, animation, embedded photographs and references to other files on the network. A mail provider drawing a stranger’s SVG beside every message in an inbox would be running that stranger’s content for millions of readers. So the drafts define a profile called SVG Tiny Portable/Secure, cut down from the W3C’s SVG Tiny 1.2.

The root element must declare the SVG namespace, version 1.2 and a base profile of tiny-ps, and it must have exactly one title with something in it. Whole chapters of SVG Tiny are then removed: the image element, conditional switching, multimedia, interactivity, linking, scripting and animation. An older standard for logo images inside certificates had already drawn the same two lines, no script and no reference to anything outside the image.

A few softer rules complete it. The file should not exceed 32 kilobytes, measured uncompressed. It must show at least two colours when drawn. The working group advises a square shape with the mark centred, because providers crop to a circle or a rounded square, and a solid background, because nobody knows what surface the logo will sit on. The profile also publishes a formal schema, and where a simple checker and that schema disagree, the schema wins.

What the certificate adds, and what the picture proves

DMARC shows that mail came from a domain. It says nothing about whether that domain has any right to the logo it publishes. The evidence document is meant to fill that hole. A mark verifying authority checks the organisation and its claim to the mark and issues a mark certificate, which carries the logo inside it and is logged publicly. One kind covers registered trademarks and government marks; another covers marks shown to be in prior use and modified forms of registered ones. The working group gives their longest validity as 398 days.

In the record syntax the evidence tag is optional. In practice, as the working group’s pages read in October 2026, each provider sets its own criteria, many require a certificate, and records without one have limited support. Those are statements about other people’s policies and they change.

So what does the little picture prove to the person reading the mail? That the message passed DMARC for the domain in the From line, and that this domain published this logo. With a certificate, also that some authority examined the claim to the mark. It does not prove the message is honest or safe. A lookalike domain can authenticate its own mail perfectly well, and the draft’s security section says as much: publishing a record is not sufficient, and receivers may weigh reputation before showing anything.

A page like this one has limits of the same kind. It can write the record correctly, read one back, check a pasted DMARC record against the draft, and inspect a logo file for the rules that can be read from its text. It cannot see your DNS, fetch your logo, validate a certificate or predict what any provider will display.

The honest case for BIMI may be the homework rather than the reward. A domain that has reached DMARC enforcement is much harder to forge, whether or not a logo ever appears beside its mail.