> ## Documentation Index > Fetch the complete documentation index at: https://docs.maski.dev/llms.txt > Use this file to discover all available pages before exploring further. # Brand logo (BIMI) > Publish your brand logo so some mailbox providers can show it beside mail from your custom domain. What it requires, what it costs, and what Maski will and will not do for you. BIMI (Brand Indicators for Message Identification) is a standard that lets a mailbox provider look up a logo for a domain and draw it next to messages from that domain. Maski hosts your logo and your certificate, and tells you the record to publish. Brand logos are in a limited beta and available on Pro, on a [verified custom domain](/custom-domains). Opt in to beta from your account page. Publishing a logo does not make a logo appear. Every mailbox provider decides on its own rules, and most of them require a certificate you buy separately — see [What each provider requires](#what-each-provider-requires) before you spend anything. Maski does not sell, resell, or recommend certificates. ## What each provider requires This is a statement about each provider, not a prediction about your domain. Providers also apply sending-reputation rules that no configuration can guarantee. | Provider | Certificate required | | ---------- | ---------------------------------- | | Yahoo, AOL | None | | Gmail | A VMC or a CMC | | Apple Mail | A VMC only — a CMC is not accepted | A **VMC** (Verified Mark Certificate) attests a *registered trademark*. A **CMC** (Common Mark Certificate) attests a mark that is not registered. Both are bought from a Certificate Authority, and a VMC lists at roughly **\$1,350–1,750 a year** plus the trademark registration behind it. A logo with no certificate is a legitimate setup. Yahoo and AOL display it. Maski does not read whether the certificate you upload is a VMC or a CMC. That distinction lives in a field Maski deliberately does not parse, because mislabelling a CMC would promise an Apple Mail logo that never appears. Only you know which one you bought. ## The four preconditions The domain page shows these as a ladder, in this order. No provider considers a logo unless your domain's own DMARC policy is `p=quarantine` or `p=reject`. SVG Tiny PS, 32 KB or smaller. Maski validates it and refuses anything that does not conform. You publish this one by hand, after the logo is stored. Optional. PEM, 64 KB or smaller. ## DMARC: Maski reports it, and will never change it Maski publishes `v=DMARC1; p=none;` for a custom domain and treats DMARC as advisory. Moving to `p=quarantine` or `p=reject` is your change to make, at your DNS host. **Maski will never write an enforcing policy for you.** Enforcement applies to every sender on the domain — your own mail servers, a CRM, a newsletter tool, a payment provider — and Maski cannot see any of them. A policy Maski raised on your behalf could start silently quarantining mail Maski has nothing to do with. Press **Check status** on the domain page to see the policy Maski found. That check reads only your domain's own `p=` tag; an inherited organizational-domain policy is not followed, because providers evaluating your domain read your domain's record. ## Preparing the logo Maski enforces the SVG Tiny PS profile and **refuses** files that fail it. It never edits your logo: a rewritten file breaks the hash a certificate binds to, which produces a logo that shows nowhere with no way to diagnose it. **Editor metadata is the most common rejection**, and the least guessable — the file opens fine in every viewer. An Illustrator or Inkscape export carries an `rdf:RDF` block inside ``, which is not SVG and is refused. Delete the `` element, or re-export without metadata. The rest of the profile: * `version="1.2"` and `baseProfile="tiny-ps"` on the root `` element. * A **square** `viewBox`, and no `x` or `y` attribute on the root. * A `` naming the brand, as the first element inside the root. * No scripts, no animation, and nothing embedded or linked from outside the file. * 32 KB or smaller. A refused upload names the exact rule it broke. Fix it and upload again — a refusal stores nothing and costs you no DNS edit. ## Publishing the record Once a logo is stored, the domain page shows the TXT record to publish: | Purpose | Type | Host | Value | | ---------- | ---- | ------------------------ | ------------------------ | | Brand logo | TXT | `default._bimi.` | `v=BIMI1; l=;` | **You publish this record yourself.** Maski's [one-click DNS setup](/dns/overview) only runs while a domain is still verifying, and BIMI is set up after the domain is already live — so this record is always a manual edit, on every provider. The record is advisory. It never blocks activation, and a domain that never publishes it keeps working exactly as before. ### Adding a certificate changes the value With a certificate stored, the record gains an `a=` tag: ``` v=BIMI1; l=; a=; ``` So **adding or removing a certificate means republishing the record.** Nothing in Maski rewrites what is already in your zone, and the domain page will not notice the mismatch until you press **Check status**. Upload the certificate **before** the logo if you have both. The record's value gains its `a=` tag as soon as a certificate exists, so certificate-then-logo produces one final value and you edit DNS once. Replacing a **logo** never changes the record. The URL is derived from the domain, not from the file, so you can swap the artwork as often as you like without touching DNS. ## The certificate Maski accepts a PEM you already hold. It does not sell certificates, resell them, or recommend an issuer. * Upload the **certificate chain only**. A PEM that also contains a private key is refused outright — both files are served at public URLs, which is how receivers fetch them. * An already-expired certificate is refused at upload. * Maski warns you on the domain page before a stored certificate expires. ### When a certificate lapses An expired certificate shows no logo at any provider, and produces no other symptom. There is **no way to remove just the certificate.** Turning off BIMI clears both files. So if yours lapses and you want to fall back to the logo-only setup that Yahoo and AOL still display: On the domain page. This clears the logo and the certificate, and stops Maski advertising either. The record's value returns to the logo-only form, without the `a=` tag. The value changed, so replace what is in your zone. ## Where a logo actually helps BIMI applies to mail sent **from** your custom domain, so what it reaches depends on which Maski feature is sending. * **Replying, or [sending from an alias](/send-from-alias)** — the message leaves as `you@yourdomain.com` and the third party you are writing to is the one who sees the logo. This is where BIMI pays off. * **Forwarding** — mail arrives at your own inbox, from an address on your own domain. You will see your own logo. Note that the sender's name is preserved in the display name while the address is yours, so your brand attaches to mail you did not write. ## What Maski checks, and what it cannot **Check status** on the domain page reports four things: your DMARC policy, that the `default._bimi` record in your zone is the one Maski advertises, that the files behind it are stored and intact, and how long a stored certificate has left. None of these can reach a failing state. A missing logo still delivers the mail; BIMI is cosmetic. What it cannot tell you: * **Whether a receiver can actually fetch your files.** That needs a vantage point outside Maski's own network. * **Whether any provider will draw the logo.** Reputation gates and each provider's own certificate policy decide that, and neither is visible from here. ## Limits * One logo per domain. There is no per-alias or per-address logo. * Custom domains only. Shared Maski domains cannot carry your logo. * The logo and certificate apply to every address on the domain.