Strip away the vendor pitch decks and BIMI is a small system. The entire production setup for tallyfy.com is an 88-character TXT record plus the two files it points at: a 771-byte SVG and an 8,404-byte PEM certificate.

That’s the whole thing.

We’ve run BIMI since July 2022. In four years we’ve debugged a Gmail rendering lag and built the logo three times. In June 2026 we also switched certificate vendors. Along the way we read every byte of the certificate, because vendor documentation kept describing a simpler system than the one that exists in production.

This post is the teardown we wanted in 2022: our live DNS records and our live certificate, plus the exact validation flow a mailbox provider runs on each. Nothing is anonymized because none of it is secret. Anyone with dig and openssl can pull identical artifacts; we’re just saving you the trouble of knowing where to look.

One TXT record starts everything

BIMI discovery happens at a fixed DNS location: a TXT record at default._bimi. followed by your domain. Here’s ours, read from production DNS on July 2, 2026:

$ dig +short TXT default._bimi.tallyfy.com
"v=BIMI1; l=https://tallyfy.com/bimi/logo.svg; a=https://tallyfy.com/bimi/certificate.pem"

The whole record is 88 characters. It carries three tags. v=BIMI1 declares the version. l= points at the brand indicator, an SVG file that must be served over HTTPS. a= points at the authority evidence, which in practice means the PEM-encoded Verified Mark Certificate. The default prefix is a selector, the same idea DKIM uses: the spec allows multiple records under different selectors, chosen per message with a header, but nearly everyone, us included, publishes exactly one under default. The draft also defines optional lps= and avp= tags for local-part selectors and a personal-versus-brand avatar preference; our record uses neither.

A detail that surprises people: BIMI has never been an RFC. The spec lives as an IETF Internet-Draft, at revision 14 dated May 1, 2026, with no formal standing in the standards process. The whole ecosystem, Gmail included, runs on a draft.

The DMARC gate comes first

No provider looks at that record until your DMARC posture earns it. The draft requires a strong policy, quarantine or reject, on both the organizational domain and the From domain of the message. Google’s setup documentation says the same thing for Gmail: the policy option “must be set to quarantine or reject,” BIMI “doesn’t support DMARC policies that have the p option set to none,” and pct must sit at 100 so enforcement applies to every message rather than a sample. Here’s our enforcement record, read the same day:

$ dig +short TXT _dmarc.tallyfy.com
"v=DMARC1; p=reject; sp=reject; rua=mailto:cf58ddc3b39843d4bc555830361dd0ca@dmarc-reports.cloudflare.net,mailto:re+9d471d5a524d@inbound.dmarcdigests.com; aspf=r; pct=100"

p=reject covers the apex and sp=reject extends the same answer to every subdomain, with pct=100 so nothing gets sampled. The two rua= addresses split aggregate reporting between Cloudflare and DMARC Digests; those mailbox tokens are public DNS, so redacting them would be theater. We tightened this exact record on July 2, 2026, during the sweep where we audited 11 domains we own.

Why insist on enforcement before showing a logo? Because BIMI amplifies trust that already exists, and rendering a brand mark on spoofable mail would hand phishers a free credibility banner. A logo next to a message is a visual claim of identity, so the identity has to be enforced before the picture appears.

What the provider actually does

When a message arrives, the receiving server runs the sequence below. Every step fails closed: any miss means no logo, and the mail otherwise delivers normally.

1. Run SPF and DKIM checks and compute the DMARC verdict; the message must pass against a policy at enforcement, because a pass against p=none counts for nothing.

2. Query default._bimi. plus the From domain for a TXT record; mail from a subdomain with no record of its own falls back to the organizational domain, which is why messages from our Mailgun-driven subdomains show the same swan as the apex.

3. Fetch the l= SVG and the a= certificate over HTTPS.

4. Validate the certificate: it must chain to a Verified Mark root the provider trusts, sit inside its validity window, cover the domain, and contain the same logo the l= URL serves.

5. Render the avatar. Gmail adds a blue verified checkmark when the certificate is a VMC backed by a registered trademark.

A teardown of our live certificate

The a= tag points at https://tallyfy.com/bimi/certificate.pem. It’s an 8,404-byte file anyone can download, and it repays reading. Here’s the real output, trimmed for length:

$ openssl x509 -in certificate.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            0f:dd:18:d0:ba:4e:84:ae:3b:9f:10:56:e8:75:3e:e5
        Issuer: C=US, O=DigiCert, Inc., CN=DigiCert Verified Mark RSA4096 SHA256 2021 CA1
        Validity
            Not Before: Jul 29 00:00:00 2025 GMT
            Not After : Jul 28 23:59:59 2026 GMT
        Subject: jurisdictionC=US, jurisdictionST=Delaware, businessCategory=Private Organization,
                 serialNumber=5588051, C=US, ST=Missouri, L=Saint Louis, street=911 Washington Avenue,
                 O=Tallyfy, Inc, CN=Tallyfy, Inc,
                 1.3.6.1.4.1.53087.1.13=Registered Mark, 1.3.6.1.4.1.53087.1.3=US, 1.3.6.1.4.1.53087.1.4=5049343
        ...
            Certificate Policies:
                Policy: 2.16.840.1.114412.0.2.5
                Policy: 1.3.6.1.4.1.53087.1.1
            X509v3 Extended Key Usage:
                Brand Indicator for Message Identification
            1.3.6.1.5.5.7.1.12:
                0...........0...0...0....image/svg+xml ... zdata:image/svg+xml;base64,H4sIAAAAAAAACoVSXY+bMBB8...
            CT Precertificate SCTs: ...

There’s a lot packed into one certificate. Four parts deserve a close look.

A dedicated root, separate from TLS

The issuer line reads DigiCert Verified Mark RSA4096 SHA256 2021 CA1, and it chains up to a dedicated DigiCert Verified Mark Root CA. Your browser has never heard of that root and doesn’t need to. Mark certificates are validated by mail infrastructure against root stores the mailbox providers curate themselves; the BIMI Group’s own issuer list carries a blunt disclaimer that inclusion doesn’t guarantee any provider will honor a certificate. Keeping trust domains separate is the same instinct as our SSO and SAML design, where SAML assertions verify against the identity provider’s own signing certificate, not a general-purpose trust store.

Two more details hide in the same file. The Subject Alternative Name pins DNS:tallyfy.com, so the certificate can’t be repointed at some other domain. And the 8,404-byte PEM turns out to hold the complete chain, three certificates deep, so a single fetch of the a= URL hands a provider the leaf together with its intermediate and the Verified Mark root.

The market behind those roots is tiny. As of July 2026, exactly three certificate authorities issue mark certificates: DigiCert, GlobalSign and SSL.com. We spent May and June 2026 collecting numbers across that whole market, and our five-vendor quote hunt documents every price we extracted.

Our logo lives inside the certificate

The extension labeled 1.3.6.1.5.5.7.1.12 is the LogoType extension. openssl prints its DER structure as dots and stray characters, and then something readable surfaces: data:image/svg+xml;base64,H4sIAAAA.... That’s a data URI carrying our swan logo, gzip-compressed and base64-encoded, embedded inside the certificate itself. The H4sI prefix is the giveaway. Decode those four base64 characters and you get the bytes 1f 8b 08: the two-byte gzip magic number followed by the deflate method byte. Any base64 blob that starts with H4sI is gzip in disguise.

What stops a company from certifying one image and then serving another? The double-embedding does. DigiCert vetted a specific image and notarized it into the certificate, and validation step four compares it against whatever the l= URL returns. If the served SVG drifts from the certified copy, the logo stops rendering.

The trademark is the entire point

Look at the odd attributes at the end of the subject line. They come from a private OID arc the AuthIndicators Working Group registered for mark certificates: 1.3.6.1.4.1.53087.1.13 carries the value Registered Mark, 1.3.6.1.4.1.53087.1.3 says US, and 1.3.6.1.4.1.53087.1.4 says 5049343. That last number is our USPTO trademark registration for the swan design mark. It’s a public record; anyone can look it up in the USPTO database and see the same bird that lands in your inbox.

The trademark determines what Gmail draws next to the logo. A VMC requires a registered trademark and earns the blue verified checkmark. The cheaper Common Mark Certificate skips the trademark, and per Google’s September 2024 announcement, a CMC sender’s “brand avatar will be displayed without the Gmail verified checkmark that’s displayed for VMCs.” Same avatar slot, no checkmark. Eligibility is strict on the VMC side too: the same Google setup doc notes the logo must be trademarked with an intellectual property office that VMC issuers recognize.

The rest of the subject is corporate identity that the CA verified before issuance. serialNumber=5588051 is our Delaware file number, jurisdictionST=Delaware and businessCategory=Private Organization record the incorporation, and the street address is our St. Louis office, the same identity we publish on our compliance and security page. The Extended Key Usage prints as the literal string Brand Indicator for Message Identification, because openssl knows the friendly name for the BIMI EKU. Even the Certificate Policies section pairs a standard DigiCert policy, 2.16.840.1.114412.0.2.5, with a mark-certificate policy from that same 53087 arc.

Anyone can find this certificate

The CT Precertificate SCTs section means the certificate sits in public Certificate Transparency logs, the same infrastructure that tracks TLS certificates. Our precertificate was logged on July 29, 2025, the day the certificate became valid; the SCT timestamp in our copy reads 18:56 GMT, less than a day after the validity window opened. Search any CT log explorer for tallyfy.com and our mark certificate shows up next to the TLS ones. The system is public end to end: public DNS record, public SVG, public PEM, public log entry.

One small wrinkle we only noticed by reading documents side by side: our previous vendor’s order forms billed service from July 27, while the certificate validity runs July 29 to July 28. A two-day offset between what you pay for and what the CA signs.

Three tries at one tiny SVG

The file at the l= URL can’t be any old SVG. BIMI requires a locked-down profile called SVG Tiny Portable/Secure, a subset of SVG Tiny 1.2. The BIMI Group’s guidance on logo files spells out the constraints: the version attribute must be 1.2, baseProfile must be tiny-ps, a title element must be present, and the document may contain no scripts, no animation or interactivity, no external references beyond the XML namespaces, and no x= or y= attributes on the root element. Square aspect ratio is the recommendation, 32 kilobytes is the ceiling, and a solid background is advised because transparency renders inconsistently across clients.

Design tools know none of this.

So why did a square logo take us three attempts across four years? Because vector editors optimize for visual fidelity and export SVG 1.1 with whatever features the artwork happens to use, while BIMI validators check the profile declaration rather than the picture.

Attempt one, May 31, 2022. The swan plus the full “Tallyfy” wordmark, with no background rectangle. Both choices are exactly what the guidance warns against: a wordmark shrinks into an unreadable smudge inside an avatar circle roughly the size of this letter O, and a missing background means every mail client paints its own.

Attempt two, July 25, 2022. Swan only. Progress, except the file came out of Adobe Illustrator as SVG version 1.1 with fill-opacity set to 0.8 on the paths. Wrong version, wrong profile, and partial opacity that a strict Tiny PS validator can reject outright.

Nobody catches these problems by eye. Every version looked like a perfectly good logo in a browser tab.

The live file. What serves at https://tallyfy.com/bimi/logo.svg today is 771 bytes, and it opens like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<svg version="1.2" baseProfile="tiny-ps" xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 228 228" xml:space="preserve">
<title>Tallyfy, Inc.</title>
<rect width="228" height="228" fill="#ffffff"/>

Square 228 by 228 viewBox. A white background <rect> covering the full canvas. Solid hex fills on the swan paths, the logo orange #EE7616 and brand green #3FB65B among them, with no opacity anywhere. And a <title> that reads Tallyfy, Inc., the same name as the certificate’s O= field. The guidance only requires that a title exists; matching it to the certified organization name costs nothing and removes one more way for a picky validator to say no.

Two operational details round it out. The file serves with content-type: image/svg+xml and x-content-type-options: nosniff, so nothing downstream reinterprets it. And its last modification date is January 22, 2026, roughly six months after the current certificate was issued, which tells you the served file was still being corrected long after go-live; that January change replaced the file with the exact certified copy after a hash mismatch. The safe stance once a certificate exists: treat the served SVG as frozen, because the certified copy inside the VMC has to keep matching it. If the logo must change, plan on reissuing the certificate too. The condensed checklist we wish someone had handed us in 2022:

• Export the SVG, then hand-edit version="1.2" and baseProfile="tiny-ps" if your tool won’t write them.
• Square viewBox, mark only; wordmarks are illegible at avatar size.
• Add an opaque background <rect>, since transparent backgrounds render unpredictably.
• Strip scripts, external references, and every trace of opacity.
• Keep a <title>, and make it your legal entity name.
• Stay far under the 32 KB cap; ours uses 771 bytes of a 32-kilobyte allowance.

Where this leaves us

The architecture decision that aged best is barely visible in the DNS record: both URLs point at tallyfy.com. We self-host the SVG and the PEM as two files committed to our website repo, deployed by Cloudflare Pages like any other static asset. A vendor can host these files for you on their own domain instead, and if yours does, your a= URL belongs to them, so leaving means DNS edits on top of everything else.

Because we control both paths, switching certificate vendors, or even certificate authorities, involves no DNS work at all. The swap is: commit the new certificate.pem, deploy, then purge the CDN cache after the deploy finishes so the edge stops serving the stale file. Purge order matters more than it looks. Flush the cache while the old deploy is still live and the CDN simply re-caches the outdated PEM, which is why the purge comes last in our runbook. That’s the entire migration plan we’re executing this month.

Nobody hands you that plan, though. When we bought the replacement certificate in June 2026, SSL Dragon’s support team put the handoff in plain terms on June 17: “A VMC (Verified Mark Certificate) does not replace your existing certificate and will not automatically become active when your current certificate expires.” Activation is entirely on you. In a vendor-hosted setup that means portal steps; in ours it means the one-file swap above.

Which brings us to the countdown. Our live certificate expires July 28, 2026 at 23:59:59 GMT. The replacement was ordered June 15 and has been in DigiCert’s validation queue since the CertCentral request went in on June 16; as of early July 2026 it’s still mid-validation. That leaves 26 days of margin, and the margin shrinks daily.

What happens if validation drags past July 28?

Nothing loud happens. Mail keeps flowing and DMARC keeps enforcing. The swan just quietly vanishes from inboxes until a valid certificate is back at the a= URL. Nothing bounces and nobody gets paged, which is exactly what makes expiry dangerous: it’s a silent downgrade rather than an outage. We’re running this renewal closer than we’d like, and the lesson is to start 60 days out, because trademark and organization validation runs on the CA’s schedule and you can’t hurry it.

Whether the logo justifies three years of certificate fees is a separate question, and we wrote up what three years bought using our own open-rate data. On the mechanics alone, our advice is short. Get DMARC to p=reject before spending a dollar. Register the trademark before shopping for a VMC. Host the l= and a= files yourself. And put the expiry date minus 60 days in a calendar that pages a human, because this system fails silently and no vendor is watching it for you.