A BIMI record is not a display guarantee
A BIMI record builder can help format a proposed DNS assertion, but it cannot guarantee that a receiver will show the logo. Publication, asset validity, mark evidence, authentication eligibility and receiver policy are separate conditions. The builder should explain the decisions behind each field and identify what remains unverified. A copyable record without those boundaries can turn a useful configuration aid into an unsupported promise.
The retained BIMI Group implementation guide describes practical setup, while Google's setup documentation describes its receiver-specific requirements. Neither source proves that EmailAuth implements a builder or that every receiver behaves identically. This manuscript proposes output and test requirements; no record was generated for a real domain, published or scanned.
Establish the domain and selector context
Record the intended sending domain, selector, DNS publication owner and approved logo identity. A builder should not silently assume that the default selector represents every message or every brand workflow. BIMI Group's selector guidance explains selector use and its relationship to message signaling. The applicable selector must be connected to the intended sending process rather than chosen only because its DNS name is familiar.
Keep BIMI selector names separate from DKIM selectors. They serve different purposes and occupy different lookup contexts. A builder should explain the publication owner name it proposes, including how the DNS editor expects relative or fully qualified names. It should not blindly duplicate a domain suffix or claim that one provider's input convention applies everywhere. Existing state and provider behavior require authorized review before publication.
Explain each proposed field
The annotation should identify the version assertion, logo-location field and any evidence-location field supported by the targeted guidance or specification version. It should state which values are supplied, which are placeholders and why they are needed for the intended receiver. Do not insert a real URL or certificate location without the domain owner's approval and evidence that the endpoint serves the intended asset.
Unknown or unsupported fields need explicit handling in the builder's own validation. Because BIMI guidance and proposals evolve, the tool should identify its supported rule set rather than invent a universal processing rule for every tag. The test plan should distinguish input the builder refuses to generate from a claim about how every receiver handles an unfamiliar assertion. No unsupported-tag behavior was tested here.
Verify asset and HTTPS prerequisites
BIMI Group SVG guidance describes the stricter SVG Portable/Secure profile. A builder should not accept any image URL as equivalent evidence. The proposed output should reference an approved asset with a retained content hash and validation record, while keeping structural and visual review separate. A logo that appears in a browser may still fail the relevant profile requirements.
Google requires HTTPS hosting for BIMI files in its documented setup. The builder should identify whether the hosting endpoint has been checked and whether the fetched bytes match the approved asset. HTTPS transport evidence does not establish mark-certificate eligibility or receiver display. If no fetch has been performed, the output should say unverified rather than treating an https prefix as a successful connection test.
Scope mark evidence and receiver requirements
Google's retained guidance states that Gmail requires a supported VMC or CMC and describes the VMC-related checkmark distinction. Other receivers may have different eligibility rules. The builder should ask which receivers matter and cite their current requirements before presenting an evidence-location field as universally sufficient or unnecessary. A certificate purchase or issuer approval is not implied by entering a URL.
The Yahoo BIMI guidance illustrates a different receiver scope, including its treatment of VMC requirements and other eligibility considerations. This contrast supports a careful receiver-specific review, not a claim that every message meeting the published checklist will display a logo. The builder should avoid labeling an incomplete configuration as guaranteed brand visibility.
Keep DMARC eligibility and sender readiness separate
BIMI receiver guidance can impose DMARC-related conditions, but a builder must not assume that a DNS enforcement policy proves every legitimate sender aligns. RFC 9989 defines current DMARC behavior and its boundaries. The proposed BIMI output should link to a separate readiness assessment rather than silently changing authentication policy to satisfy a logo setup form.
Where receiver documentation uses conventions that differ from the current protocol vocabulary, retain the source dates and applicability question. Do not automatically rewrite a policy or invent a new version token. A BIMI builder's task is not permission to modify DMARC, purchase mark evidence or change a supplier's sending configuration. Those decisions need their own approved scope and verification.
Prepare an exact-record change plan
Inspecting existing state and preparing an intended diff are separate from publishing. The builder should distinguish replacement of an approved record from addition of a competing assertion at the same owner. RFC 1035 defines TXT structure, including the distinction between strings within a record and separate records. Preserve unrelated TXT data and the complete affected record set in the change plan.
Record restore material, owner approval and the post-change observation plan. A generated string should not automatically authorize a DNS write. If the tool supports publication, that capability needs separate evidence of tenant binding, approval and verification; this manuscript makes no claim that EmailAuth offers it. No DNS state was read or changed for this exercise.
An annotated-builder worksheet
Create a worksheet with domain, selector, exact publication owner, proposed assertion, each field's purpose, asset hash, endpoint evidence, mark-evidence status and intended receivers. Add source-rule versions, current-state reference, intended diff, approval owner and unresolved prerequisites. Keep output validity, operational readiness and receiver display as separate statuses.
The required test cases should cover a positive supported assertion, invalid input, duplicate records and unsupported fields. Each case needs original input, expected behavior and actual tool output once an authorized test is run. Do not label a fixture passed because the proposed output looks plausible. A documentation example is not an executed builder test, and this draft contains neither a production record nor measured results.
Fictional diagnosis: a valid assertion without display evidence
A fictional team generates a syntactically plausible BIMI record pointing at a logo and assumes every recipient will now see it. The proposed review asks whether the asset meets the profile, whether HTTPS retrieval was verified, what mark evidence exists and which receiver requirements apply. The record's formatting answers none of those questions by itself.
The team would leave display readiness unresolved and collect the missing authorized evidence. It would not purchase a certificate or alter authentication policy solely to make a builder status turn green. This scenario is fictional and does not describe a real receiver failure or product limitation. It demonstrates why the output must remain annotated and conditional.
Publish only the demonstrated claim
The catalogue requires an annotated record and positive, invalid, duplicate and unsupported-tag test cases. Those original artifacts remain open, as do human specialist review, source applicability, production routes, accessibility and owner release. This draft supplies requirements and a fictional exercise, not implemented tool behavior or a promise of logo display. A publishable example must retain the actual supported output and tests while keeping receiver discretion visible.