Email authentication
BIMI record generator
Build the BIMI TXT record for your logo, with or without a certificate.
Free, no accountIn your browser
The HTTPS address of the SVG Tiny PS file. This is the "l=" tag.
The HTTPS address of the PEM file, if you have one. This is the "a=" tag.
Result
A record that declines BIMI
Publish the record below as a TXT record at the default selector.
- Warning
DMARC is not at enforcement yet
Draft-14 §7.1 step 7 says BIMI processing MUST NOT be performed when the DMARC policy for the domain or its organizational domain is "p=none", and step 8 says the same about "sp=none". BIMI Group makes quarantine or reject on both step 1 of its guide. This record is still worth publishing, but nothing will show a logo until the policy moves.
Take DMARC to "p=quarantine; sp=quarantine" first, confirm the aggregate reports show nothing legitimate failing, then publish this record.
- Info
This record declines to participate
With no logo and no certificate, both tags are empty - draft-14 §4.3.1 calls that an explicit refusal to participate in BIMI, which a receiver reports as "bimi=declined". Add an SVG URL above and the record turns into a real assertion.
BIMI record to publish
At default._bimi (TXT)
Publish this at "default._bimi.<yourdomain>", not at the domain itself.
What goes where
- Host
- default._bimi.<yourdomain>
- Type
- TXT
- l= (logo)
- empty
- a= (authority evidence)
- not published
- This builds the record from the URLs you give it. It does not fetch either of them, so whether the SVG is a valid Tiny PS document, and whether the PEM is a certificate at all, is not checked here - the BIMI checker next door fetches the SVG and reads it against the profile.
- Google says it can take up to 48 hours for BIMI to start working after the record is published; Yahoo gives no figure, and also wants bulk volume with sufficient reputation and engagement before it shows a logo.
- BIMI and SVG Tiny Portable/Secure are both Internet-Drafts dated 1 May 2026 that expire on 2 November 2026, so the record syntax this builds can change with the next revision.
What this is
This BIMI record generator writes the "v=BIMI1" TXT record for the default selector from two addresses - where the SVG logo is served, and where the certificate is, if you have one - and tells you straight away whether the DMARC policy you already publish lets a receiver act on it.
An assertion record is a short tag-value string with one required tag that matters: "l=", the HTTPS address of the logo. "a=" is optional in the draft and names the certificate that attests you own the mark. Draft-14 insists "v=BIMI1" is spelled exactly that way and comes first; the other tags may appear in any order.
The host is what trips people up more often than the value. The record goes at a subdomain named "_bimi" under a selector - "default._bimi.yourdomain.com" for the selector every message uses unless it carries a BIMI-Selector header of its own.
How to read the result
The record in the box is the whole value to paste into one TXT record. Everything above it is about whether a receiver will act on it: the DMARC line, and whether you are publishing with a certificate or self-asserting.
Nothing here opens either URL. Whether the file at the end of "l=" really is an SVG Tiny Portable/Secure document - one <svg> root, the right namespace, no script, under 32 KB - is a separate question, and the BIMI checker is the tool that fetches it and answers it.
A warning is not a syntax error. A record built while DMARC is still at "p=none" is perfectly valid and perfectly ignored, which is why the policy you publish today is one of the three inputs.
Common mistakes
What goes wrong most often, and how to tell.
- Putting the record on the domain itselfThe value is right and nothing happens, because a receiver only ever queries the selector subdomain: "default._bimi.yourdomain.com". Google's own detailed steps give that exact host name.
- Writing v=bimi1 or BIMI=1The draft says the version value must match precisely and must be the first tag, and that receivers must not attempt to fix syntactical or capitalisation errors. A record with the version written any other way is ignored outright rather than repaired.
- Adding pct=100 to DMARC because a BIMI page said soThe BIMI draft and Google both ask for it where the policy is quarantine and the tag is present, but RFC 9989 of May 2026 lists "pct" as historic and no longer defines it. Leaving the tag out altogether satisfies both readings; adding it to a new record follows neither cleanly.
- Expecting an http:// or a PNG URL to be toleratedBoth are hard stops in the draft: HTTPS is the only supported transport for the location tag, and a URI ending in any image suffix other than SVG or SVGZ makes evaluating the record a permanent error.
How it works
- 1. Get DMARC to enforcement firstQuarantine or reject, on the organizational domain and its subdomains. BIMI Group makes this step one of its implementation guide, and the draft stops processing entirely below it.
- 2. Export the logo as SVG Tiny PSTwo things are required: a non-empty <title>, by the SVG Tiny PS draft, and dimensions in absolute pixels of at least 96 each, by Google. A square aspect ratio, a centred mark and a solid background are recommendations rather than rules - BIMI Group lists them under "consider the following", Google under its own recommendations - and the SVG Tiny PS draft has no aspect-ratio rule at all, so a non-square logo is not invalid.
- 3. Serve both files over HTTPSGoogle says the web server hosting your BIMI files must use HTTPS and recommends TLS 1.2 or later. Put the SVG, and the PEM if you have one, somewhere that answers an anonymous request.
- 4. Publish the record and waitOne TXT record at "default._bimi" plus your domain, with the value from this page. Google says it can take up to 48 hours for BIMI to start working.
Questions
What people ask about this tool.
- Not by the draft - it says that if the tag is absent it is assumed to have an empty value. In practice it depends on the provider: Google says Gmail and other email clients support BIMI only with PEM files, while Yahoo says it does not currently require a VMC for a logo to appear in its applications.
- In a TXT record at "default._bimi" under your domain - "default._bimi.yourdomain.com" - because the draft says all BIMI preferences are published in subdomains named "_bimi", and "default" is the selector a message uses unless it carries a BIMI-Selector header.
- You can, and the record will be valid, but no receiver following the draft will act on it: processing must not happen when the policy for the domain or its organizational domain is "p=none", or when a subdomain policy of "sp=none" is present. The warning on this page is about that, not about syntax.
- Google says the logo must be trademarked with an intellectual property office recognised by VMC issuers and that the trademark process can take 6 to 12 months; where the logo is not trademarked, it points to a CMC instead. Prices and issuers are not listed here - BIMI Group keeps the list of mark certificate issuers.
Sources
Every fixed value here comes from the provider’s own documentation. These pages change, so each says the day it was last read.
- IETF, “Brand Indicators for Message Identification (BIMI), draft-brand-indicators-for-message-identification-14” read 13 October 2026
- IETF, “SVG Tiny Portable/Secure, draft-svg-tiny-ps-abrotman-12” read 13 October 2026
- BIMI Group, “Creating BIMI SVG Logo Files” read 13 October 2026
- BIMI Group, “Implementation Guide” read 13 October 2026
- Google Workspace Admin Help, “Set up BIMI” read 13 October 2026
- Google Workspace Admin Help, “Add a BIMI TXT record to your domain (detailed steps)” read 13 October 2026
- Yahoo Sender Hub, “BIMI - senders.yahooinc.com” read 13 October 2026
- IETF, “RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)” read 13 October 2026
Use it from the API
The same check, as one request.