What this analysis does
Mailybox checks DMARC enforcement and the default BIMI record, parses logo and authority locations, and separates missing prerequisites from provider-specific certificate requirements.
BIMI displays a brand logo beside authenticated mail, but the logo is the last step rather than the first. The prerequisites are structural: enforcing DMARC, a correctly published BIMI record, an SVG that meets a restricted profile, and for most participating mailbox providers a verified mark certificate.
Enforcement comes before everything else
BIMI requires a DMARC policy at quarantine or reject. A monitoring policy is not sufficient, and no amount of correct logo configuration compensates. This is deliberate: the logo is a trust signal, and it is only meaningful for a domain that has committed to having unauthenticated mail acted upon.
Reaching enforcement is usually the longest part of the project. It requires a complete sender inventory and an aligned authentication path for every legitimate service, verified through aggregate reporting over a period long enough to include infrequent senders.
- A monitoring-only DMARC policy blocks BIMI entirely.
- Enforcement must be reached before logo work has any effect.
- Subdomain policy matters when mail is sent from subdomains.
The image profile is narrower than ordinary SVG
BIMI does not accept general SVG. The required profile is a restricted tiny variant with scripting, external references and animation removed, a square aspect ratio, and a defined title element. Exporting from a design tool without conforming to that profile is the most common technical failure.
The asset must be served over HTTPS from a stable location. A logo behind a redirect, on a host with certificate problems, or at a URL that changes with each site deployment will fail validation even when the file itself is correct.
Certificates and provider support
Most participating mailbox providers require a verified mark certificate that attests to the organization’s right to use the mark. Obtaining one involves a registered trademark and a verification process with an issuing authority, which has both cost and lead time that should be planned before the technical work starts.
Support and display rules differ between providers, and a domain that satisfies every published requirement may still see the logo rendered inconsistently. Treat BIMI as a brand-presentation improvement layered on an already sound authentication posture, not as a deliverability mechanism.
Read the BIMI readiness guideReview the wider authentication posture
Example: a correct record blocked by policy
Evidence supplied
A domain publishing a valid BIMI record and a conforming SVG, with a DMARC policy of p=none.
How to read the result
Readiness is reported as blocked at the policy prerequisite. The record and image are validated, but no participating provider will display the logo until the DMARC policy moves to quarantine or reject.
Known limits
- Provider display behaviour is not standardized and can differ from published requirements.
- Certificate validation status is not verified by this DNS-level analysis.
- Structural readiness does not guarantee that any provider will render the logo.
Common questions
Can BIMI work without a certificate?
Some providers have supported self-asserted configurations, but the mainstream participating providers require a verified mark certificate. Plan for one.
Does BIMI improve deliverability?
Not directly. The DMARC enforcement it requires is associated with better authentication posture, but the logo itself is a presentation feature.
Why is my logo not showing despite a valid setup?
Display depends on the receiving provider, the recipient’s client and, in most cases, certificate validation. A structurally valid setup is necessary but not sufficient.