BIMI Checker/Generator
Review BIMI tags, DMARC dependency, asset URLs, evidence signals and a conservative record draft.
Email SecurityBIMI Rollout: From Enforced DMARC to a Visible Logo
The BIMI TXT record is the smallest part of a BIMI project. Logo display sits at the end of a chain—aligned authentication, enforced DMARC, a constrained SVG, optional certificate evidence and receiver reputation—and every receiver still owns the final decision.
Earn enforcement before touching the logo
BIMI depends on DMARC enforcement because a displayed mark would otherwise reward a From domain that receivers cannot reliably protect. The practical threshold is p=quarantine or p=reject; p=none is observation, not enforcement. A partial pct rollout may also fail a receiver’s eligibility rules. More important, the policy must be safe: every legitimate source needs aligned SPF or aligned DKIM before you ask receivers to act on failures.
Inventory transactional mail, marketing, support platforms, employees, appliances and forgotten SaaS senders through DMARC aggregate reports. Move from monitoring to quarantine and reject only when unauthorized traffic can be separated from broken legitimate streams. Check the live policy and authentication records with the SPF/DMARC/DKIM Checker, while remembering its limit: DNS readiness cannot prove what a real message signs or which envelope domain a provider uses.
Publish a deliberately boring record
The customary owner is default._bimi.example.com, though selectors allow different marks for controlled streams. A basic value is v=BIMI1; l=https://assets.example.com/brand.svg. The l= location must be a stable HTTPS URL. Where certificate evidence is used, a= points to the VMC or CMC file. Do not publish a speculative evidence URL: a broken certificate reference adds a failure without adding trust.
Serve the assets as production dependencies: correct content type, no authentication, no fragile redirects, a valid TLS chain and predictable availability. Keep the URL stable when the underlying file changes, but manage caches during replacement. The BIMI Checker/Generator can fetch live BIMI and DMARC records, assess record tags, asset URLs and readiness signals, and draft a conservative value. It does not cryptographically certify evidence or promise that a mailbox provider will render the result.
SVG Tiny P/S is not ordinary SVG
A logo that opens in a browser is not necessarily a BIMI logo. Receivers expect SVG Tiny Portable/Secure: a constrained, self-contained profile designed for security-sensitive rendering. Scripts, animations, external resources, linked fonts and many editor-specific features are out. The file needs a square view box, scalable artwork and no dependence on a background that may be light, dark, circular or heavily padded by the mailbox UI.
Exporting directly from a design application commonly leaves metadata, unsupported elements, raster images or styling that violates the profile. Produce the BIMI asset as a separate deliverable, validate its structure, then inspect it visually at small sizes and in varied crops. Keep generous safe space and favor a simple brand mark over a wordmark whose letters become dust at avatar size. “Pixel perfect” in the design file is irrelevant if the receiver masks half the canvas.
VMC or CMC is a receiver-coverage decision
A Verified Mark Certificate binds a validated trademark to the logo and domain. It is the strongest evidence path and is required by some major mailbox providers for their form of BIMI display. The cost is not merely the certificate: trademark scope, legal ownership, exact artwork and renewal become operational dependencies. A Common Mark Certificate supports marks that may not meet the registered-trademark path, but receiver support and visual treatment can differ.
Choose from the recipient population backward. If the providers that matter require a VMC, an uncertified deployment can be technically correct and commercially invisible. If broad certificate-free BIMI support already covers the objective, do not buy evidence as ritual. Document which provider policies the decision targets and recheck them at renewal—receiver programs evolve. Certificates expire, logo rights change and an old a= URL can turn yesterday’s proof into today’s reason not to display.
Roll out as a chain of proofs
First prove DMARC enforcement across a full business cycle. Then host and validate the SVG, obtain certificate evidence if the coverage decision requires it, and publish BIMI with a change record and rollback value. Query the exact selector owner through more than one resolver after TTL expiry. Confirm that logo and evidence URLs are reachable from outside your network without cookies, allowlists or content negotiation that serves HTML to an unfamiliar fetcher.
Send aligned production mail to representative providers and inspect their authentication results. Verify the visible From domain is the one whose DMARC and BIMI records you prepared; parent and subdomain policy assumptions cause quiet misses. The MX Record Check can expose adjacent DNS routing problems, but inbound MX health is not a BIMI prerequisite for a sending domain. Keep the layers separate, especially when a dedicated subdomain sends mail but receives none.
Why a valid record still shows no logo
Start with the usual failures: DMARC remains at p=none, enforcement is partial, SPF or DKIM passes without alignment, the wrong From domain is used, the selector owner is wrong, or DNS caches still hold an older answer. Next inspect the asset chain: redirect loops, TLS errors, incorrect media types, an unreachable certificate, expired evidence or an SVG that is visually valid but outside Tiny P/S. A syntax-clean TXT record proves almost none of this.
After technical checks pass, the remaining answer may be receiver policy. Providers apply reputation, volume, abuse and account-specific display rules; some require evidence certificates, some support BIMI differently, and some do not support it. Logos may appear gradually, only in certain clients, or not for test traffic. Do not “fix” this by repeatedly changing a correct record. Preserve evidence, monitor authentication and asset availability, and treat display as a provider-controlled outcome—not an SLA granted by DNS.