The SVG That Broke BIMI: Debugging Vector Logos Before DNS

You did everything right. DMARC is enforced at `p=quarantine` or `p=reject`, an absolute prerequisite per RFC 7489. Your BIMI DNS record is syntactically perfect, passing every online checker you can find. Your logo is hosted on a public HTTPS endpoint with a valid certificate. Yet, in the user's inbox, there's nothing. Just the default round initial mocking your effort.

The culprit isn't your DNS provider. It isn't your DMARC policy. Nine times out of ten, the failure is silent, buried deep inside the logo file itself.

The humble SVG is not an image. It's an XML document — a set of instructions for a rendering engine. And for security reasons, mail clients are incredibly strict about which instructions they're willing to follow. Let's pull apart a failing SVG and see why.

Anatomy of a BIMI-Compliant SVG

Unlike a JPEG or PNG, which are grids of pixels, a Scalable Vector Graphic (SVG) is code. Open one in a text editor and you won't see pixel data; you'll see tags like `<path>`, `<circle>`, and `<g>`. This is an instruction set that tells a client how to draw the image from scratch using mathematical paths. This vector nature is why it scales perfectly, but it's also why it's a potential attack vector.

Because an SVG is parsed like code, it can theoretically contain anything an XML document can, including scripts, links to external resources, animations, and interactive elements. A mail client rendering a million logos a day cannot afford the security risk of executing untrusted code or making network calls for every single message. This is the entire motivation behind the strictness of BIMI's SVG requirements.

The Basic Requirements Checklist

Before we get into the weeds, your file must meet a baseline. The official BIMI group maintains the authoritative standard, but operationally, it boils down to this: a fixed `version="1.2"` and `baseProfile="tiny-ps"`. It must include a `<title>` element containing your company name. The file must be square. There are no size constraints in the spec, but mailbox providers recommend keeping it under 32KB.

Critically, the SVG cannot reference external assets. No external stylesheets, no linked images, no fonts pulled from Google Fonts. Everything required to render the logo must be self-contained within that single XML file. This is where most designers, using tools not built for this specific security context, unknowingly introduce breaking changes.

Case Study: A Visually Correct but Invalid SVG

Imagine your design team sends you `logo.svg`. You open it in Chrome, it looks perfect. It's a simple blue square. You publish it, and it fails. You open the file in a text editor and find this waiting for you.

<?xml version="1.0" encoding="UTF-8"?>
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" viewBox="0 0 100 100" onclick="alert('pwned')">
<defs>
<style>.cls-1{fill:#0055ff;}</style>
</defs>
<title>OurCo Inc.</title>
<a xlink:href="https://example.com/tracker">
<rect class="cls-1" width="100" height="100"/>
</a>
</svg> — Excerpt from a fictional but representative invalid SVG file.

This file is a security nightmare from a mail client's perspective, despite looking like a harmless blue square. It has at least three critical violations.

First, `version="1.1"` is wrong; BIMI requires `version="1.2"`. Second, it's missing the `baseProfile="tiny-ps"` attribute in the `<svg>` tag, which is an immediate disqualifier. Third, it contains multiple forbidden elements: an `onclick` JavaScript handler, a `<style>` block (in-document CSS is often forbidden, inline `style` attributes are preferred), and an `<a>` tag with an `xlink:href` attempting an external network call. A BIMI validator will reject this on sight.

The 'tiny-ps' Profile: Security in a Subset

So what is this `baseProfile="tiny-ps"` that mail providers demand? It specifies the "SVG Tiny Portable/Secure" profile, a highly restricted subset of the full SVG 1.2 specification. Think of it as a safe mode for rendering vectors.

The 'Tiny' part comes from the SVG Tiny 1.2 specification, originally designed for mobile phones and low-power devices. It strips out heavy features like gradients, filters, and complex text layouts. The 'Portable/Secure' (ps) part is an even stricter layer on top, explicitly forbidding any feature that could introduce security or privacy risks.

The Render-Time Threat Model

When a mailbox provider like Gmail or Yahoo Mail considers rendering your BIMI logo, they are thinking about the risk at scale. What could an attacker do if they could control the SVG displayed next to an email? They could try to execute script in the context of the mail client's web UI. They could embed tracking pixels via external `<a>` or `<image>` tags. They could even attempt to find vulnerabilities in the SVG rendering library itself, a classic client-side attack.

The `tiny-ps` profile neuters these threats by design. It's a declaration from you, the sender, that your SVG contains nothing but simple, static drawing instructions. No scripts, no external links, no animations, no user interaction. By enforcing this profile, the mail client can use a much simpler, more secure parser without worrying about the Pandora's box of a full web-rendering engine.

Manual Auditing: Your Linter is a Text Editor

While automated BIMI SVG checkers exist, you should know how to perform a manual audit. It’s faster and builds your intuition. Open the SVG in a plain text editor and use the search function (Ctrl+F) to hunt for forbidden strings.

Forbidden Elements and Attributes

Your search list should be aggressive. Look for these keywords. If you find any, your SVG is almost certainly invalid for BIMI:

Search for tag names like `<script>`, `<a>`, `<foreignObject>`, and `<use>`. Search for attribute names like `onclick`, `onmouseover`, `onload`, or any attribute starting with `on`. Look for any URL prefixes like `http:` or `https:`. Search specifically for `xlink:href`, which is the old SVG standard for linking. These are all red flags. Your file should contain drawing primitives (`<path>`, `<rect>`, `<circle>`, `<polygon>`), a `<title>`, and grouping tags (`<g>`). That’s about it.

Common Culprits from Design Tools

Graphic design tools like Adobe Illustrator or Inkscape are the most common source of invalid BIMI SVGs. Their default "Save as SVG" output is optimized for web browsers, not for the `tiny-ps` security profile. They often inject editor-specific metadata (e.g., `xmlns:adobe=...`), comments, `<defs>` blocks, and other features that, while technically valid SVG, are forbidden by BIMI's strict subset. Always use an "Export for web" or "Plain SVG" option if available, and even then, plan to hand-edit the output to strip it down to the bare essentials.

Final Pre-Flight: CDN Headers and Accessibility

Once your SVG file is clean, the final check is its delivery mechanism. Your logo must be hosted at an `https://` URL, and the server must respond with the correct `Content-Type` header. A simple `curl` command is your best friend here.

curl -I https://cdn.example.com/bimi/logo.svg

Look at the response headers. You need to see `HTTP/2 200` (or `HTTP/1.1 200 OK`). Crucially, you must also see `content-type: image/svg+xml`. If the content type is `text/plain` or `application/octet-stream`, the mail client will refuse to parse it, even if the file itself is perfect. Most modern CDNs and object storage services like S3 will serve this header correctly based on the `.svg` extension, but it's a frequent point of failure with misconfigured web servers.

Also, ensure the URL is globally accessible. Mailbox providers' servers are located all over the world. If your CDN has aggressive geo-blocking rules that prevent access from certain countries or IP ranges, the fetch will fail, and your logo won't display for users of that provider.

The takeaway

Getting BIMI to work is an exercise in precision. It's not just a DNS record pointing to an image; it's a verified chain of trust that extends from your DMARC policy all the way to the individual XML tags inside your logo file. Treat the SVG as a piece of code to be audited, not as a static image. Strip it down to its most basic, secure form, validate its `Content-Type` on delivery, and only then publish your BIMI record.

The process is exacting because the goal is to build verifiable identity into the inbox at massive scale. By understanding the security model behind the constraints, you can debug issues quickly and ensure your brand's logo appears exactly where you want it. Tools across the industry, including our own analysis platform at MailSleuth.AI, are continuously improving to make validating these technical nuances clearer for security teams.