How to Get Your VMC Certificate URL, and Where the a= Tag Points

The short answer

The a= tag in your BIMI record is an HTTPS URL that serves your Verified Mark Certificate as a PEM file. No tool looks that URL up for you. You either upload the certificate to a web server and use its address, or you let your certificate authority host the file and hand you the address.

Three terms, defined once. BIMI is Brand Indicators for Message Identification, the standard that puts your logo beside your messages in supporting mailboxes. A VMC is a Verified Mark Certificate, the credential that proves the logo is a trademark you own. PEM is a plain text encoding for certificates, the block that starts with BEGIN CERTIFICATE.

Our advice is to take the certificate authority hosting if it is offered. DigiCert, GlobalSign and SSL.com all offer it. DigiCert states that it pushes the updated files to its hosted URL after every renewal or reissue, which removes the failure that quietly kills a logo about a year after launch.

What the a= tag actually is

The BIMI specification calls it the Authority Evidence Location. The draft says the tag is optional and that "If present, this tag MUST have an empty value or its value MUST be a single URI." On the scheme it is blunt. The URI "MUST contain a fully qualified domain name (FQDN) and MUST specify HTTPS as the URI scheme."

So the record carries two URLs doing two different jobs. The l= tag points at your logo as an SVG Tiny PS image. The a= tag points at your evidence, the certificate. Swapping them produces a record that parses cleanly and displays nothing.

Worth knowing before you copy an example. The Google setup page shows a record with the logo slot left empty, as v=BIMI1;l=;a=https://images.solarmora.com/brand/certificate.pem, because your logo is also embedded inside the certificate. The specification still lists l= as required, and the five live records we looked up on August 27, 2026 filled both slots: benchclearers.com, globalsign.com, cnn.com, bankofamerica.com and ebay.com. Fill both.

Where you host the PEM file

Three routes, in the order we would try them.

The Google troubleshooting page lists same domain hosting as a check for the SVG logo, not for the certificate. Bank of America and eBay both point a= at vmc.digicert.com.

• Your certificate authority. DigiCert says that when it hosts your files, "DigiCert automatically pushes the latest version of your files to the hosted server after each renewal or reissue." GlobalSign says "In case you opted for optional hosting, you will get the above URLs from us, which you need to place on your DNS Entries as shown above." SSL.com says "SSL.com hosts both your Mark Certificate and SVG logo file for BIMI."
• Your own web server. The Google instruction is one sentence: "Upload the PEM file (including all appended files) to your domain's public web server." Our own store serves its PEM from a Shopify CDN path.
• A deliverability vendor. Some DMARC platforms host both files and give you the URLs. The CNN record points at amplify.valimail.com for the logo and the certificate.

What the file has to contain

The normative document is the IETF draft Fetch and Validation of Verified Mark Certificates, which the Google setup page cites for web server requirements.

The draft adds that if the certificates "appear out of issuance order, contain duplicates or more than one VMC, the receiver may choose to reject the validation." So do not paste in a second certificate hoping one of them takes.

Three PEM files we downloaded on August 27, 2026 each held exactly three certificates in order: leaf, intermediate, root. That matches the Google instruction to verify "you've appended any other issued files or certificates to your PEM file."

• Certificates "MUST be in PEM encoding" and "the full issuance chain up to and optionally including the root CA certificate, MUST be present."
• The file "SHOULD be ordered by starting with the Verified Mark Certificate, followed by its issuer CA certificate and potential successive issuers all the way to the optional root CA certificate."
• The URI should carry a .pem file name extension.
• ""The service MUST use HTTPS protocol and SHOULD use TLS version v1.2 [RFC5246] or newer to avoid protocol security bugs with earlier versions of TLS.""

The content type question, answered honestly

You will see advice to serve the file as application/pem-certificate-chain. We went looking for that requirement and it is not there. The fetch and validation draft specifies PEM encoding, chain order, HTTPS and the filename extension, and says nothing about a media type. The BIMI Group sender FAQ hedges too, telling you to check for "application/pem-certificate-chain (or similar) content types."

Production does not follow the advice. Here is what four live certificate URLs returned on August 27, 2026.

Four URLs, three different content types, and not one of them is the header the guides recommend. Our store serves application/octet-stream and the Gmail checkmark is live on it. Do not lose a day fighting your CDN over this header. Spend it confirming the URL returns 200 and the body is a certificate chain.

• vmc.digicert.com, serving Bank of America, returned application/x-pem-file
• vmc.globalsign.com, serving GlobalSign, returned application/x-x509-ca-cert
• amplify.valimail.com, serving CNN, returned application/x-x509-ca-cert
• benchclearers.com, serving our own store, returned application/octet-stream

The mistakes that cost people a logo

Each of these leaves you with a record that reads as correct and a logo that does not appear.

• A redirect. The BIMI Group lists "Redirect chains ending on the wrong file/host" among the reasons a provider or tool fails to retrieve the file. The draft never says verifiers have to follow redirects, so pointing a= at an address that bounces is a bet with no upside. Publish the final URL.
• An expired certificate behind a working URL. The BIMI Group states that "BIMI Mark Certificates currently have a maximum validity period of 398 days (roughly one year)." The three leaf certificates we inspected ran from 367 to 396 days. The URL keeps returning 200 long after the certificate inside it has lapsed.
• A renewal that never reached the file. If you self host, reissuing the certificate changes nothing until you upload the new PEM. This is the failure that authority hosting removes.
• The logo URL in the evidence slot. The l= tag takes the SVG, a= takes the PEM. A record with the SVG address in both slots is still syntactically valid.
• A server that blocks the fetch. Hotlink protection, geo restrictions, IP allowlists and user agent filtering give you a URL that works in your browser and fails for a mailbox provider.
• Stale caching. The draft lets receivers cache evidence documents, tells them to set a TTL on the cache entries and index by URI, and declines to say what that TTL should be. Its own workaround: publish the new certificate at a new unique URI, then update the record.

Verify it end to end

Four checks, in order, run from outside your own network.

One caveat on the official tool. The BIMI Group inspector carries its own disclaimer: "This tool only validates the format of your BIMI record and your DMARC record being at enforcement. It does not validate your SVG or Mark Certificate." A pass there tells you nothing about your a= URL.

• Read the record with dig +short TXT default._bimi.example.com and confirm the a= value is the address you meant to publish.
• Fetch the headers with curl -sSI on that address and confirm a 200. Run it again with -L and compare the final URL. If it moved, you have a redirect to remove.
• Confirm it is a real chain. Pipe the body through grep -c for BEGIN CERTIFICATE and check the count against what your authority issued. Then run openssl x509 -noout -subject -dates on the first block to check the leaf has not expired.
• Confirm the logo matches. Your SVG is carried inside the certificate as a base64 data URI, gzip compressed. Decode the base64, gunzip the result, then compare it against the file at l=. On our own certificate the two are the same 682 bytes with the same SHA-256 digest. DigiCert describes doing this for you, matching "the PEM file byte-for-byte to your logo SVG file."

If the URL is right and the logo still does not show

The certificate URL is one requirement among several. The Google page states that "The policy option (p) must be set to quarantine or reject" and that "The percent option (pct) must be set to 100." It also asks for patience. After you add the record "it can take up to 48 hours for your logo to show in recipients' mailboxes."

The display decision is not yours either. The specification leaves it to the receiving provider, so a correct record is a request rather than a guarantee. Google ties the badge to the certificate type: "In Gmail, you'll see a checkmark next to senders verified with a VMC."

Working with us

Verified Everywhere is a small team in San Diego. We ran this stack on our own business first. Bench Clearers, our hockey apparel store, holds a VMC issued through GlobalSign and has BIMI live in Gmail with the checkmark, which is where the certificate figures above come from. We work through each platform's official channels and screen work before quoting. If your a= URL is published and the logo still is not showing, send us the domain and we will read the record and the certificate before quoting anything.