Hosted BIMI end to end

15 June 2026 · 13 min read

BIMI is the standard that puts your brand logo next to your messages in supporting mailboxes. It sounds like a design task, and the visible result certainly is a logo, but underneath it is a chain of dependencies: a passing DMARC policy, a precisely constrained SVG file, a published DNS record, and in the inboxes most people care about a paid certificate that ties the logo to a trademark you actually own. Get any link wrong and the logo silently fails to appear, with no bounce, no error and no explanation. This article walks the whole path end to end, from artwork to a verified mark rendered in the inbox, and is explicit about which steps DMARC Engine handles for you and which still need a human decision or a purchase only you can make.

If you have not yet decided whether BIMI is worth the effort, start with do you need BIMI and come back. The short version: BIMI is a brand and trust signal, not a security control. It rides on top of authentication you should already have, and it only renders once that authentication is enforced.

The hard prerequisite: DMARC at enforcement

BIMI does not work on a domain that is still publishing p=none. Every implementation, in every supporting mailbox, requires that the sending domain has a DMARC policy of p=quarantine or p=reject. Gmail goes further and expects p=quarantine with pct=100 at minimum, and most senders end up at p=reject anyway. This is the single most common reason a BIMI rollout stalls: the logo file is perfect, the record is published, the certificate is bought, and nothing shows because the domain is still at monitoring level.

The reason is deliberate. A logo is a trust mark. If anyone could attach a recognisable brand logo to mail from a domain that does not enforce authentication, the logo would become a phishing aid rather than a phishing deterrent. So the BIMI specification makes enforced DMARC the price of entry. You cannot shortcut it.

This is exactly the journey DMARC Engine is built to take a domain through safely. The staged path from p=none to p=reject with no legitimate mail lost is the core product, described in the DMARC product overview, and BIMI is the reward at the end of it rather than a separate project. In practice the sequence is:

Publish p=none and start collecting aggregate reports so you can see every source sending as your domain.
Fix SPF and DKIM alignment for each legitimate sender until they pass under DMARC.
Move to p=quarantine, then p=reject, watching reports for collateral damage at each step.
Only then publish BIMI, because only then will it render.

You can check where a domain stands right now with the free DMARC checker. If it reports p=none, BIMI is premature and the platform will tell you the same thing during onboarding rather than letting you waste money on a certificate that cannot display.

Preparing the logo: the SVG is fussier than it looks

BIMI does not accept a PNG, a JPEG or an ordinary SVG exported from a design tool. It requires a very specific, deliberately restricted flavour of SVG called SVG Portable/Secure, usually written SVG P/S, and based on the SVG Tiny 1.2 profile. The restrictions exist because the file will be rendered inside an email client and must not be able to do anything dangerous or unpredictable.

The constraints that trip people up most often are:

No scripts. Any <script> element disqualifies the file outright.
No external references. No linked images, no remote fonts, no external stylesheets, no xlink:href pointing off the document.
No animation. SMIL animation elements are forbidden.
A single root <svg> element with a baseProfile="tiny-ps" attribute and the correct version declaration.
A <title> element describing the mark.
A square aspect ratio. The viewBox must be square, for example 0 0 200 200. Logos that are wide wordmarks have to be reworked into a square lockup, often just the brand symbol rather than the full name.
A solid background, not transparent. Transparency renders unpredictably against the coloured circles and avatars different clients draw, so a defined background colour is expected.
Small file size. Keep it lean; large embedded path data and unused metadata cause problems.

Beyond the machine rules there are taste rules that decide whether the logo actually looks like your brand once it is shrunk into a 30-pixel avatar circle. Fine detail vanishes at that size. Thin strokes disappear. A full horizontal logo becomes an unreadable smear. The practical answer is almost always a simplified, square, high-contrast version of your mark. We cover the design decisions in designing a BIMI logo, which is worth reading before you hand artwork to anyone, because reworking the SVG after a certificate has been issued against it is painful.

There is a second, subtle trap here that becomes important the moment you buy a certificate: the logo in your DNS record and the logo on your trademark registration and the logo inside the certificate must all be the same mark. The certificate authority issues the certificate against a specific image. If you later tweak the SVG, the certificate no longer matches and the logo stops verifying. So the SVG you finalise now is the SVG you commit to. Treat it as a versioned asset, not a draft.

When you onboard a domain to DMARC Engine, the platform validates the SVG against the BIMI P/S profile before anything else happens. It checks for the forbidden elements, confirms the square viewBox and tiny-ps base profile, flags transparency, and stores the canonical file. That validation step catches the overwhelming majority of "my logo will not show" problems before they cost you a certificate fee.

Publishing the BIMI DNS record

Once the SVG is final, BIMI is advertised through a single DNS TXT record at a predictable location:

default._bimi.example.com.  IN  TXT  "v=BIMI1; l=https://.../logo.svg; a=https://.../vmc.pem"

The three parts:

v=BIMI1 is the version tag and must come first.
l= is the HTTPS URL of your validated SVG logo.
a= is the HTTPS URL of your verified mark certificate (the VMC, covered below). If you have no certificate you can leave a= empty, but understand the consequence: the major mailboxes will not render the logo.

The default part is the selector. Just as DKIM uses selectors to let one domain publish several keys, BIMI uses selectors to let one domain publish several logos, chosen per message via a BIMI-Selector header. Most senders only ever need default, but if you run distinct brands or sub-brands off one domain the selector mechanism is how you target each. This is explained more fully in the BIMI selector explained.

Two operational details matter and both are easy to get wrong by hand:

The logo and certificate must be served over HTTPS with a valid, trusted certificate on the web server, with the correct content type. A logo served over plain HTTP, or from a host with an expired TLS certificate, will not be fetched.
The record must be at the right name. For the default selector that is default._bimi under the domain. A typo here produces total silence.

This is where the hosted model removes a whole category of mistakes. Rather than asking you to hand-edit a TXT record, format the parameters correctly, host the SVG and the certificate somewhere reliable, and keep the HTTPS endpoints valid forever, DMARC Engine publishes and hosts all of it for you. The SVG and the certificate are served from monitored HTTPS endpoints, the record is generated with the correct selector and syntax, and the platform owns the moving parts that break silently when a human forgets to renew or mistypes a label. The same delegated-DNS approach the platform uses for DMARC, SPF and DKIM applies here; if you have already delegated, BIMI is just another record on the managed zone. See the BIMI product page for how this fits the rest of the hosted stack.

You can confirm what is actually published at any point, on any domain, with the free BIMI checker. It fetches the record, parses the tags, retrieves the SVG, and reports whether the file passes the P/S profile and whether a certificate is referenced.

The VMC: a certificate that proves the logo is yours

For the inboxes that matter most, Gmail and Apple Mail among them, publishing a record and an SVG is not enough. They require a Verified Mark Certificate (VMC). A VMC is a special X.509 certificate, issued by a small number of approved certificate authorities, that cryptographically binds your specific logo image to evidence that you are entitled to use it. The "evidence" is, in the standard case, a registered trademark for the mark in question, in a recognised trademark office, that matches the logo you are publishing.

This is the step that no platform can do for you, because it depends on facts about your business:

You need a registered trademark for the logo. Not a pending application in most cases, and not just a company name: a registered figurative or design mark covering the actual image. If your logo is not trademarked, that is a legal process with its own timeline and cost, entirely outside the email system.
The CA performs a verification process. This is a vetting exercise, similar in spirit to extended-validation certificate issuance. The CA checks the trademark registration, confirms your organisation's right to it, and validates that the SVG matches the registered mark. It is not instant; allow days to weeks.
There is a real annual cost. VMCs are paid certificates with yearly renewal, and the price is meaningful. This is a deliberate business decision, not a checkbox.

Because of the trademark requirement, a genuine subset of organisations cannot get a VMC at all, or not yet. For them there is a second option that has emerged more recently: the Common Mark Certificate (CMC). A CMC relaxes the strict registered-trademark requirement and instead allows marks that have been in prior use, which opens BIMI-style logo display to organisations whose logo is not a registered trademark. Support and exact rules differ by mailbox and are still evolving, so a CMC is not a drop-in equivalent of a VMC everywhere. The trade-offs are laid out in the CMC explainer and, specifically for logos without a registration, in CMC for unregistered logos. If you go the CMC route, the rest of the pipeline (SVG preparation, the record, the hosting, the rendering) is identical; only the certificate type and its issuance criteria change.

What DMARC Engine handles around the certificate: it generates the certificate signing request against your canonical SVG so the image inside the request matches the published logo exactly, coordinates the file formats the CA needs, and once the certificate is issued it hosts the .pem over HTTPS and wires it into the a= tag of your BIMI record automatically. What it cannot handle: owning the trademark, paying the CA, and passing the CA's identity vetting. Those are yours. The honest division of labour is that the platform removes the fiddly technical and DNS work and leaves you with the genuinely human decisions.

What happens in a supporting inbox

When everything is in place, here is the chain of events a receiving mailbox runs for an inbound message, and it is worth understanding because every link is a place rendering can quietly fail:

The message arrives and the mailbox authenticates it. SPF and DKIM are checked, and DMARC alignment is evaluated.
DMARC must pass and the domain's policy must be at enforcement. If DMARC fails, or the policy is still p=none, the mailbox stops here and shows no logo.
The mailbox looks up the BIMI record for the domain (and selector, if a BIMI-Selector header is present).
It fetches the SVG from the l= URL and the certificate from the a= URL.
It validates the certificate: is it from a trusted VMC or CMC issuer, is it currently valid, and does the logo inside it match the SVG being served?
If all of that holds, the mailbox renders your logo in the avatar position next to the message.

Notice how much has to be true simultaneously. The message itself has to authenticate, on top of the standing configuration being correct. This means a sender that has BIMI fully set up can still see the logo missing on a particular message because that message failed DMARC, perhaps it went through a forwarder that broke the signature, or came from a sender that was never aligned. BIMI is per-message gated on authentication, not just per-domain. This is one more reason the underlying SPF and DKIM hygiene matters; you can audit those with the SPF checker and DKIM checker, and aggregate DMARC reports will show you which sources are failing alignment so you can fix them before they cost you logo display. The platform's DMARC report analyzer turns those XML reports into a readable picture of which senders are passing.

Also worth setting expectations on: support is not universal and rendering is not identical everywhere. Gmail and Apple Mail are the headline implementations and both want a certificate. Some other mailboxes will show a logo from the record and SVG alone, without a certificate, which is why the question "will BIMI work without a VMC" comes up so often; the honest answer is "in a few places yes, in the places you care about no", and that is covered in BIMI without a VMC. Plan around the major inboxes and treat anything extra as a bonus.

What the platform handles, and what stays with you

Pulling the division of labour together, because this is the practical question:

DMARC Engine handles:

Driving the domain from p=none to enforcement safely, which is the precondition BIMI cannot exist without.
Validating your SVG against the BIMI P/S profile and storing the canonical, versioned file.
Hosting the SVG and the certificate over monitored HTTPS endpoints with valid TLS, so the l= and a= fetches never fail because of a lapsed web certificate.
Generating and publishing the BIMI DNS TXT record with the correct selector and syntax on the managed zone, alongside your DMARC, SPF, DKIM and MTA-STS records.
Building the certificate signing request against the exact published logo so the image matches, and wiring the issued certificate into the record's a= tag.
Ongoing monitoring, so that if a record drifts, a file stops serving, or a certificate approaches expiry, it is caught rather than discovered months later when someone notices the logo vanished.

You handle:

Owning a registered trademark (for a VMC) or a qualifying prior-use mark (for a CMC) that matches the logo.
Paying the certificate authority and passing its identity vetting.
Choosing and signing off the final square logo design, since that is the asset everything else is built against.

That split is the whole point of a done-for-you model. The parts that are technical, repetitive and silently breakable become someone else's monitored responsibility; the parts that require your legal ownership and your money stay with you because they cannot be delegated.

A realistic sequence to follow

If you are starting from a domain that already sends mail and has email authentication in some state, the order of operations that wastes the least time and money is:

Check your enforcement level with the DMARC checker. If you are at p=none, do not buy anything yet. Use the staged rollout in the DMARC product to reach p=quarantine or p=reject first.
Confirm your trademark situation. If the logo is a registered trademark, you are on the VMC path. If not, read CMC for unregistered logos and decide whether a CMC fits, or whether registering the mark first is worthwhile.
Finalise the square SVG following designing a BIMI logo, and validate it. Lock it; this is now the canonical image for the certificate.
Let the platform publish the record and host the file, then verify with the BIMI checker.
Obtain the certificate through the platform's CSR, supplying your trademark evidence to the CA and paying the fee.
Confirm rendering by sending an authenticated test message to a Gmail and an Apple Mail account once the certificate is wired in. Remember the logo only appears on messages that pass DMARC, so test from a properly aligned sender.

For the wider context of how every record fits together and what "compliant" actually means across SPF, DKIM, DMARC, MTA-STS and BIMI, the requirements page is the map, and unfamiliar terms like selector, alignment and VMC are defined in the glossary.

The honest summary

BIMI is the most visible part of email authentication and, perversely, the part that does the least for security. It cannot exist without enforced DMARC, it demands a precisely constrained SVG, it usually requires a paid certificate backed by a trademark you must already own, and it renders per message only when that specific message authenticates. None of that is hard once you understand the chain; the difficulty is that every link fails silently. The value of hosting the whole path is that the silent, technical, monitored links become managed and watched, the BIMI record sits correctly alongside the rest of your authentication on a delegated zone, and you are left only with the two things that genuinely require you: the trademark and the cheque. Get the foundation right first, finalise one good square logo, and the verified mark in the inbox is the straightforward payoff at the end of a journey the platform has already taken your domain through.

Hosted BIMI end to end: from logo to verified mark in the inbox