Skip to content
Sales Pitch
Menu
English

5 Quick Commands to Verify Your BIMI Record and SVG for Email Admins

, 17 min read

5 Quick Commands to Verify Your BIMI Record and SVG for Email Admins

Decorative BIMI verification title card

A correctly configured BIMI setup requires three things working together: SPF or DKIM aligned to your visible From domain, DMARC enforced at p=quarantine or p=reject, and a BIMI TXT record pointing to an HTTPS-hosted SVG that passes the BIMI Group’s SVG Tiny-PS validation. Some mailbox providers, including Gmail, also require a Verified Mark Certificate before they display your logo. Start by checking your DMARC policy and alignment status before touching DNS for BIMI itself.

TL;DR:

  • Ensuring DMARC enforcement at p=quarantine or p=reject with aligned SPF or DKIM is essential before deploying a BIMI record, or else the logo will not display.
  • The SVG logo must adhere to strict Tiny-PS profile specifications, be simplified, and tested via the BIMI validator to avoid fetch and rendering failures.
  • Hosting the SVG and certificate files on a stable HTTPS URL with correct headers, no redirects, and no authentication is critical for successful logo fetches by inbox providers.
  • Some providers, like Gmail, require a verified mark certificate to display your logo, which involves a months-long registration process for trademark proof.
  • Proper BIMI DNS records include the mandatory version tag, logo URL, and optionally a certificate URL, with exact formatting and cautious TTL management to ensure reliable propagation and validation.
Usesalespitch
Strengthen Your Email Outreach
Explore practical insights, templates, scripts, and tools for improving cold email strategies and email deliverability.

Table of Contents

Authenticate and align SPF, DKIM, and DMARC first

BIMI sits on top of your existing authentication stack, so nothing works until that stack is solid. DMARC alignment means the domain in your DKIM signature, or the domain used for SPF, matches the domain shown in the visible From header. At least one of the two must align: both failing means DMARC fails regardless of what your BIMI record says.

According to the BIMI Group’s implementation guide, BIMI depends on DMARC enforcement at the organizational domain, aligned SPF or DKIM, and a BIMI TXT record with the v= and l= tags set correctly. “Enforcement” means a policy of p=quarantine or p=reject, not p=none, and ideally with pct=100 so the policy applies to all mail. A subdomain can inherit DMARC enforcement from its organizational domain, but check your sp= tag if subdomains send mail independently.

Before changing anything, run these checks:

  • Query your DMARC record with dig TXT _dmarc.yourdomain.com and confirm the policy tag.
  • Send a test message to a mailbox you control and inspect the authentication results header for dmarc=pass and alignment details.
  • Review DMARC aggregate reports for the past few weeks to confirm your legitimate sending sources are passing alignment consistently.

BIMI depends on DMARC enforcement at the organizational domain, aligned SPF or DKIM, and a correctly formatted BIMI TXT record, according to the BIMI Group. Skip any of the three and providers will quietly ignore your logo, with no error returned to you.

Your logo file has to meet the SVG Tiny-PS profile, a restricted subset of SVG built for security and predictable rendering. The BIMI Group’s SVG guidance lists the required attributes and the elements you need to strip out before a validator will accept the file.

  1. Set baseProfile="tiny-ps" and version="1.2" on the root <svg> element.
  2. Remove x and y attributes from the root element; BIMI rejects files that include them.
  3. Strip scripts, external references, and embedded fonts: Tiny-PS does not permit any of them.
  4. Keep the file reasonably small, which usually means running it through SVGO to flatten paths and drop metadata.
  5. Design the artwork as a square, centered, with a solid background and no fine detail near the corners, since some clients render the logo inside a circular crop.

Many teams automate this with an SVGO pipeline in their build process so every export comes out validator-ready instead of relying on manual cleanup each time. If your design team needs help simplifying a logo for this format, brand studios like CreativeCo work on exactly this kind of visual simplification.

Pro Tip: Test your SVG in the BIMI Group’s validator before you publish any DNS record. A rejected file wastes a DNS propagation cycle you didn’t need to spend.

Host your logo and certificate with the right headers

Mailbox providers fetch your SVG and certificate over HTTPS at send time or on a caching schedule, so the hosting setup matters as much as the file itself. Both files need to sit at a stable, publicly reachable URL with no login wall and no redirect chain.

  • Serve the SVG with a Content-Type: image/svg+xml header: a mismatched MIME type is one of the most common causes of a failed fetch.
  • Serve the certificate as a .pem file with a plain text or application/x-pem-file content type, not wrapped in HTML.
  • Avoid CORS restrictions that block automated fetchers, and avoid authentication gates entirely.
  • Set a reasonable cache TTL: too short increases load on your server, too long delays how fast providers see an updated logo.

Check both URLs with curl -I https://yourdomain.com/logo.svg and confirm a 200 OK status with the correct content type before you reference the file in DNS.

Understand when you need a Verified Mark Certificate

A Verified Mark Certificate, or VMC, proves you legally own the logo you’re publishing. Some mailbox providers, Gmail among them, require one before they’ll render your BIMI logo, while others display logos without it as long as authentication and SVG requirements pass.

  • VMCs are issued by Mark Verifying Authorities after you submit proof of a registered trademark, typically from an office like the USPTO, EUIPO, or UKIPO.
  • According to the BIMI Group, obtaining a VMC can take months depending on jurisdiction and the completeness of your trademark documentation, so start the application well before a planned rebrand or launch.
  • Use a staging selector such as test._bimi.yourdomain.com to validate a new certificate or logo without touching your production default._bimi record.

Publish the BIMI TXT record correctly

The BIMI record itself is a TXT record published at a selector under _bimi in your DNS zone. The canonical form looks like this:

default._bimi.yourdomain.com TXT "v=BIMI1; l=https://yourdomain.com/logo.svg; a=https://yourdomain.com/cert.pem"
Tag Required Purpose
v= Yes Declares the record version, always BIMI1
l= Yes HTTPS URL to the SVG logo
a= No HTTPS URL to the VMC or CMC certificate
  • A missing v= tag causes receivers to discard the entire record rather than attempt a partial read, per the IETF BIMI draft.
  • Escape semicolons correctly in your DNS provider’s interface, since many panels require quoting around the full TXT value.
  • Selector lookups check selector._bimi.AuthorDomain first and fall back to default._bimi.organizational-domain; multiple or conflicting records stop BIMI processing for that message entirely.
  • Keep TTL modest (300 to 3,600 seconds) while testing, then raise it once the record is stable.

Test your setup and fix the most common errors

Run through this sequence after publishing, and keep each step’s output so you can compare against expected results:

  1. Resolve the TXT record with dig TXT default._bimi.yourdomain.com and confirm the string matches what you published.
  2. Fetch the SVG with curl -I and confirm a 200 status and image/svg+xml content type.
  3. Fetch the certificate the same way and confirm it returns without a login prompt or redirect.
  4. Send a test message through your production sending infrastructure and inspect the authentication headers for DMARC alignment.
  5. Check logo rendering in a supporting client, keeping in mind that some providers delay display by caching results for up to 48 hours or more, per Google’s own DKIM guidance.

The BIMI Group’s troubleshooting documentation lists the errors admins hit most often: SVG_FETCH_ERROR from an oversized file or wrong MIME type, DNS syntax errors from unescaped semicolons, and DMARC failures from a policy still set to p=none. Hosting mistakes, including wrong MIME types, unexpected redirects, and authentication gates, cause failures even when the DNS record and SVG are both correct, so isolate the hosting layer first with a curl check before re-examining DNS.

Pro Tip: If the logo doesn’t appear after 48 hours and every check above passes, confirm whether the receiving provider requires a VMC. A perfectly valid record without one simply won’t render in Gmail.

A quick checklist and commands you can run right now

  1. Confirm DMARC: dig TXT _dmarc.yourdomain.com, policy must read p=quarantine or p=reject.
  2. Confirm SPF or DKIM alignment on a real test message’s authentication headers.
  3. Validate your SVG against the Tiny-PS profile and confirm file size is near 32 kilobytes.
  4. Confirm hosting: curl -I on both the SVG and certificate URLs, expecting 200 OK and correct content types.
  5. Confirm the BIMI TXT record: dig TXT default._bimi.yourdomain.com matches your published string exactly.

If DMARC fails, fix authentication before touching BIMI. If the SVG fetch fails, check MIME type and file size before re-checking DNS.

Why BIMI setup is worth the effort for brand visibility

A correctly rendered BIMI logo sits next to your sender name in the inbox, giving recipients a visual cue that the message is legitimate before they open it. That visibility matters most for brands recipients already recognize, since a familiar logo next to a familiar name reinforces trust at the exact moment someone decides whether to open or delete.

The BIMI Group frames BIMI as a reward layered on top of authentication rather than a replacement for it: the logo only appears once SPF, DKIM, and DMARC are already working correctly, so pursuing BIMI often forces teams to clean up authentication gaps they had been ignoring. That side effect alone improves deliverability independent of whether the logo ever renders.

For marketing teams running cold outreach or lifecycle campaigns, brand visibility in the inbox is one of the few deliverability levers that also doubles as a recognition tool. A recipient who has seen your logo in a BIMI-enabled inbox is more likely to recall your brand later, even in a channel like cold email where recipients have no prior relationship with you. The visual signal does not fix a bad subject line or a spammy sending pattern, but it compounds the value of every other deliverability fix you make.

What your SPF and DKIM records need beyond basic setup

BIMI assumes your SPF and DKIM configurations are not just present, but correctly scoped. A loose SPF record, one that includes too many third-party senders or exceeds the 10 DNS lookup limit, will fail silently and break alignment without any obvious warning.

For SPF, list only the services that actually send mail on your domain’s behalf, and keep the lookup count under the limit by flattening includes where possible. For DKIM, rotate keys periodically and verify the selector your sending platform uses actually matches what’s published in DNS. A mismatched or missing DKIM selector is a frequent, easy-to-miss cause of failed alignment, especially after switching email service providers without updating DNS.

Both SPF and DKIM need to point to the domain shown in your visible From header, not just the domain in your envelope sender, since BIMI and DMARC alignment check against the header domain recipients actually see. Teams that send from multiple subdomains, one for marketing, another for transactional mail, need DKIM and SPF configured separately for each, since alignment does not automatically extend across subdomains without an explicit DMARC subdomain policy.

Run your checks on a live message, not just a DNS lookup, since alignment is evaluated per message based on the actual headers sent, not just what’s theoretically published.

The practical sequence for creating and publishing your record

Once authentication passes consistently, the actual BIMI record creation follows a fixed order. Confirm DMARC enforcement first, since publishing a BIMI record before DMARC reaches p=quarantine or p=reject wastes the effort: providers will ignore the record entirely.

Next, finalize your SVG and host it at a permanent URL, since changing that URL later means another round of DNS propagation and cache delays. Decide at this stage whether you’re pursuing a VMC, since that decision affects whether your TXT record includes an a= tag from day one or gets added later.

Publish the TXT record at default._bimi.yourdomain.com, or at a named selector if you’re running a staged rollout. Verify the record resolves correctly with a DNS lookup, then verify the SVG and certificate both return correct headers over HTTPS. Send a test message through your actual sending infrastructure, not a sandbox, since some providers only evaluate BIMI eligibility on production-volume sending patterns.

Six-step BIMI publishing and verification sequence

Expect a delay between a correctly published record and visible rendering. Caching and reputation checks on the provider side mean a technically perfect setup can still take time to show up, so budget a testing window of several days rather than expecting immediate results after DNS propagation completes.

Getting a Verified Mark Certificate: process and cost expectations

A VMC is issued by a Mark Verifying Authority after reviewing your trademark documentation, not by your DNS provider or email service. The process starts with confirming you hold a registered trademark in a supported jurisdiction, commonly through offices like the USPTO, EUIPO, or UKIPO, and gathering the registration documents the certificate authority requires.

From there, you submit an application to a Mark Verifying Authority, which checks your trademark registration against the logo you intend to publish and confirms organizational ownership. According to the BIMI Group, this process can take months depending on jurisdiction and documentation completeness, so initiating it well ahead of a planned launch or rebrand avoids display downtime.

Administrators often underestimate the coordination this requires across legal, brand, and IT teams, since trademark documentation usually sits with legal while the technical implementation sits with IT. Starting the certificate authority conversation early, even before your SVG and DNS work is finished, keeps the two tracks moving in parallel instead of blocking each other. If your organization is mid-rebrand, use a staging selector to test your new logo and certificate without disrupting whatever is currently live on your production BIMI record.

How BIMI support differs across inbox providers

Not every mailbox provider treats BIMI the same way, and that inconsistency is one of the most common sources of confusion for admins who’ve done everything correctly. Some providers display a logo as soon as authentication, SVG, and DNS all pass. Others, including Gmail, require a Verified Mark Certificate on top of that before anything renders.

This means two recipients at different providers can receive the identical message and only one sees your logo, even though your BIMI record is published correctly for both. That isn’t a bug in your setup: it reflects each provider’s own policy on what evidence they require before trusting a logo claim.

Client-side support varies too. Webmail interfaces tend to support BIMI more consistently than some desktop or mobile mail clients, where rendering depends on the client version and whether it has adopted the BIMI specification at all. Google’s own documentation notes that even correctly configured senders can see delayed rendering due to caching and reputation checks, sometimes for 48 hours or longer.

Email logo rendering varies by provider

The practical implication is that you should not treat a missing logo at one provider as proof your setup is broken. Check your DNS, SVG, and certificate independently against the requirements, confirm the message passes authentication, and then be patient with provider-specific rendering timelines before assuming something needs fixing.

Common BIMI record variations you’ll encounter

Most BIMI records follow the same basic shape, but a few variations come up often enough to know in advance. A record without a certificate looks like this:

default._bimi.yourdomain.com TXT "v=BIMI1; l=https://yourdomain.com/logo.svg;"

This form is valid where the receiving provider does not require a VMC, and it’s a common starting point for teams still working through certificate authority paperwork. Once a certificate is ready, the a= tag gets appended without changing anything else in the record.

Organizations testing a new logo or certificate often publish a second record under a named selector rather than overwriting their production record:

test._bimi.yourdomain.com TXT "v=BIMI1; l=https://yourdomain.com/logo-draft.svg; a=https://yourdomain.com/cert-draft.pem"

This lets you validate rendering and fetch behavior without any risk to the logo currently showing in live inboxes.

A record with no logo URL at all, just v=BIMI1;, is technically used in some provider documentation to indicate an intentional opt-out for a subdomain, though this usage is less common and worth confirming against your specific provider’s requirements before relying on it. Whatever variation you publish, the v= tag always comes first and the record always resolves at a _bimi subdomain, whether that’s default or a custom selector you’ve chosen for staged testing.

Why BIMI is a visibility layer, not a deliverability fix

BIMI rewards authentication you should already have in place: it does not fix a weak sending reputation or a loose SPF record on its own. We’d treat it as the last step in a deliverability project, not the first, since chasing a logo before DMARC enforcement is solid just means a record that silently does nothing. Budget certificate and design time only after your authentication reports are clean.

— Samuel

Where to check your deliverability work before you publish

Getting BIMI to render depends entirely on authentication work holding up under real sending volume, which is exactly where most setups quietly break. A guide to what actually predicts the spam folder walks through the deliverability signals worth checking before you spend time on a logo nobody will see. Once your sending domain is clean, revisit cold email templates to make sure the message behind that logo earns the open.

Usesalespitch

FAQ

Is a BIMI record necessary?

No, BIMI is optional and does not affect whether mail is delivered or lands in the inbox. It adds a visual brand signal in supporting inboxes once your authentication, including DMARC enforcement, is already solid.

Is the BIMI record free?

Publishing the DNS record and hosting your SVG costs nothing beyond your existing domain and hosting setup. A Verified Mark Certificate, required by some providers like Gmail, involves a trademark application and a fee charged by the Mark Verifying Authority, which varies by provider and is not listed as a single fixed price.

How do I generate a DMARC record?

A DMARC record is a TXT record published at _dmarc.yourdomain.com specifying a policy tag such as p=quarantine or p=reject, which BIMI requires for display eligibility. Most DNS providers let you add this directly through their TXT record interface, and confirming it resolved correctly with a dig lookup is the quickest way to verify it’s live.

How do I create an MX record for my domain?

An MX record is added through your DNS provider’s control panel and points your domain to the mail server responsible for receiving messages, with a priority value determining order when multiple servers are listed. This record is separate from BIMI and DMARC setup, though all three live in the same DNS zone and should be checked together when troubleshooting mail flow.

More from the blog