How to use your logo in the From address

Open one of your own product emails in Gmail and look at the circle next to your sender name. Most senders find a grey letter sitting there, which is the placeholder every domain gets by default. Filling that circle with your logo is a DNS record called BIMI, and publishing the record turns out to be the easy part.

The rest of this explains what has to be true before the record does anything, because a correctly published BIMI record on a domain that fails one of three prerequisites shows exactly the same grey letter.

The short answer

Publish one TXT record on your sending domain:

; The logo, and the certificate that vouches for it
default._bimi.example.com.  TXT  "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/cert.pem"

Three things gate it:

1. DMARC at enforcement. p=quarantine at full coverage, or p=reject. A domain at p=none is ignored.
2. The right kind of SVG. Square, solid background, served over HTTPS, in a restricted profile called Portable/Secure.
3. A mark certificate, for some providers. Gmail reads the a= tag and shows nothing without it. Yahoo, Fastmail and La Poste draw the logo from the l= tag alone.

When all three hold, the circle fills in.

What a BIMI record contains

BIMI stands for Brand Indicators for Message Identification. The record is a TXT entry published at default._bimi under your domain, and it carries two tags that matter.

l= is the location of the logo. a= is the location of the certificate asserting that the logo is yours. Both must be HTTPS URLs; the specification allows no other transport for either.

The default part is a selector. A message can name a different one with a BIMI-Selector header, which is how a company runs separate logos for separate product lines. Almost nobody needs that on day one. What matters more is where you publish the default record: put it on your organisational domain and every sending subdomain inherits it, so one record covers mail.example.com, send.example.com and anything you add later.

Receivers resolve all of this at delivery time. Your mail carries no logo and no certificate, which is why nothing about your sending code changes.

The DMARC policy is the real gate

This is where most attempts stop, and it is worth being precise about the threshold.

The specification accepts a domain whose DMARC policy is quarantine at an effective 100%, or reject at any percentage. A policy of none fails, and so does quarantine at anything under full coverage. There is no partial credit and no logo drawn at reduced volume.

Two details catch people out. The first is that enforcement is read at the organisational domain rather than only at the subdomain you send from. If your mail leaves mail.example.com, then _dmarc.example.com needs to be at enforcement as well, and the parent record wants a matching sp= so the policy reaches its subdomains.

The second is the starting position. The DMARC record we generate when you add a domain uses p=none, because that is the policy that collects reports without touching delivery while you find every system sending as you. It is the right default and it is below BIMI’s floor, so getting a logo means moving off it deliberately.

Raising the policy will not break your domain in the dashboard. Our verification looks for our own rua and ruf addresses in the record and reads nothing else, so you can change p= and sp= freely as long as both of those addresses stay exactly as they were. What you should not do is jump to p=reject on a domain you have not finished inventorying. Read the reports until nothing legitimate is failing, then tighten. The mechanics of all this are in our earlier post on SPF, DKIM and DMARC.

Self-asserted, a CMC or a VMC

The a= tag is where BIMI stops being free.

Leave it empty and you have a self-asserted record. It claims nothing beyond the fact that you control the DNS, and Yahoo, Fastmail and La Poste accept it. If those providers cover your audience, you are finished, and you have spent nothing.

Gmail reads the certificate instead. A record with an empty a= draws no logo there, whatever the SVG looks like. Two certificate types satisfy it:

A Verified Mark Certificate covers a registered trademark or a government-recognised mark. That is the older of the two, and for a young company it means a trademark application first, which is a process measured in months.

A Common Mark Certificate covers a mark you have used publicly without registering it. It exists precisely so that a company without a trademark can still get a logo into Gmail, and Google supports it today. The issuer decides what evidence of prior use it will accept, so ask before you plan around it.

DigiCert, GlobalSign and SSL.com issue both. Each runs its own verification before signing, so start the process well before any launch that assumes the logo is there.

What to do about it

1. Check where your DMARC policy actually sits. Query _dmarc on your organisational domain, not just on the subdomain you send from. If you see p=none, that is your first piece of work.
2. Read your DMARC reports for a couple of weeks. Find every system sending as your domain. This is the step nobody enjoys and the one that makes the rest safe.
3. Tighten to p=quarantine, then to p=reject. Keep both of our reporting addresses in the record, comma-separated alongside any of your own.
4. Produce the SVG. Square, solid background, a single non-empty title element, under 32 KB, no scripts and no external references. Export from your design tool and then fix it, because general purpose SVG output does not pass.
5. Decide whether you need Gmail. If yes, start a CMC or VMC application now. If no, skip straight to the record.
6. Publish the TXT record at default._bimi on your organisational domain, and query it back to confirm what resolved.

Common mistakes

• Leaving DMARC at p=none. The single most common reason a published BIMI record does nothing. Every other piece can be perfect and the logo still will not draw.
• A transparent background. Each provider composites the logo onto a background of its own choosing, and a transparent file vanishes against roughly half of them. Use a solid fill.
• Exporting an ordinary SVG. Portable/Secure is a restricted subset. Missing baseProfile="tiny-ps", a missing title, an embedded raster or an external font reference each fail validation on their own.
• Pasting the full record name into a DNS panel. Most panels append your zone to whatever you type, so the Name field takes default._bimi alone. Type the full name and you publish default._bimi.example.com.example.com.
• Expecting it immediately. Providers weigh your sending reputation before drawing a logo, and they refresh on their own schedules. A domain with high complaint or bounce rates keeps a blank avatar with every record correctly in place.

Where to go next

The record syntax, the full SVG rule table and the certificate comparison are in the BIMI guide(opens in a new tab) , which is the page to work from when you are actually publishing.

If your logo still does not appear after everything above resolves, you are looking at a reputation problem rather than a configuration one, and it needs different signals. The thinking behind our sending path covers what we do about that, and the pricing page has what a dedicated IP costs if your volume justifies one.