GoDaddy How GoDaddy issues Mark Certificates for BIMI

[godaddygodaddy is verified member.]

• Mark Certificates are the trust artifact behind BIMI: they bind a verified organization, an authorized domain, and an embedded logo so mailbox providers can display a brand’s mark next to authenticated email.
• A VMC requires a registered trademark matching the logo and can unlock a verified indicator in some clients, while a CMC relies on at least 12 months of documented prior use and shows the logo without the checkmark.
• Even a valid Mark Certificate does not guarantee display, because it depends on DMARC enforcement being in place and on each participating mailbox provider choosing to render the logo.

Your logo is one of the strongest trust signals your customers have. Phishing campaigns exploit that too. In the inbox, a familiar mark can help a real message stand out or help a lookalike deceive someone.

As a Platform PM on Mark Certificates, I sit between those forces: brands that want their logo next to authenticated email, and rules that keep “verified” from becoming a sticker anyone can print.

Brand Indicators for Message Identification (BIMI) lets participating mailbox providers show a brand-controlled logo next to messages that already pass strong authentication (DMARC at enforcement). The hard part is proving the organization that controls a domain has the right to use that mark.

That proof is a Mark Certificate. This post walks through how GoDaddy issues them through Starfield Technologies’ Mark Certificate PKI.

Start with SPF, DKIM, and DMARC first. This DNS for email guide covers the authentication foundation a Mark Certificate depends on.

What problem are we solving?​

BIMI starts with DNS: a record pointing mailbox providers at a logo and, for the verified path, a Mark Certificate. DNS alone can’t prove the organization is real, controls the sending domain, and owns (or has long used) that mark.

A Mark Certificate answers those questions with public PKI building blocks (X.509 certificates, roots, revocation, audits, and Certificate Transparency) under the AuthIndicators MC Requirements for Mark Certificates. Starfield’s Mark Certificate CP/CPS is how we apply those rules.

BIMI is the display standard; the Mark Certificate is the trust artifact.

VMC vs. CMC​

Under the Mark Certificate rules, applicants usually follow one of two paths: a Verified Mark Certificate (VMC) or a Common Mark Certificate (CMC). Both are Mark Certificates. They differ by how the CA verifies the mark, not by how much cryptography is in the file.

A VMC is for brands that can prove a registered trademark matching the logo they want in the inbox. In some clients (notably Gmail), that path can also unlock a verified indicator next to the logo. A CMC is for brands that can show long-running prior use of the mark (or an allowed modification of a registered mark) without relying on a trademark registration for that logo. CMC is often the on-ramp; VMC is the natural upgrade when trademark paperwork catches up.

The following table compares what each path requires, who it fits, and what recipients may see in participating mailbox apps:

Type	What the CA verifies	Who it’s for	What recipients may see
VMC	A Registered Mark in good standing; subject matches the mark owner	Brands with a trademarked inbox logo	Logo + verified indicator (e.g. Gmail’s checkmark), where supported
CMC	Prior use (now + ≥12 months earlier on a controlled domain via approved archives) or an allowed modification of a registered mark	Brands still building trademark coverage, or adapting a mark for inbox display	Logo without the verified checkmark, where CMC is supported

Both paths still require organization and domain validation. Display varies by client.

Why a dedicated hierarchy​

TLS proves hostname control for HTTPS. Mark Certificates prove something else, so they use a purpose-built chain:

GoDaddy Verified Mark Root CA – VMCR1
└── GoDaddy Verified Mark Intermediate CA – VMCR1V1
└── Subscriber Mark Certificate (end-entity)

The intermediate’s Extended Key Usage is Brand Indicator for Message Identification (Mark Certificates, not website TLS). Relying parties check the path plus Mark-specific profile checks (logotype, mark fields, EKU).

The following diagram illustrates that Verified Mark hierarchy from root to end-entity:

What’s in the certificate​

A Mark Certificate carries verified organization identity, at least one authorized dNSName, mark metadata (including markType), and the logo itself—embedded in the Logotype extension as compressed SVG Tiny PS. Embedding ties validation to the exact mark bytes mailbox providers will trust, not a mutable URL. That’s why “upload any PNG” doesn’t work here. For mark and logo guidance before you apply, see GoDaddy’s brand identity guide.

How validation works​

The following flow illustrates the issuance pipeline:

Application
├─► Organization identity
├─► Domain authorization or control
├─► Mark verification (VMC or CMC)
├─► Denied-list checks
├─► Multi-Perspective Issuance Corroboration (domain + CAA)
├─► Certificate Transparency (mark pre-certificate)
└─► Issue end-entity Mark Certificate

Because issuance is a pipeline rather than a single API call, Mark Certificates take longer than typical DV TLS.

Those stages break down as follows:

Stage	What we verify
Org/domain	Legal entity and domain control. Mark CAA uses issuevmc; TLS CAA readiness isn’t enough.
VMC	Trademark in good standing, subject matches owner, SVG matches the mark.
CMC	Prior-use match now and 12+ months earlier, or limited modifications to a registered mark.
MPIC + CT	Multi-perspective corroboration for domain/CAA; Mark Representation logged to public CT before issuance.

What BIMI does not promise​

A valid Mark Certificate is necessary for the verified logo path. Not a promise every inbox will render it. Authentication must pass; display is each participating client’s product decision. Revoke and check status like any other public cert. A Mark Certificate builds on email authentication; it doesn’t replace it.

Mark Certificate vs. TLS​

If you already know website certificates, Mark Certificates can look familiar at first glance. Both use public PKI. The assertion is different: TLS proves control of a hostname for HTTPS, while a Mark Certificate binds an organization, a domain, and a verified logo for BIMI display in participating mailboxes.

Concern	Typical TLS	Mark Certificate
Relying party	Browsers	Mailbox / BIMI clients
EKU	Server Authentication	Brand Indicator for Message Identification
Visual brand	Not in cert	Embedded SVG Tiny PS
Mark evidence	Not required for DV	Core of VMC/CMC
Success metric	Encrypted channel to a host	Eligible logo next to authenticated email

Practical checklist​

Use this checklist to move from email authentication readiness to a published BIMI logo path:

1. Get SPF, DKIM, and DMARC (enforcement) healthy.
2. Prepare SVG Tiny PS matching your evidence path.
3. Get a VMC or CMC.
4. Publish BIMI DNS.
5. Check supporting clients; watch cert lifecycle.

Closing​

BIMI makes inbox brand presence possible. Mark Certificates make it accountable. When hierarchy, validation, embedded logotype, and CT line up, customers just see a small logo (backed by verification the platform had to get right first).

The post How GoDaddy issues Mark Certificates for BIMI appeared first on GoDaddy Blog.

Continue reading...