Self-Asserted BIMI: Verification Problems and How to Fix Them

Estimated reading time: 13 minutes

A company publishes a BIMI record to display its logo in recipients’ inboxes. The DNS record looks correct, email authentication passes, and messages are being delivered. Yet the logo appears in Yahoo Mail but remains missing in Gmail. An email verification tool might also report that the BIMI record lacks third-party validation.

The problem often comes down to self-asserted BIMI, which allows domain owners to publish brand logos without obtaining a certificate that verifies their right to use them.

But what does this mean for email verification, sender reputation, and deliverability? Let’s examine how self-asserted BIMI works, why verification problems occur, and how senders can resolve them.

Key Takeaways

• Self-asserted BIMI records publish a brand logo without third-party certification of logo ownership.
• A self-asserted record is not automatically invalid, but mailbox providers differ in whether they accept it.
• Gmail requires a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC), while Yahoo can display self-asserted logos.
• BIMI does not replace SPF, DKIM, or DMARC, and it does not directly determine inbox placement.
• Misconfigured authentication, invalid BIMI records, and inaccessible logo files can prevent brand logos from appearing.
• Troubleshooting should distinguish BIMI verification failures from actual email deliverability problems.

What Are Self-Asserted BIMI Records?

BIMI stands for Brand Indicators for Message Identification. It allows organizations to publish a brand logo that supporting mailbox providers can display next to authenticated emails.

To participate, senders publish a BIMI TXT record in their domain’s DNS. This record identifies the logo and, when applicable, provides information about its certification.

There are two main ways to publish a BIMI record:

Self-asserted BIMI: The domain owner publishes a logo without obtaining third-party certification. The record identifies the logo’s location, but no certificate independently verifies the organization’s right to use it.

Certificate-backed BIMI: The domain owner obtains a VMC or CMC from an authorized certificate authority. The certificate verifies the organization’s identity and its association with the logo.

For example, a self-asserted BIMI record might look like this:

v=BIMI1; l=https://assets.example.com/logo.svg; a=;

Here:

• v=BIMI1 identifies the BIMI version.
• l= specifies the HTTPS location of the SVG logo.
• a= identifies the location of an evidence document, such as a VMC or CMC. Leaving it empty indicates that no such certificate is provided.

The record is typically published at default._bimi.example.com.

Importantly, self-asserted BIMI does not mean the sending domain lacks email authentication. A sender can have properly configured SPF, DKIM, and DMARC while using a self-asserted BIMI record.

The distinction concerns verification of the logo’s association with the sender, not whether the underlying email is authenticated.

Why Can Self-Asserted BIMI Records Cause Verification Issues?

Self-asserted BIMI records create limitations because publishing a logo and proving the right to use it are different processes.

Several factors can cause a BIMI verification warning or prevent a logo from appearing.

1. No Independent Verification of Logo Ownership.

With a self-asserted record, the domain owner declares which logo should represent the organization.

However, there is no independent certificate authority confirming that the logo belongs to that sender.

This creates a potential impersonation problem. An attacker who controls a domain could publish a BIMI record referencing a recognizable company’s logo, even without authorization to use that branding.

That does not mean the attacker can publish records in another organization’s DNS. It means the attacker could associate a copied logo with a domain they control.

Certificate-backed BIMI addresses this concern by requiring independent verification of the organization and its right to use the logo.

For mailbox providers that require this verification, a self-asserted record is insufficient to qualify for logo display.

2. Different Mailbox Providers Apply Different BIMI Requirements.

Not all mailbox providers support BIMI in the same way.

Gmail

Gmail requires a third-party certificate for BIMI logo display. It supports two certificate types:

• Verified Mark Certificate (VMC): Generally used for eligible registered trademarks. Gmail can display the logo alongside a verified checkmark.
• Common Mark Certificate (CMC): Available for qualifying logos that may not have trademark registration. Gmail can display the logo without the verified checkmark.

A self-asserted BIMI record without either certificate will not qualify for Gmail’s BIMI logo display.

Yahoo Mail

Yahoo supports self-asserted BIMI records without requiring a VMC.

However, publishing a record does not guarantee that the logo will appear. Yahoo also considers factors such as sending volume, sender reputation, engagement, and DMARC compliance.

This explains why the same sender might see their logo in Yahoo but not Gmail.

The difference is not necessarily an authentication failure. It can simply reflect different provider requirements.

3. BIMI Records Don’t Meet DMARC Requirements.

BIMI depends on DMARC, which uses SPF and DKIM authentication results to determine whether a message is authorized to use the domain shown in its From header.

To qualify for BIMI, a domain must have an enforced DMARC policy:

• p=quarantine
• p=reject

The policy must apply to 100% of messages. If the pct tag is specified, its value must be 100.

A DMARC record with p=none can still be useful for monitoring authentication results, but it does not meet BIMI’s enforcement requirement.

Another common problem involves alignment.

For example, a company might send campaigns through a third-party email service provider that signs messages using the provider’s own domain.

If neither an aligned SPF result nor an aligned DKIM result is available, DMARC will fail.

Even with a properly formatted BIMI record, those messages will not qualify for BIMI logo display.

This is an email authentication problem rather than a consequence of using self-asserted BIMI.

4. The Logo File Cannot Be Retrieved or Validated.

Sometimes the issue has nothing to do with certification.

BIMI requires a logo in the appropriate SVG format, and supporting mailbox providers need to retrieve that file successfully.

Common technical problems include:

• The SVG file is unavailable or returns an HTTP error.
• The hosting server has an invalid TLS certificate.
• The image does not meet BIMI’s SVG Tiny Portable/Secure formatting requirements.
• The server blocks requests from certain clients or locations.
• The DNS record points to an outdated or incorrect file.
• The server returns an unsuitable content type or forces a download.

For certificate-backed BIMI, an inaccessible or incorrectly configured PEM certificate file can also prevent validation.

In these situations, the mailbox provider may ignore the BIMI logo even when the sender’s email authentication passes.

BIMI Verification vs. Email Address Verification: What’s the Difference?

The word verification can cause confusion because it refers to several different processes in email infrastructure.

Email Address Verification

Email address verification determines whether an address is correctly formatted and potentially capable of receiving messages.

Depending on the service, it may include syntax checks, MX record lookups, domain checks, and mailbox-level verification attempts.

Its purpose is to identify invalid or risky recipient addresses.

A recipient’s email address does not become invalid because the sender uses self-asserted BIMI.

Email Authentication

Email authentication determines whether a message is authorized to use the claimed sending identity.

The main mechanisms are:

• SPF: Checks whether a sending server is authorized to send mail for the domain used in the SMTP envelope.
• DKIM: Uses a cryptographic signature to verify message integrity and authenticate the signing domain.
• DMARC: Checks whether SPF or DKIM authentication aligns with the visible From domain and provides a policy for handling authentication failures.

These mechanisms play an important role in email security and deliverability.

BIMI Verification

BIMI verification concerns whether a sender qualifies to display a particular logo.

It depends on successful underlying authentication, a valid BIMI record, and the mailbox provider’s requirements for certificates and logo display.

An email can therefore:

• Pass SPF, DKIM, and DMARC.
• Be accepted by the recipient’s mailbox provider.
• Reach the inbox successfully.
• Still fail to qualify for BIMI logo display.

This distinction matters when interpreting verification reports.

If a tool reports an unverified BIMI logo, it should not automatically be interpreted as an invalid email address, an authentication failure, or a spam placement problem.

Do Self-Asserted BIMI Records Affect Email Deliverability?

There is no general rule that mailbox providers reject emails or lower sender reputation simply because a BIMI record lacks a VMC or CMC.

BIMI primarily controls brand logo display. It is not a replacement for email authentication or an independent guarantee of inbox placement.

However, problems encountered during BIMI implementation can expose or create deliverability risks.

Authentication Problems Can Affect Inbox Placement

Mailbox providers evaluate several factors when deciding whether to accept a message and where to place it.

These include:

• SPF, DKIM, and DMARC authentication results.
• Sending domain and IP reputation.
• Spam complaints and recipient engagement.
• Sending patterns and message volume.
• Email content and suspicious sending behavior.

If a sender has poor authentication or domain reputation, messages may be filtered into spam regardless of whether BIMI is enabled.

For example, consider a company that changes its DMARC policy from p=none to p=reject to meet BIMI requirements.

If some legitimate sending services have not been configured for DMARC alignment, their messages may begin failing authentication.

Receiving servers can then reject those messages according to the domain’s DMARC policy.

The cause is the enforcement of DMARC against misaligned mail, not the presence of a self-asserted BIMI record.

Missing Logos Don’t Necessarily Mean Poor Deliverability

A sender might have excellent inbox placement without displaying any BIMI logo.

Similarly, a sender whose BIMI logo appears in supported email clients can still experience spam placement if other deliverability signals deteriorate.

BIMI can improve brand recognition and help recipients identify familiar senders, but it does not override spam filtering decisions.

For this reason, BIMI validation results and inbox placement results should be evaluated separately.

How to Identify and Fix Self-Asserted BIMI Issues

When BIMI validation fails, the best approach is to check each part of the configuration rather than assuming that the missing certificate is responsible for every problem.

Step 1. Check Your BIMI DNS Record

Start by looking up the TXT record at:

default._bimi.example.com

Replace example.com with your sending domain.

Check whether the record includes the correct BIMI version and a valid logo location.

Pay particular attention to the a= attribute.

If the field is empty or omitted, the record is self-asserted. This is not inherently a formatting error, but it limits compatibility with providers that require certificate-backed BIMI.

If you intend to use a certificate, confirm that the record references the correct evidence document.

You can use the free GlockApps BIMI Checker to look up your domain’s BIMI record and validate its configuration. The tool helps identify implementation issues and check whether your BIMI setup meets the necessary technical requirements. It’s a useful starting point when a logo isn’t appearing as expected or a verification tool reports an error.

Step 2. Validate SPF, DKIM, and DMARC

Before making changes to BIMI, verify the authentication setup.

Check that:

• SPF authorizes the relevant sending infrastructure.
• DKIM signatures validate successfully.
• At least one of SPF or DKIM aligns with the visible From domain.
• DMARC passes for legitimate email streams.
• The DMARC policy uses p=quarantine or p=reject with full enforcement for BIMI eligibility.

Pay particular attention to external sending platforms, such as email marketing services, CRM systems, and transactional email providers.

These services may require separate DKIM configurations or other changes to achieve proper alignment.

Step 3. Verify the Logo File and Certificate

Next, check that the SVG logo is accessible through HTTPS.

The file should meet BIMI formatting requirements and be available without authentication or other access restrictions.

For certificate-backed BIMI, also verify that the VMC or CMC:

• Is valid and has not expired.
• Covers the appropriate organization and logo.
• Is hosted in the required format.
• Can be retrieved successfully by mailbox providers.

If the certificate has been renewed or replaced, confirm that the BIMI record references the updated file.

Remember that changes to DNS records and hosted files may take time to propagate or become visible because of mailbox-provider caching.

Step 4. Review Mailbox Provider Requirements

Determine which providers matter most to your audience.

For example, if Gmail accounts represent a substantial portion of your subscriber base, a self-asserted record alone will not deliver the expected BIMI logo visibility.

You will need an eligible VMC or CMC.

If most of your recipients use Yahoo, self-asserted BIMI may be sufficient from a certification perspective, provided the sender meets Yahoo’s other requirements.

This review helps determine whether the problem requires a configuration fix or a change in BIMI implementation strategy.

Step 5. Test Actual Inbox Placement

Once the technical configuration has been reviewed, test how messages are handled by receiving mailbox providers.

This is particularly important if BIMI changes were accompanied by changes to DMARC enforcement.

Compare those results with your email authentication reports and separate BIMI validation checks.

If the email reaches the inbox but the logo does not appear, focus on BIMI eligibility, certificates, and file configuration.

If messages are being rejected or placed in spam, investigate authentication failures, sender reputation, and other deliverability factors before attributing the problem to BIMI.

After correcting your BIMI configuration, run another check with the GlockApps BIMI Checker to verify the updated setup. Keep in mind that a valid BIMI record doesn’t guarantee inbox placement. If your messages are also being filtered into spam, investigate email authentication, sender reputation, and other deliverability factors separately.

Should You Replace Self-Asserted BIMI With a Verified Certificate?

Not every sender needs to move away from self-asserted BIMI immediately.

The decision depends on the mailbox providers your audience uses, your branding requirements, and whether your organization qualifies for certification.

A self-asserted record may be appropriate when the primary goal is logo visibility at providers that support it without a certificate.

However, a certificate-backed implementation offers broader opportunities for verified brand display.

Choose a VMC when:

• Your organization has an eligible registered trademark or another qualifying mark.
• You want your logo to qualify for Gmail’s verified checkmark.
• Verified brand identity is an important part of your email strategy.

Consider a CMC when:

• Your logo does not qualify for a VMC.
• You can demonstrate the legitimate prior use required for a CMC.
• You want certificate-backed logo display in Gmail without the verified checkmark.

In either case, certification should follow proper authentication configuration.

Purchasing a certificate will not fix incorrect SPF records, DKIM alignment failures, or poor sender reputation.

Conclusion

Self-asserted BIMI records are not inherently problematic, but their lack of independent logo certification limits where they can be used.

When a BIMI verification warning appears, first determine whether it concerns logo ownership, DNS configuration, DMARC alignment, or mailbox-provider requirements. These problems require different solutions and should not automatically be treated as email deliverability failures.

For senders who want broader BIMI support, moving to a VMC or CMC may be worthwhile. However, the priority remains the same: maintain reliable email authentication, monitor sender reputation, and test inbox placement regularly.

A verified logo can strengthen brand recognition, but it cannot compensate for a poorly configured sending infrastructure.

FAQ