---
title: "How GoDaddy issues Mark Certificates for BIMI"
date: "2026-11-02T07:15:00"
url: "https://www.godaddy.com/resources/news/how-godaddy-issues-mark-certificates-for-bimi"
---
# How GoDaddy issues Mark Certificates for BIMI

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](https://www.godaddy.com/resources/mindset/configuring-dns-for-email-a-quick-beginners-guide) 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](https://www.godaddy.com/resources/mindset/configuring-dns-for-email-a-quick-beginners-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](https://bimigroup.org/resources/VMC_Requirements_latest.pdf). 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:

![flow chart](https://www.godaddy.com/resources/wp-content/uploads/2026/10/hierarchy.png?size=1024x1024)

## 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](https://www.godaddy.com/resources/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).