Your sending system sends the email. The receiver authenticates it, looks up the BIMI record, evaluates the logo and any required certificate, and applies its own display rules.
- BIMI is configured for a sending domain.
- The recipient’s provider performs the checks.
- Passing technical checks makes display possible, not guaranteed.
1. Your organisation sends an email
Start with the address a person sees in the From field, such as hello@example.com. The domain in that address is central to DMARC alignment and the BIMI lookup. The name shown beside it, such as “Northstar”, is not the domain.
An email service provider may handle delivery for you. It still needs to authenticate mail in a way that aligns with your own visible sending domain.
2. The receiver checks authentication
The receiving system evaluates SPF and DKIM, then DMARC. A DMARC pass needs a passing, aligned SPF result or a passing, aligned DKIM result. Configuring both is good operational practice.
Passing a message check and publishing an enforcement policy are different things. BIMI needs the relevant domain policy at enforcement as well as authenticated messages. Understand the authentication layer →
3. The receiver finds your BIMI record
For the default selector, the published location is default._bimi.example.com. The TXT record points to a logo and, when used, certificate evidence. DNS acts like a directory: it holds the addresses of the files, not the artwork itself.
Use the actual sending domain when planning your deployment. Do not assume that configuring one of several unrelated domains configures the others.
4. The receiver evaluates the files
The receiver needs to retrieve the referenced assets and accept their format and evidence. A certificate may be checked for its issuer, validity, domain coverage, and relationship to the logo. A URL that opens only after a login is unsuitable for public receiver access.
5. The provider decides what to show
Providers can consider sender reputation, their interface, account context, and supported certificate types. One provider may display a logo while another does not. A desktop reading view can also differ from a mobile message list.
Test real messages from each sending service. A DNS checker sees published configuration; it does not see every recipient’s authentication result or display decision.
Go to the source
Provider policies and specifications can change. These primary sources informed this guide, reviewed on 1 November 2026.