BIMI Record Generator
Build the BIMI DNS record to publish, point it at your hosted logo and copy the exact TXT record for your DNS. Free, no signup.
Logo not ready yet? Make it BIMI-compatible first →
Used to show the exact host name to publish. The record itself doesn't contain it.
The public HTTPS URL where your BIMI-ready SVG is hosted.
Advanced: selector and VMC
Almost always 'default'. Change it only if you publish multiple BIMI logos.
Only if you already have a certificate. Link to your Verified (or Common) Mark Certificate .pem. It gets added to the record as the a= tag.
Your BIMI record
Publish this as a TXT record in your DNS.
default._bimi.yourdomain.comv=BIMI1; l=;Click the record to select all of it.
Record type: TXT · TTL: your provider’s default (e.g. 3600) is fine.
After you publish
- Add the TXT record at your DNS host and allow up to an hour for propagation.
- Verify it with the free BIMI checker.
- If the logo still doesn’t show, confirm DMARC is enforced and that a valid VMC is in place. Those are the two most common blockers.
Without a VMC, most major inboxes won't show your logo
Palisade's white-glove team sets up your BIMI and verified checkmark end to end, from DMARC enforcement to the published record.
Set up BIMI for meWant it done in 30 days instead of two years?
Signet is our sister company. They handle the trademark, the DMARC enforcement, and the Verified Mark Certificate end to end — the three things that stall a BIMI project for eighteen months.
Start the clockWhat is a BIMI record generator?
A BIMI (Brand Indicators for Message Identification) record is a single TXT entry in your DNS that tells supported inboxes where to find your brand logo and the certificate that vouches for it. The syntax is short but unforgiving: the logo has to be hosted over HTTPS in the right SVG format, most inboxes now require a VMC in the a= tag, and none of it displays unless DMARC is already enforced. This generator assembles the record from plain inputs and flags the blockers that quietly stop logos from showing. Prepare the logo itself with the BIMI SVG converter, then once the record is live, verify it with the BIMI checker and read the step-by-step guide to creating a BIMI record.
Email authentication knowledge base
How do I create a BIMI record?
A BIMI record is a single TXT entry in your DNS. Publish it at the host default._bimi.yourdomain.com with the value v=BIMI1; l=<logo-url>; a=<vmc-url>, where l= is the HTTPS URL of your BIMI-ready SVG logo and a= is the URL of your Verified Mark Certificate. The generator above assembles the exact string; the two things you supply are the hosted logo URL and, for most inboxes, the VMC. Before any of it displays, your domain must already have DMARC at enforcement.
Where do I publish the BIMI record?
In your domain's DNS, wherever you manage it: Cloudflare, GoDaddy, Route 53, your registrar, or your MSP's DNS console. Create a TXT record, set the host or name field to default._bimi (some providers want the full default._bimi.yourdomain.com), paste the generated value, and save. Separately, host the SVG file itself at a public HTTPS URL and reference that URL in the l= tag. Propagation is usually minutes but can take up to an hour.
Do I need a VMC for BIMI to work?
For the logo to actually display in most supported inboxes, including Gmail, yes. A Verified Mark Certificate (VMC) is issued by a certificate authority after they verify you own a registered trademark of the logo, and the a= tag points to it. The record is technically valid without a VMC, but major mailbox providers won't show the logo until one is present. Requirements vary by provider, and a Common Mark Certificate (CMC) is an alternative path for some logos that aren't trademarked.
What does the DMARC policy have to be for BIMI?
BIMI is only honoured when your domain publishes DMARC at enforcement, a policy of quarantine or reject, applied to 100% of mail. If you're still on p=none (monitoring), no inbox will display your logo, no matter how perfect the record and logo are. This is the single most common reason BIMI 'doesn't work'. Get DMARC to enforcement first with the DMARC checker and generator, then publish BIMI.
Why isn't my logo showing even though the record is published?
The two usual causes are DMARC and the VMC. BIMI needs DMARC at quarantine or reject, with no legacy pct value below 100, if you're still on p=none, nothing shows. After that, most providers require a valid VMC referenced in the a= tag. Beyond those, check that the SVG URL is reachable over HTTPS, the file is valid SVG Tiny P/S, and enough time has passed for DNS and provider caches to refresh. The BIMI checker will point at whichever piece is missing.
How do I make my logo the right format for the l= tag?
The l= tag must point to an SVG in the SVG Tiny Portable/Secure (P/S) profile: square, with the correct profile attributes and a <title>, and no scripts, animation, external references, or raster images. A logo exported straight from a design tool usually fails several of these. Use the BIMI SVG converter to fix an ordinary SVG into the required format, host the result, then paste its URL here.
What's the difference between this generator and the BIMI checker?
The generator builds the record you should publish; the checker reads what your domain currently has and tells you why the logo is or isn't displaying. Typical flow: build the record here, publish it, then run the checker to confirm everything resolves. If you're auditing a domain you already manage, start with the checker.
BIMI requires a DMARC policy at enforcement. Here are the DMARC tags you'll configure first.
- vVersion
- The Version tag is essential in a DMARC record and must strictly be set to ‘DMARC1’. If this value is not correctly specified or if the tag is absent, the DMARC record will not be considered valid and will be disregarded.
- pDMARC policy
- The DMARC policy setting is crucial and accepts three possible values: ‘none’, ‘quarantine’, or ‘reject’. By default, it is set to ‘none’, which means it doesn’t actively intervene with emails that fail authentication. This setting primarily serves to gather DMARC reports, aiding in understanding the existing email traffic and its authentication status. On the other hand, the ‘quarantine’ option flags unauthenticated emails as dubious, and ‘reject’ outright prevents their delivery.
- ruaAggregate report destination
- The destination for sending aggregate reports is specified using a ‘mailto:’ URI, which Email Service Providers (ESPs) utilize to dispatch failure reports. While this tag is not mandatory, omitting it means you will not receive any reports.
- rufForensic report destination
- The destination for Forensic (Failure) report transmission is designated by a ‘mailto:’ URI, which is employed by Email Service Providers (ESPs) for the delivery of failure reports. Although this tag is not obligatory, failing to include it will result in not receiving any reports.
- spSubdomain policy
- The policy for subdomains defaults to inheriting the main domain’s policy tag (p=), as previously described, unless explicitly stated otherwise. Similar to the domain policy, the permissible values for subdomains are ‘none’, ‘quarantine’, or ‘reject’. However, this option is not commonly employed in current practices.
- adkimDKIM alignment
- The alignment of the DKIM signature, indicated by this tag, refers to the congruence between the DKIM domain and the originating domain in the ‘Header From’. The acceptable values for this tag are ‘r’ for relaxed and ‘s’ for strict. The default setting, ‘r’, permits a partial match between these domains, whereas the ‘s’ setting demands an exact match of the domains.
- aspfSPF alignment
- This tag pertains to the SPF alignment, which concerns the compatibility between the SPF domain (the sender) and the domain in the ‘Header From’. It allows two settings: ‘r’ for relaxed and ‘s’ for strict. By default, it is set to ‘r’, which tolerates a partial match between the domains. In contrast, the ‘s’ setting necessitates an exact correspondence of the domains.
- foForensic reporting options
- The options for forensic reporting include ‘0’, ‘1’, ‘d’, and ‘s’. The default setting is ‘0’, which triggers a forensic report only when both SPF and DKIM alignments do not pass. Use ‘1’ if the outcome of either SPF or DKIM is anything other than a pass. The option ‘d’ is selected to generate a report specifically for DKIM validation failures, and ‘s’ is used for SPF-related issues. To actually receive these forensic reports, it’s necessary to specify the ‘ruf’ tag.
- rfFailure report format
- The format for failure report generation can be set to either ‘afrf’ or ‘iodef’, as these are the two permissible options.
- pctPercentage (historic)
- The legacy Percentage tag asked receivers to apply a quarantine or reject policy to only part of the mail that failed DMARC. RFC 9989 removed pct because receivers implemented partial enforcement inconsistently. New records should omit it and stage rollout with aggregate reports, whole-policy changes, and low-volume subdomains.
- riReporting interval
- The Reporting interval specifies how often XML reports are received, measured in seconds. The standard setting is 86400 seconds, which equates to daily reporting. However, it’s important to note that despite the specified interval, Internet Service Providers (ISPs) typically send these reports on their own schedules, which in most cases, is also once a day.