{{ summaryHeading }}{{ summaryValue }}{{ summaryLine }}

Protocols, paths, _bimi prefixes, and trailing dots are normalized.
Use one or more DNS-safe labels, such as default or seasonal.brand.
Use a public HTTPS URL ending in .svg or .svgz; validate the Tiny PS profile separately.
Receiver certificate requirements vary; declination intentionally suppresses an inherited indicator.
This tool validates URL shape only; it does not inspect certificate content or status.
Verify aligned SPF or DKIM and the live DMARC record after publication.
Choose the interface where you will publish this one TXT record.
Use a shorter TTL during rollout and raise it after validation.
sec
This presentation choice does not change BIMI tag meaning.
FieldValueUseCopy
{{ row.label }}{{ row.value }}{{ row.note }}
{{ values.txt_value }}
Provider fieldValue to pasteNoteCopy
{{ row.label }}{{ row.value }}{{ row.note }}
GateStatusNext actionCopy
{{ row.label }}{{ row.status }}{{ row.detail }}{{ row.action }}
DKIM DNS Record Generator Build a DKIM TXT record from a selector and public key with validation and DNS string splitting, plus rollout checks before publishing.
DMARC DNS Record Generator Build a current or legacy DMARC TXT record with policy inheritance and reporting destinations plus DNS string splitting and rollout review.
SPF Record Generator Build an SPF TXT record from real sender paths with ordered mechanisms and lookup-budget planning plus DNS packaging and rollout checks.
Email Header Analyzer Inspect raw email headers locally to trace relay delays and compare recorded SPF, DKIM and DMARC evidence while spotting sender mismatches.

An inbox logo is the last visible step in a longer email-authentication chain. Brand Indicators for Message Identification (BIMI) lets a domain publish a preferred logo location in DNS, but a receiving mailbox decides whether to fetch or display it after evaluating the message and the sender's authentication history.

BIMI builds on Domain-based Message Authentication, Reporting, and Conformance (DMARC). DMARC connects the visible From domain with authenticated SPF or DKIM results and publishes a handling policy. BIMI guidance expects strong enforcement, commonly quarantine at 100 percent or reject, before a sender should expect broad logo display.

The assertion itself is a TXT record at a selector-specific owner such as default._bimi.example.com. Its v=BIMI1 tag declares the version, l= points to an HTTPS SVG logo, and a= may point to evidence such as a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC). An empty value has meaning; it is not the same as accidentally omitting the record.

Piece Purpose Important boundary
DMARC posture Provides the authenticated-domain gate beneath BIMI. A selected posture is a declaration until live mail confirms alignment and enforcement.
Selector owner Places the assertion below _bimi. A non-default selector normally needs a matching BIMI-Selector header.
Logo asset Supplies the brand indicator over HTTPS. A URL ending in .svg or .svgz does not prove the image satisfies the required SVG profile.
Evidence Links a certificate or leaves the evidence tag empty. Mailbox providers set their own certificate and display requirements.

A correct record therefore answers only one part of the rollout. The owner must exist in the authoritative zone, the logo and evidence documents must be reachable and valid, DMARC must work on real mail, and receivers must support the chosen profile. DNS propagation and cached answers can also delay what a lookup shows.

Separate selectors can support distinct sending contexts, but they increase operational work. Most first deployments are easier to audit with the default selector, one reviewed logo asset, a deliberate evidence choice, and a live test across the mailbox providers that matter to the sender.

How to Use This Tool:

Prepare the assertion only after deciding which domain, selector, assets, and DMARC posture are actually in scope.

  1. Enter the Domain and Selector. Use default unless the sending system adds the selector header required for another name.
  2. Provide an HTTPS Logo SVG URL, then choose the Evidence profile. Certificate mode requires a VMC or CMC URL; no-evidence mode leaves a= empty; declination leaves both l= and a= empty.
  3. Set DMARC posture from verified production evidence. Do not select enforced merely to clear a readiness check.
  4. Choose the DNS provider format and Publication TTL. Follow the generated field names and quoting guidance because DNS consoles differ on relative owners and surrounding quotes.
  5. Review every item in Readiness checks. Publish only after replacing example values, clearing blockers, and separately validating DNS, DMARC, the logo profile, evidence, and receiver behavior.

Interpreting Results:

Ready for live validation means the supplied values passed local format rules and no selected readiness gate is blocked. It does not mean that a logo is live. Review marks a pilot DMARC posture, missing evidence URL, or sample-only data. Blocked means DMARC readiness was left unknown. Decline identifies an intentional empty-logo assertion.

The readiness percentage summarizes six local gates. It is a checklist score, not a mailbox-provider acceptance probability. Give more weight to the individual check rows and their next actions than to the percentage alone.

Technical Details:

A BIMI assertion combines a DNS owner with a semicolon-delimited TXT value. The selector and domain form the owner; the evidence choice determines the values of the location and authority-evidence tags.

Record Core:

Evidence choice TXT value before optional final semicolon Local interpretation
VMC or CMC URL v=BIMI1; l=<logo-https-url>; a=<evidence-https-url> Logo and evidence URLs are both present.
No evidence URL v=BIMI1; l=<logo-https-url>; a= Evidence gate remains under review.
Declination v=BIMI1; l=; a= Logo display is intentionally declined for the selector.

The owner is <selector>._bimi.<domain>. Domain and selector labels must be DNS-safe. Logo locations must use HTTPS and end in .svg or .svgz; certificate evidence must use HTTPS. These are format checks only and do not fetch or validate the assets.

Formula Core:

Each local gate contributes a percentage, and the displayed readiness score is the rounded arithmetic mean of the six gate values.

R = round ( g1+ g2+ g3+ g4+ g5+ g6 6 )

Domain, selector, logo-format, and publication-format gates contribute 100. Certificate evidence contributes 100, no-evidence contributes 40, and declination contributes 100 as an intentional choice. DMARC contributes 100 for enforced, 50 for pilot, and 0 for unknown. The selected labels are not independently verified.

TTL accepts 60 to 86,400 seconds. Provider-specific instructions change owner qualification, quoting, and field names but leave the assertion value itself unchanged. A terminal semicolon may be included or omitted.

Limitations and Privacy Notes:

No DNS query, DMARC traffic analysis, SVG profile validation, certificate verification, or receiver test is performed. Inputs are assembled in the browser and are not sent to a BIMI-validation service. After publication, the DNS record and linked public assets are intentionally visible to outside resolvers and mailbox providers.

Worked Examples:

Pilot DMARC without evidence

A valid domain and selector with an HTTPS SVG, no evidence URL, pilot DMARC, and a recognized provider receives gate values of 100, 100, 100, 40, 50, and 100. The rounded readiness score is 82 percent and the state remains Review. The next work is DMARC enforcement and receiver-specific evidence validation, not publication based on the score.

References: