Your logo will not appear beside your email just because you upload an image. Brand Indicators for Message Identification (BIMI) depends on verified domain authentication, a precisely formatted logo, and a public Domain Name System (DNS) record. This BIMI implementation guide gives you the straight answer on what must be in place before supported inbox providers can display your brand.
BIMI can help recipients recognize legitimate messages from your organization. That is useful when you send appointment reminders, invoices, client updates, sales follow-ups, or operational notices. It does not guarantee inbox placement, and it is not a replacement for good sending practices. It is a visible signal that builds on authentication you should already have.
What BIMI does and does not do
BIMI is an email standard that lets participating mailbox providers display a verified brand logo next to authenticated messages. The provider decides whether to display it. Your sending domain, message authentication, logo file, and certificate information must all meet that provider's requirements.
The business benefit is simple: recipients have another way to distinguish your genuine email from a lookalike or phishing message. A familiar logo may improve recognition, especially for businesses that send recurring customer communications from a consistent domain.
BIMI does not stop every impersonation attempt. It also does not repair a poor sender reputation, fix a blocklisted sending server, or override a recipient's spam filtering rules. Think of it as the final visible layer of a properly authenticated email program, not the first fix to apply.
BIMI implementation guide: start with authentication
Before you publish a BIMI record, confirm that your domain has working Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC).
SPF is a DNS record that identifies which mail servers and services may send email for your domain. DKIM adds a signed digital identifier to your email, allowing the receiving system to check that the message was authorized and was not changed in transit. DMARC tells receiving systems what to do when SPF or DKIM checks fail and whether those checks align with the domain recipients see in the From address.
For BIMI, DMARC must be active at an enforcement policy. In practical terms, that generally means your DMARC record uses either `p=quarantine` or `p=reject`, rather than `p=none`. Many providers also expect the policy to apply to 100% of mail, shown as `pct=100`.
That requirement is intentional. A logo is more meaningful when the domain behind it has told mailbox providers to treat unauthenticated mail as suspicious. If DMARC is still in monitoring mode, do not rush to enforcement just to get BIMI. First review your DMARC reports and make sure every legitimate sending source passes alignment. This may include your main mailbox provider, marketing platform, customer relationship management system, billing software, website forms, and help desk tool.
A common failure looks like this: your employees send from one service, but invoice notices or newsletters send through another service that was never added to SPF or configured with DKIM. Changing DMARC to reject before finding that gap can cause legitimate mail to be filtered or rejected.
Check SPF and DKIM alignment, not just existence
An SPF record can exist and still be incomplete. DKIM can be enabled and still sign with a domain that does not align with your visible From domain. BIMI depends on DMARC passing, and DMARC depends on alignment.
For SPF, look at the envelope sender domain and confirm it aligns with the From domain when SPF is the authentication method that passes. For DKIM, confirm the `d=` domain in the signature aligns with the From domain. Relaxed alignment can allow related subdomains, while strict alignment requires an exact domain match.
For most small and midsize organizations, DKIM alignment is the more dependable path because third-party tools often control the envelope sender used for SPF. Your exact setup depends on the systems sending mail for you.
Prepare the logo and certificate
BIMI uses a specific logo format called SVG Tiny Portable/Secure, commonly written as SVG Tiny PS. This is not the same as exporting a standard SVG from a design program and placing it online. The file must meet BIMI profile rules, including restrictions intended to keep the image safe and predictable for mailbox providers.
Your logo should be clear at a very small size. Fine print, a full slogan, or a detailed photo usually will not work well. Use the primary mark your customers recognize, with enough contrast to remain legible in different inbox interfaces.
Many providers require a Verified Mark Certificate (VMC) before they will show your logo. A VMC is a digital certificate that connects your domain to a logo associated with a registered trademark. Some provider programs may recognize other certificate types or have their own eligibility rules, so confirm the current requirements for the mailbox providers that matter most to your recipients.
The certificate step is often where a BIMI project slows down. It may require trademark documentation, proof of domain control, and a logo that matches the registered mark. That is not a DNS problem, but it is part of the verification chain. Start that process early if logo display is time-sensitive.
Publish the BIMI DNS record
Once DMARC enforcement, the SVG file, and any required certificate are ready, publish your BIMI record in DNS. The standard location for the default selector is:
`default._bimi.yourdomain.com`
The record is a TXT record. A basic example looks like this:
`v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem`
The `v=BIMI1` value identifies the record as BIMI. The `l=` value points to the public HTTPS location of your SVG Tiny PS logo. The `a=` value points to your certificate file when a certificate is required or available.
Use your real domain and URLs, not the example values. The logo and certificate must be reachable publicly over HTTPS. Do not place the files behind a login, firewall prompt, temporary file-sharing link, or location that redirects unpredictably. Mailbox providers need to retrieve and validate them automatically.
Some organizations use BIMI selectors beyond `default`, but the default selector is the normal starting point. Keep the initial configuration simple unless your technical team has a specific reason to manage multiple brands or sending identities.
Test the full chain before treating BIMI as complete
DNS updates can take time to appear across the internet. More importantly, a published record does not confirm that your messages meet every provider's display conditions. Test using a real message from the exact domain and platform you use for customer mail.
Check the message authentication results first. You want to see SPF and DKIM pass, with DMARC passing and aligned. Then confirm that the BIMI record resolves correctly and that the referenced logo and certificate can be retrieved. If a provider does not show the logo, review its requirements before changing records at random.
The usual causes are manageable: DMARC is still set to `p=none`, a third-party sender is failing alignment, the SVG is not in the required profile, the certificate URL is wrong, or a mailbox provider has not chosen to display the mark. Not every supported inbox handles BIMI the same way, so treat display as provider-specific.
Keep the supporting records healthy
BIMI is not a set-it-and-forget-it project. A later change to your mail platform, marketing tool, DNS host, or sending domain can break SPF, DKIM, or DMARC alignment. Certificate expiration and logo file changes can create problems too.
Maintain a simple record of every service that sends mail as your domain. When a new vendor asks you to add DNS authentication records, review how it affects your existing SPF record. SPF has lookup limits, and adding every vendor instruction without review can create a record that fails when it is needed.
You should also understand two related protections. Mail Transfer Agent Strict Transport Security (MTA-STS) lets your domain tell receiving mail servers to use encrypted Transport Layer Security connections when delivering mail to you. TLS Reporting (TLS-RPT) provides reports about failures in that encrypted delivery process. Neither is required for BIMI, but both support a healthier, more accountable email environment.
If you are unsure whether your domain is ready, start with MailArrive's free email health check and Report Card. It can show your SPF, DKIM, DMARC, BIMI, and related DNS issues in plain language, so you know the exact fix before publishing changes.