BIMI Record Generator: A Practical Setup Walkthrough

Do not index

A BIMI record generator produces a usable TXT record only after DMARC is enforced at quarantine or reject, the logo is a valid SVG Tiny PS file hosted on HTTPS, and a VMC is in place where required. The generator assembles the final DNS value, but it can't make an unprepared domain eligible for BIMI.

A marketer can spend weeks preparing a new logo, only to discover that it doesn't appear beside outbound messages. At the same time, authentication failures, DNS mistakes, blacklist listings, or broken mail infrastructure can send campaigns to spam, reduce replies, and damage trust in the sending domain. A logo won't repair those problems, but a correctly implemented BIMI layer can help mailbox providers identify authenticated brand mail when their display policies support it.

BIMI has moved beyond a small experimental standard. From March 2021 through mid-2024, DMARC.org observed 33,924 unique and valid BIMI records remaining active in DNS, including about 3,450 records with a Verified Mark Certificate. A separate dataset reported commercial BIMI certificate issuances rising from 539 in 2021 to 6,679 in 2025, roughly a twelve-fold increase, with 4,552 issued in the first half of 2026 and 20,227 BIMI certificates across 109 countries by July 2, 2026. These figures indicate growing adoption, but they also reflect an ecosystem that still depends heavily on authentication readiness, certificate requirements, and mailbox-provider implementation. (BIMI adoption data)

Table of Contents

What a BIMI Record Generator Actually Does The record's basic fields Prerequisites Before You Open the Generator Four readiness gates Preparing the SVG Tiny PS Logo What belongs in the file Generating and Publishing the BIMI DNS Record Enter the values in order Publish at the correct DNS name Common Mistakes That Break a BIMI Rollout Validating the Record, Logo, and Certificate Four checks before testing display Putting BIMI in the Broader Authentication Picture What BIMI can and can't change

What a BIMI Record Generator Actually Does

A BIMI record generator is a formatting utility. It takes the HTTPS location of a BIMI-compatible logo and, where required, the location of a Verified Mark Certificate, then assembles a DNS TXT value that receiving systems can query.

That sounds simple because the final record is small. The difficult work happens earlier, when the domain owner authenticates every legitimate sender, enforces DMARC, prepares the logo, obtains the certificate, and hosts each asset correctly. A generator can't turn a PNG into a compliant BIMI logo, upgrade p=none into an eligible policy, or make an unavailable certificate URL work.

The record's basic fields

A generated BIMI value normally starts with v=BIMI1. It then uses:

l=, the HTTPS URL of the hosted SVG logo.

a=, the HTTPS URL of the certificate file when a VMC or CMC is required or being used.

Conceptually, the result looks like this:

v=BIMI1; l=https://brand.example/logo.svg; a=https://brand.example/vmc.pem

The value belongs at default._bimi.example.com, using the domain's apex rather than a web host such as www. The mailbox provider retrieves the TXT record, follows the URLs, validates the assets, and then applies its own display rules.

For a plain-language explanation of the relationship between BIMI and authentication, marketers and developers can read the mailX BIMI guide. A useful operational rule follows: the generator is the last publish step, not the first setup step.

Prerequisites Before You Open the Generator

A marketing team can have a valid logo and still be unready for BIMI. The generator belongs at the end of a chain: authenticated mail, enforced DMARC, a compliant SVG, and reachable certificate hosting where the receiving mailbox requires it. Check each gate before producing the TXT value.

Four readiness gates

First, verify SPF. Confirm that the sending domain authorizes every real mail provider and aligns with the visible From domain where DMARC requires alignment. SPF evaluation allows 10 DNS lookups, and include, a, mx, ptr, exists, and redirect can consume that allowance. A limit failure creates a permanent SPF error, so an apparently complete record may still fail authentication. See this SPF lookup limit guidance while reviewing nested includes.

Second, verify DKIM. Send a real test message and inspect its headers for DKIM=pass. The signature's d= domain must align with the visible From domain under the applicable DMARC alignment mode. Because DKIM uses selectors, the selector shown in the header must resolve to the public key that validates the signature. This DKIM selector and alignment guidance helps explain what to check.

Third, inspect DMARC at _dmarc. BIMI requires an enforcement policy, p=quarantine or p=reject. A p=none policy does not qualify, and the policy's percentage value should be 100. Check a live message for DMARC=pass; finding a DMARC TXT record alone is not enough. The BIMI requirements from Google Workspace describe these policy conditions.

Fourth, confirm the brand assets. The logo must be a compliant SVG Tiny PS file available through HTTPS. A VMC or CMC may be needed for mailbox-provider support. Certificate requirements vary, but Gmail requires one, so teams targeting that mailbox should confirm certificate availability and hosting before publishing. Review this BIMI generator implementation guidance for certificate-related requirements.

Prerequisite	Where to Check	Pass Result
SPF	DNS TXT lookup and a live message header	Authorized sender, no lookup-limit failure, aligned result where applicable
DKIM	Message headers and selector DNS record	`DKIM=pass`, with an aligned `d=` domain
DMARC	`_dmarc` TXT lookup and message headers	`p=quarantine` or `p=reject`, percentage set to 100, `DMARC=pass`
Logo and certificate	HTTPS fetch and certificate validation	SVG Tiny PS resolves correctly, certificate is available where required

A failed gate belongs in the troubleshooting queue, not in the generator. Publishing a correct-looking BIMI value before the authentication chain passes leaves mailbox providers with no reason to display the logo. Address the failed check, then generate and publish the record.

Preparing the SVG Tiny PS Logo

A BIMI logo isn't any vector file with an .svg extension. It must fit the SVG Tiny PS profile, a restricted format designed for secure and predictable processing by mailbox systems.

Start with a clean source file. The final asset should contain a single root <svg> element, a declared viewBox, plain integer width and height values, and elements inside the SVG namespace. Solid named colors or hexadecimal fills are generally safer than complex effects. The asset shouldn't depend on a browser, a remote stylesheet, or a designer's workstation fonts.

What belongs in the file

Allowed structure should be deliberately minimal. A logo can use ordinary vector paths and solid fills, provided the document remains compatible with the required profile.

Common exclusions include:

JavaScript and scripts: Dynamic code creates a security and rendering risk.

External references: Linked images, fonts, stylesheets, or other remote resources can fail when a provider fetches the file.

Embedded raster images: A PNG inside an SVG isn't a clean BIMI vector asset.

Foreign objects and filters: Export effects may look correct in a design application while failing provider validation.

Embedded fonts: Convert text to paths so the logo doesn't depend on a font installed elsewhere.

Exports from design applications often carry metadata, filters, unsupported dimensions, or hidden references. Removing those extras matters because a mailbox provider may validate the file without rendering it in the same environment used by the design team.

A practical preparation sequence is:

Export the logo as SVG.

Remove scripts, metadata, external resources, filters, and raster content.

Convert text to paths.

Run the document through an SVG validator and an SVGO optimization pass.

Host the final file over HTTPS.

Confirm that the server returns image/svg+xml.

Teams that need a more detailed format review can browse Bimi requirements by mailX. The final URL should be stable, publicly reachable, and free from access controls that prevent mailbox providers from retrieving it.

Generating and Publishing the BIMI DNS Record

A BIMI generator is the final step in a prerequisite chain, not a shortcut around it. Before opening the form, confirm that DMARC enforcement is in place, the SVG Tiny PS logo is publicly reachable, and the VMC or CMC certificate is hosted over HTTPS when the receiving provider requires one. Prepare the exact logo and certificate URLs first.

Enter the values in order

Use the generator fields in this sequence:

Domain: Enter the apex domain that sends the mail.

Logo URL: Paste the complete HTTPS URL ending in the SVG Tiny PS file.

Certificate URL: Paste the HTTPS URL of the VMC or CMC PEM file when required.

Generate: Review the output for v=BIMI1, l=, and a=.

The logo URL belongs in l=. The certificate URL belongs in a=. A generator may leave out a= when no certificate URL is supplied. That output can still be syntactically valid, while a mailbox provider may require the certificate before displaying the logo.

Publish at the correct DNS name

Create the record in your DNS provider's dashboard with these values:

Type: TXT

Name or host: default._bimi

Value: The generated string beginning with v=BIMI1

DNS dashboards handle host fields differently. Some automatically append the domain after you enter default._bimi; others may expect the complete hostname. Check the resulting fully qualified name rather than trusting the field label. It should resolve as default._bimi.example.com.

A record at _bimi.example.com, www._bimi.example.com, or an unrelated subdomain will not be discovered for the sending domain. If the dashboard offers separate fields for record name and value, place the generated BIMI string only in the TXT value field.

After saving, query the published record with a DNS lookup tool or a command such as dig TXT default._bimi.example.com +short. Review the response returned by DNS, including quotation marks and any escaped characters, because a control panel can display a value differently from what it publishes. Propagation may take time, and mailbox providers refresh records independently. A live TXT response confirms that DNS serves the string. It does not confirm that the logo or certificate will pass validation.

Common Mistakes That Break a BIMI Rollout

A generator can produce a correctly formatted string while the rollout still fails. The usual causes are a mismatched hostname, inaccessible asset, incompatible SVG, or certificate problem.

Mistake	Symptom	Fix
Wrong DNS hostname	The record exists, but a BIMI lookup finds nothing	Publish at `default._bimi` on the sending domain's apex
Broken HTTPS hosting	The logo or PEM cannot be retrieved, so validation stops	Return a successful HTTPS response with a valid certificate and avoid redirects
Certificate mismatch	Authentication passes, but the logo remains absent	Put the certificate URL in `a=`, use a valid X.509 BIMI certificate, and confirm it is current

Treat the DNS panel as an editor, not as proof of publication. Some panels rewrite quotation marks or escape characters, so the displayed value may look correct while the actual TXT response contains invalid syntax. Query the published record and inspect its returned content.

SVG files can fail for reasons that are invisible in a browser. Unsupported dimensions, scripts, metadata, external references, and complex effects may stop validation even when the logo renders normally on screen. Use a BIMI-compatible SVG Tiny PS file, and keep the hosted version identical to the approved asset.

The certificate URL must point to a retrievable PEM file. The certificate should be a valid X.509 BIMI certificate from a trusted authority, intended for BIMI, and currently valid. Its association with the hosted logo must also remain intact. BIMI implementation requirements

BIMI adoption remains operationally uneven. One estimate reports 20,227 BIMI certificates with 54% year-over-year growth, while another estimates about 3 million domains with enforced DMARC as the addressable BIMI market. BIMI adoption estimates The difference shows why a technically valid record does not guarantee a visible logo. Test the complete chain with the mailbox providers that matter to your sending program.

Validating the Record, Logo, and Certificate

A BIMI rollout is ready for provider testing only after the DNS value and both hosted assets pass separate checks. A single green result from a generator isn't enough because the generator may not fetch every dependency after publication.

Four checks before testing display

Query the TXT record. Confirm the published name is default._bimi on the correct domain. The returned value should begin with v=BIMI1 and contain the intended l= and a= values.

Fetch the logo URL. The response should be successful, use HTTPS, and return the image/svg+xml content type. The downloaded file should be the same optimized asset that the brand team approved, not an HTML error page served under an SVG-looking URL.

Inspect the certificate. If a certificate is present, retrieve the PEM file and verify its chain, intended use, validity, and relationship to the hosted logo. The SVG hash recorded in the certificate should match the SHA-256 hash of the file being served. An expired certificate or changed logo can invalidate an otherwise correct DNS record.

Run an independent inspection. A dedicated BIMI inspector can surface syntax, MIME, URL, and certificate mismatches in one pass. Teams can also check BIMI email status with a live diagnostic that focuses on the domain's BIMI configuration.

Brand consistency matters outside DNS, too. A logo change can affect certificates, email assets, and other identity controls, so teams reviewing visual identity may also find this resource on brand font protection by Font Checker Pro useful.

A clean validation record should capture the DNS response, logo response headers, certificate issuer and expiry state, and the date of each check. That evidence shortens future troubleshooting when a provider changes its refresh cycle or display policy.

Putting BIMI in the Broader Authentication Picture

BIMI is the visible endpoint of email authentication, not a replacement for it. The chain starts with an authorized sender and a passing SPF or DKIM result, continues through alignment and enforced DMARC, and ends with a provider deciding whether to render a verified brand mark.

DMARC reports help domain owners identify unauthorized sending sources before enforcement becomes stricter. The domain owner, DNS administrator, sending-platform team, brand team, and certificate authority should agree on the rollout record, including who owns each URL and who receives alerts when a certificate or logo changes.

What BIMI can and can't change

Correct BIMI configuration can provide a recognizable visual identity where a mailbox provider supports display. It doesn't directly repair SPF failure, DKIM misalignment, poor sender reputation, blacklist status, spam complaints, or sudden sending changes. Those signals still influence whether messages reach the inbox.

A practical operating checklist includes:

Authentication: Recheck SPF authorization and DKIM alignment for every sending service.

DMARC enforcement: Monitor aggregate reports and preserve aligned authentication before tightening policy.

BIMI assets: Test the TXT record, SVG URL, MIME type, certificate chain, and certificate expiry.

Brand changes: Treat a new logo as a coordinated DNS and certificate change, not a simple file replacement.

Provider behavior: If the logo is absent, review the provider's current requirements and rollout policy before changing the message or record.

Evidence: Store effective dates, operators, certificate issuer details, and validation results.

Teams managing automated email workflows should also explore the documentation for operational context around sending systems and authentication dependencies. AI agents can create campaigns and monitor domains, but they shouldn't send blindly. A live diagnostic layer lets an agent check authentication, DNS, blacklist status, and infrastructure before launching or modifying a workflow.

The same principle applies to human operators. A raw DNS response doesn't explain whether the next fix belongs in the sender platform, DNS panel, logo file, certificate chain, or message configuration. A combined deliverability audit can connect those signals to inbox-placement risk and provide a remediation order.

mailX is a free diagnostic suite that runs live checks across SPF, DKIM, DMARC, BIMI, MX, DNS, SMTP, IMAP, blacklist status, and related email infrastructure. It returns plain-English explanations and specific next steps, and it can also support automated workflows through API and MCP access.

Use mailX to run a free live deliverability audit before publishing BIMI, verify the authentication chain and hosted assets, and identify the exact DNS or infrastructure issue that needs attention. The audit requires no signup and helps humans and AI agents replace raw lookup results with actionable remediation steps.