Preparing a BIMI logo: SVG Tiny PS

18 June 2026 · 11 min read

BIMI is the standard that puts your brand's logo next to your messages in the inbox, and almost everyone who tries to switch it on hits the same wall: the logo file. Not the DNS record, not the verification certificate, but the humble image. You hand a designer the request "give me our logo as an SVG" and they cheerfully export one from their design tool, you publish it, and the mailbox providers quietly refuse to display it. Nothing is obviously wrong. The file opens fine in a browser. It just does not meet the one profile BIMI actually accepts, and BIMI is unforgiving about that profile in a way most image specifications are not.

This article is about getting that logo file right. It covers what the SVG Tiny PS profile is and why BIMI insists on it, the squareness and sizing rules that catch people out, how and where the file has to be hosted, and the specific validation failures that come up again and again. If you only want to know whether your current logo passes, the BIMI checker inspects your published record and the file behind it and tells you what is wrong. The rest of this is the detail behind that verdict, so that when it flags something you know exactly what to change.

Why BIMI is so fussy about the image at all

It helps to understand why the rules exist before you fight them. A BIMI logo is not a decorative image on a web page that a browser will do its best to render however it can. It is a piece of brand identity that a mailbox provider is going to display, at small sizes, next to your name, as a signal of authenticity. The whole point of BIMI is trust: a recipient sees your verified logo and is reassured the message is genuinely from you. That only works if the provider can render the logo predictably, safely and identically across every client, and if the file cannot be used as an attack surface.

Ordinary SVG is a large and powerful format. It can embed scripts, pull in external resources, run animations, reference fonts that may not be present, and carry interactive elements. None of that belongs in a logo that a mailbox provider must render inside a hostile environment millions of times a day. So BIMI does not accept ordinary SVG. It accepts exactly one restricted dialect, and a file that strays outside that dialect is rejected wholesale rather than rendered partially. There is no graceful degradation. The logo either conforms or it does not appear.

This is the single most important mental shift. You are not producing an image that needs to look good. You are producing a file that needs to conform to a profile. Looking good is necessary but nowhere near sufficient.

What SVG Tiny PS actually is

The accepted dialect is called SVG Portable/Secure, almost always written SVG Tiny PS or SVG Tiny 1.2 PS. It is built on top of an older, deliberately small subset of SVG called SVG Tiny 1.2, which was originally designed for constrained devices like early mobile phones. BIMI takes that small subset and adds a further "Portable/Secure" (PS) layer of restrictions on top, removing anything that could be a security or rendering risk.

Two requirements sit at the very top of the file and are checked first.

• The root <svg> element must declare the version attribute version="1.2" and the baseProfile baseProfile="tiny-ps". These two attributes are how a validator knows you are even claiming to follow the profile. Leaving them off is the most common single reason a perfectly drawn logo is rejected.
• The file must contain a single <title> element as the first child of the root, giving the logo a human-readable name. This is used for accessibility and is mandatory, not optional.

Beyond those headline attributes, the PS profile bans a long list of things that ordinary SVG allows. The practical bans you need to internalise are these.

• No scripts. Any <script> element, or any event handler attribute such as onload or onclick, fails the file outright. This is a security rule and it is absolute.
• No external references. The image must be entirely self-contained. No <image> elements pointing at external bitmaps, no external stylesheets, no xlink:href pulling in remote resources, no embedded raster data. If a pixel of your logo lives outside the file, the file is invalid.
• No animation. Elements like <animate> and <animateTransform> are not allowed. The logo is a still image.
• No <foreignObject>, no embedded HTML, no interactivity. Nothing that hands rendering off to another engine.
• Text is discouraged and effectively must be converted to paths. SVG text relies on fonts that the renderer may not have, so any wording in your logo (including a wordmark) should be converted to vector outlines. A <text> element that depends on a font is a portability risk and will commonly be flagged.

What you are left with is a small, flat, self-contained vector file made of shapes and paths, with a declared profile and a title. That is by design. The narrowness is the feature.

Squareness: the rule nobody expects

Here is the rule that surprises almost everyone, because it has nothing to do with file format and everything to do with geometry. A BIMI logo must be square. Not roughly square, not square-ish, but a 1:1 aspect ratio defined by the viewBox.

The viewBox attribute on the root <svg> defines the coordinate space of the image as four numbers: min-x, min-y, width and height. For BIMI the width and height must be equal. A viewBox="0 0 400 400" is square and acceptable. A viewBox="0 0 600 400" is a rectangle and will be rejected even if it draws a lovely logo.

This trips up real brands constantly, because most logos are not square. A horizontal wordmark, a logo with the company name set beside a symbol, a banner-shaped lockup: none of these fit a square frame. Mailbox providers render the BIMI logo inside a small square or circular avatar slot, the same shape an account photo would occupy, so a wide logo simply does not work there.

The fix is a design decision, not a technical one. You take the square-friendly part of your identity, usually the symbol or monogram rather than the full horizontal lockup, and you centre it inside a square viewBox with comfortable padding around it. Think of how an app icon is constructed: the mark sits in the middle of a square with breathing room, not jammed edge to edge. Many brands maintain a dedicated "avatar" or "icon" version of their logo precisely for slots like this, and that is the version you want for BIMI. If your only logo is a long horizontal one, expect to commission a square variant before BIMI is viable.

A related detail: give the square a deliberate background. Transparent backgrounds can render unpredictably against the provider's own interface colour, and a logo designed for a white page can vanish against a dark inbox theme. A solid, brand-appropriate background fill inside the square gives you a predictable result everywhere.

Sizing and weight

Because the format is vector, there is no pixel resolution to worry about: an SVG scales cleanly to whatever size the provider renders it at, which is the whole reason BIMI uses vectors rather than a PNG. What you do need to watch is file size. The specification expects a small file, and the practical target is well under 32 kilobytes. Most compliant logos come in at a few kilobytes. If your exported file is hundreds of kilobytes, that is a strong sign it is carrying junk: editor metadata, hidden layers, unused definitions, absurdly precise path coordinates, or an embedded bitmap you did not know was there.

Keeping the file small is mostly about cleaning it. Flatten the artwork to a minimal set of paths, remove editor-specific metadata, drop unused gradient and clip-path definitions, and reduce path coordinate precision to something sensible. A logo does not need fourteen decimal places of precision on every point. Tools that optimise SVG can strip most of this automatically, but check the result afterwards, because aggressive optimisers sometimes remove the very attributes BIMI requires, such as the baseProfile, while tidying up. Optimise, then re-add or re-confirm the profile attributes, then validate.

Hosting the file: HTTPS is not optional

Once you have a conforming, square, lightweight file, it has to live somewhere a mailbox provider can fetch it, and BIMI is strict about where that is.

The logo must be served over HTTPS. A plain http:// URL is rejected. The certificate on the host must be valid: not expired, not self-signed, matching the hostname. Providers fetch the logo automatically and will not negotiate around a broken or untrusted certificate, so a logo hosted behind a misconfigured TLS setup simply never displays.

A few more hosting realities matter in practice.

• The URL goes in your BIMI DNS record. BIMI is published as a TXT record at default._bimi.yourdomain.com, and inside it the l= tag holds the HTTPS URL of the SVG. The a= tag, where present, holds the URL of the verification certificate (the VMC or CMC). The BIMI checker reads this record for you and follows the l= URL to fetch and inspect the actual file, which is why it can catch both record errors and file errors in one pass.
• The file must be reachable without authentication. No login wall, no IP allowlist, no signed-URL expiry. If a provider's fetcher cannot retrieve the file anonymously, the logo will not show.
• The response should serve the right content type, ideally image/svg+xml, and should not be gzip-mangled or wrapped in anything unexpected. A misconfigured server that returns the SVG with the wrong type, or returns an HTML error page where the SVG should be, is a quietly common failure.
• Stability matters. This is not a file you swap out casually. Mailbox providers and certificate authorities tie verification to the file at that URL, so changing the artwork can mean re-validating. Treat the hosted logo as a fixed asset with a stable URL, not as something a marketing team edits in place.

If you would rather not manage TXT records, certificate URLs and a stable HTTPS asset yourself, this is exactly the kind of plumbing the hosted BIMI product takes off your plate, hosting the file, publishing the record and keeping the references consistent.

The validation failures you will actually hit

Knowing the rules in the abstract is useful, but in practice the same handful of failures account for most rejected logos. Here is what they look like and what each one really means.

• Missing baseProfile="tiny-ps" or version="1.2". The file is drawn correctly but never declares the profile, so the validator does not accept it as Tiny PS at all. Fix: add both attributes to the root <svg> element. This is the number one cause of "but it looks fine" rejections.
• No <title> element. Easy to forget, mandatory to include. The title must be present and should be the first child of the root. Fix: add <title>Your Brand</title> right after the opening <svg> tag.
• Non-square viewBox. Width and height differ, so the aspect ratio is not 1:1. Fix: redraw or re-frame the artwork inside a square viewBox with the mark centred. This is a design fix, not a one-line edit.
• Forbidden elements present. A <script>, an onload handler, an <animate>, a <foreignObject>, or an embedded raster <image>. These often arrive invisibly from the design tool that exported the file. Fix: open the SVG as text and remove them, or re-export with a cleaner profile, then re-check.
• External references. An xlink:href pointing at a remote font, stylesheet or image. The file must be wholly self-contained. Fix: inline or remove the dependency; convert text to outlined paths so no external font is needed.
• Live <text> depending on a font. The renderer may not have the font, so the wordmark shifts or disappears. Fix: convert all text to vector paths in your design tool before export.
• Served over HTTP, or behind a bad certificate. The file itself is perfect but unreachable in the way BIMI requires. Fix: host on a proper HTTPS endpoint with a valid certificate and an anonymous, correctly typed response.
• File far too large. Usually editor cruft or an embedded bitmap. Fix: optimise the SVG, then re-confirm the profile attributes survived the optimisation.

A sensible order of operations saves a lot of back and forth: get the artwork square first, export to clean SVG with text outlined, run it through an optimiser, manually confirm version, baseProfile and <title> are present, host it on HTTPS, then run the BIMI checker end to end. Working in that sequence means each later check is not undone by an earlier omission.

Where BIMI sits in the bigger picture

It is worth being clear about one thing that the logo work can obscure: the file is the last mile, not the first. BIMI only displays once your domain is authenticating properly and enforcing DMARC. Mailbox providers require your domain to be at an enforced DMARC policy, meaning p=quarantine or p=reject, not p=none, before they will even consider showing your logo. A flawless SVG on a domain still sitting at p=none shows nothing, because the precondition is not met.

That ordering is deliberate and it is also good for you. BIMI is the reward at the end of getting authentication right, not a shortcut around it. The logo is a visible payoff for having put SPF, DKIM and DMARC in order and having driven your policy to enforcement without breaking your legitimate mail. If you are not there yet, the logo can wait; the path to enforcement is the work that matters first. Our guides on reaching p=reject without breaking email and on whether you even need BIMI put the logo step in its proper place in that sequence, and the requirements overview lays out exactly which mailbox providers expect what.

If you want to see where your domain stands across the whole stack before you spend a designer's afternoon on a square SVG, the free tools cover each layer: the DMARC checker for your policy, the SPF checker and DKIM checker for the underlying authentication, the MTA-STS checker for transport security, and the BIMI checker for the record and logo themselves.

The practical takeaway

Preparing a BIMI logo is a small, precise task wearing the disguise of a creative one. The image has to be a self-contained, script-free, animation-free SVG that declares the Tiny PS profile with version="1.2" and baseProfile="tiny-ps", carries a <title>, fits inside a square viewBox, stays comfortably under 32 kilobytes, and is served from a stable HTTPS URL with a valid certificate. Almost every rejection traces back to one of those points, and almost every one of them is fixable in a single focused pass once you know which it is.

Get the artwork square, export it clean, confirm the profile attributes survived, host it over HTTPS, and validate the whole chain with the BIMI checker. And if you would rather skip the DNS record, the certificate reference and the file hosting altogether, the done-for-you BIMI service handles the publishing while you concentrate on having a logo worth showing. Either way, remember the precondition: the logo is the visible finish line, and an enforced DMARC policy is what earns the right to cross it.