BIMI Record Check for Agencies: What to Review Before Promising Logo Display

A BIMI record check looks for a TXT record at default._bimi.example.com and reviews whether it points to the expected logo policy information. A visible BIMI record does not guarantee mailbox providers will show a logo. Agencies should treat BIMI as a brand-indicator configuration signal that depends on broader email-authentication posture, provider support, logo requirements, and client expectations.

Use Inbox Pulse to check visible public email-authentication DNS records, including BIMI where supported. Use the free 10-domain agency audit when the client-domain review should include broader SSL, DNS, and domain-health signals. Review the CertPilot methodology when explaining that these are public DNS configuration checks, not inbox-placement guarantees.

Quick answer: BIMI record check

A BIMI record check answers a narrow question: does the domain publish a BIMI TXT record at the expected selector, and does that record appear to reference the expected logo location and optional certificate information?

The common default location is:

default._bimi.example.com TXT "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem"

The DNS record is only one part of BIMI readiness. Agencies also need to review DMARC policy posture, logo file requirements, certificate expectations, provider support, and whether the client understands that logo display is never guaranteed by DNS alone.

What BIMI is

BIMI stands for Brand Indicators for Message Identification. It allows a domain owner to publish a DNS record that points to brand logo information for supporting mailbox providers.

In agency language, BIMI is a public brand-indicator signal connected to email authentication. It is not the same as SPF, DKIM, or DMARC. It depends on the broader authentication foundation and on mailbox-provider support.

BIMI is usually relevant when a client asks:

• "Can our logo show next to emails?"
• "Why does one mailbox show the logo but another does not?"
• "What does this default._bimi DNS record do?"
• "Can the agency set up BIMI after DMARC?"

The right answer is cautious: agencies can help review and configure the public DNS signal, but they should not promise logo display.

Where BIMI records live in DNS

BIMI is usually published as a TXT record under a selector. The default selector is default, so the DNS name is:

default._bimi.example.com

A BIMI TXT record normally starts with:

v=BIMI1

It may include:

• l= for the logo URL.
• a= for an assertion or certificate URL where required or supported.

Some organizations may use a selector other than default, but agencies should not invent selector names. Start with the client's actual setup, vendor instructions, and the mailbox providers involved.

Why BIMI depends on other email-authentication signals

BIMI is downstream from the basic email-authentication foundation. Before spending time on BIMI, agencies should review:

• MX routing context.
• SPF sender coverage.
• DKIM selectors for active platforms.
• DMARC record and policy posture.
• Alignment for legitimate senders.
• Domain ownership and DNS control.

The email authentication guide for agencies gives the broader model. The DMARC policy guide is especially important because BIMI expectations commonly involve a stronger DMARC posture than p=none, depending on provider requirements.

BIMI and DMARC policy expectations

Many BIMI conversations eventually become DMARC conversations. If a client wants BIMI, review DMARC first:

• Does the domain publish DMARC?
• Is the policy still p=none?
• Are legitimate senders aligned?
• Are subdomains handled intentionally?
• Are aggregate reports being reviewed?

Do not move a client to p=reject just because they want BIMI. DMARC policy progression should be based on sender alignment and operational readiness, not logo desire. A brand goal should not override mail-flow safety.

Logo and certificate expectations

A BIMI record may point to a logo file, commonly an SVG profile that must meet specific requirements. Some mailbox providers may also expect a Verified Mark Certificate or another certificate/assertion mechanism for logo display.

Agencies should set expectations carefully:

• The logo file may need a specific SVG format.
• The logo URL needs to be publicly reachable.
• The brand mark may need legal or certificate review.
• Requirements vary by provider and can change.
• A technically visible BIMI DNS record is not the same as provider acceptance.

If the client expects guaranteed logo display, pause and clarify the limitation before proceeding. The BIMI Group is the primary standards-oriented external starting point for BIMI background: bimigroup.org.

Why logo display is not guaranteed

BIMI does not force inboxes to show a logo. Supporting providers make their own decisions based on authentication, policy, certificates, reputation, user interface rules, and provider-specific requirements.

A logo may not appear even when:

• A BIMI DNS record exists.
• DMARC is configured.
• The logo URL is reachable.
• The client has a certificate.
• One mailbox provider displays it successfully.

Agencies should avoid promising "we will make your logo appear in inboxes." A safer promise is: "We can review the public BIMI DNS configuration and related authentication prerequisites, then identify what still needs provider, certificate, or platform review."

Common BIMI review findings

| BIMI signal | What it means | What it does not prove | Agency action | |---|---|---|---| | No BIMI record | No visible BIMI TXT at checked selector | The domain cannot ever use BIMI | Review DMARC and brand readiness first | | BIMI record present | DNS publishes v=BIMI1 | Logo will display in inboxes | Check logo URL, certificate, and prerequisites | | Logo URL missing | Record may be incomplete | BIMI is impossible forever | Confirm intended setup and vendor guidance | | Logo URL unreachable | Mailbox providers may not fetch it | DNS is the only issue | Fix hosting and validate file requirements | | DMARC weak or missing | BIMI prerequisites may not be met | p=reject is automatically safe | Review sender alignment before policy changes | | Certificate reference present | Certificate URL is published | Provider acceptance is automatic | Confirm certificate validity and provider expectations |

What agencies should tell clients

Use plain language:

"BIMI is a public DNS signal that can support brand logo display where mailbox providers support it. It depends on email authentication and provider requirements. We can check whether the DNS record and related signals are present, but no DNS record can guarantee logo display everywhere."

This framing protects the agency and gives the client a practical next step. It also prevents BIMI from being sold as a deliverability product. BIMI is brand-adjacent and authentication-adjacent, not a replacement for deliverability work.

BIMI review checklist

Before recommending BIMI work, check:

• [ ] Does the domain publish SPF?
• [ ] Does each important sender have DKIM configured?
• [ ] Does the domain publish DMARC?
• [ ] Is DMARC policy posture appropriate for BIMI goals?
• [ ] Are legitimate senders aligned?
• [ ] Does a BIMI record exist at default._bimi or another known selector?
• [ ] Does the record start with v=BIMI1?
• [ ] Does the l= logo URL resolve publicly?
• [ ] Does the logo file meet the relevant format expectations?
• [ ] Is a certificate or assertion URL required for the client's target providers?
• [ ] Has the client been told that logo display is not guaranteed?

What Inbox Pulse can check

Inbox Pulse can check visible public DNS/email-authentication signals, including whether a BIMI record appears to exist where supported. It can help agencies find missing or obvious configuration gaps during client-domain QA.

It does not validate every visual, legal, trademark, certificate, provider-specific, or mailbox-display requirement. It does not read inboxes, send test emails, guarantee logo display, or replace a provider-specific BIMI rollout review. Use it as an initial configuration check before deeper manual review.

What a BIMI check cannot prove

A BIMI record check cannot prove:

• The logo will appear in Gmail, Apple Mail, Yahoo, Outlook, or any specific inbox.
• The logo file satisfies every provider's current requirements.
• The brand mark is legally cleared.
• A certificate is valid for every provider's expectations.
• DMARC enforcement is safe for the client.
• Deliverability will improve.

It proves only what public DNS appears to publish at the checked BIMI selector.

Related Resources

• Email authentication for agencies
• DMARC policy: none, quarantine, and reject
• DMARC, SPF, and DKIM explained for agency operations
• DKIM selectors cheat sheet
• Google bulk sender DMARC guide for agencies

Frequently Asked Questions

What is a BIMI record check?

A BIMI record check looks for a public DNS TXT record, usually at default._bimi.example.com, that begins with v=BIMI1. The check reviews whether the domain publishes BIMI configuration and whether the record points to expected logo or certificate information. It does not prove that mailbox providers will display the logo.

Does BIMI guarantee logo display?

No. BIMI does not guarantee logo display. Mailbox providers decide whether to show a logo based on their own support, authentication requirements, certificate expectations, reputation signals, and interface rules. A visible BIMI record is only one configuration signal. Agencies should never promise that a logo will appear everywhere just because the DNS record exists.

Should agencies set up BIMI before DMARC?

Usually no. BIMI should come after the basic email-authentication foundation is understood. Review SPF, DKIM, DMARC policy, alignment, and sender inventory first. If the domain has no DMARC record or legitimate senders are not aligned, BIMI work is premature. A logo project should not create rushed DMARC enforcement.

What DNS name should I check for BIMI?

The common BIMI DNS name is default._bimi.example.com, where example.com is the client domain. Some setups may use a different selector, but default is the normal starting point. Agencies should check actual vendor or provider instructions before assuming a custom selector.

Can Inbox Pulse validate the BIMI logo file?

Inbox Pulse can help check visible public DNS configuration, including BIMI record presence where supported. It should not be treated as complete validation of every BIMI logo, certificate, trademark, provider-specific, or legal requirement. Manual review is still needed for brand assets and mailbox-provider expectations.

Is BIMI a deliverability tool?

BIMI is not a deliverability guarantee. It is a brand-indicator configuration connected to email authentication. Good authentication can support trust, but inbox placement depends on many other factors, including sender reputation, engagement, complaints, bounces, content, list quality, and mailbox-provider behavior.