Fixing the Invisible Logo: Your Guide to BIMI SVG Requirements

You did everything right. Your DMARC policy has been at `p=enforce` for weeks, the BIMI TXT record is live, and your logo's SVG is published at its HTTPS endpoint. You send a test email, open your inbox, and… nothing. Just a generic initial where your brand's mark should be. The frustration is real, and the cause is almost always a silent, picky failure in the SVG itself.

BIMI (Brand Indicators for Message Identification) promises a verified logo in the inbox, a powerful trust signal for your recipients. But that promise is conditional. Mailbox providers like Google and Yahoo have to fetch and render that logo safely, inside their app's most sensitive real estate. This means your SVG file must conform to a brutally strict standard.

This isn't a simple file format issue. It's a security-driven validation process. Let's walk through the exact requirements and how to debug them like an engineer.

The Spec Within the Spec: SVG 'Portable/Secure'

The root of most BIMI SVG problems lies in a misunderstanding of the required format. The official BIMI specification demands an 'SVG Tiny Portable/Secure' (SVG P/S) file. This is not the same as 'SVG Tiny 1.2,' a profile many graphic design tools can export. The 'P/S' is the critical part—a further restricted subset designed by the BIMI working group specifically for this high-risk use case.

Why so strict? Because that SVG is rendered by the Mail User Agent (MUA) in a privileged context. A malicious SVG could theoretically execute scripts, leak information via external resource calls, or even trigger a buffer overflow in a C++ rendering library. The SVG P/S profile aggressively locks down the file to be a single, self-contained, static vector document. It's a preventative security control, not just a file format preference.

Key Restrictions of SVG P/S

The profile explicitly forbids any element that could introduce interactivity, animation, or external dependencies. This includes `<script>` tags, any `on*` event handlers like `onclick`, and external references via `xlink:href` attributes. Even `<a>` hyperlink tags are out. The file must contain a `<title>` element with your company name, but it cannot contain any external stylesheet references, either inline in a `<style>` block or linked. All styling must be done via presentation attributes on the elements themselves (e.g., `fill="#FEFEFE"`). The base profile must also be declared as `baseProfile="tiny-ps"` in the root `<svg>` element.

Local Pre-Flight Checks Before You Deploy

Never debug in production. Before you even upload your SVG to a web server or CDN, you should validate it locally. Firing up a terminal is infinitely faster than updating a DNS record and waiting for caches to clear. Two command-line utilities are indispensable here: `xmllint` and `rsvg-convert`.

XML Structure Validation with `xmllint`

`xmllint` is a powerful tool for checking XML well-formedness and validity against a schema. While the official SVG P/S DTD isn't always easy to find and use, you can at least check for basic syntax errors that would cause any parser to fail immediately. A simple `--noout` check will tell you if the file is parsable.

xmllint --noout my-logo.svg
mylogo.svg:5: parser error : Opening and ending tag mismatch: title line 4 and head
</head>
^

An output like the one above is an immediate red flag. A clean, well-formed file will produce no output. This simple command catches mismatched tags, unclosed quotes, and other syntax bugs that creep in during manual edits.

Render Testing with `rsvg-convert`

Just because an SVG is valid XML doesn't mean it will render correctly. `rsvg-convert`, part of the `librsvg` library used by many applications, can act as a proxy for a mail client's renderer. Attempting to convert your SVG to a PNG is a great functional test.

Running `rsvg-convert -o test.png my-logo.svg` should execute silently and produce a valid PNG file. If it spits out warnings about unsupported elements or fails entirely, you know there's a feature in your SVG that a strict renderer will reject. This is often how you discover that your export from Adobe Illustrator included a proprietary tag that needs to be stripped out.

Stripping Banned Elements and Attributes

Most SVG creation tools are built for the web, where rich features are a good thing. For BIMI, they're a liability. You will almost certainly need to manually edit the SVG file in a text editor to achieve compliance.

External References and Data URIs

One of the most common and strictly forbidden features is the `xlink:href` attribute. It's an explicit vector for making external network requests. A mail client cannot risk a logo file 'phoning home' for tracking or security reasons. All parts of the image must be contained within the file.

This also applies to embedded raster images using data URIs. While technically 'self-contained,' the BIMI spec forbids `<image>` tags altogether to keep the file purely vector-based. If your logo includes a bitmap element, it must be vectorized or removed.

Producer-Specific XML and Comments

Graphic design software loves to leave its mark. Open an exported SVG in a text editor and you'll often find a block of comments at the top identifying the generator, along with editor-specific XML namespaces and data attributes. While XML comments are usually harmless, some parsers are configured to reject them. It's best practice to strip all comments and any XML tags or attributes prefixed with `sodipodi:`, `inkscape:`, or `i:`. Your final SVG should be clean, containing only elements from the SVG Tiny 1.2 and SVG P/S specifications.

CDN and Hosting: The Final Gatekeeper

Once your SVG is pristine, you need to host it correctly. The mail client's fetch-and-parse process is unforgiving. If your server or CDN headers are wrong, the logo will be rejected even if the file itself is perfect.

Content-Type is Non-Negotiable

The single most important server setting is the `Content-Type` header. It *must* be `image/svg+xml`. If your server sends `text/plain`, `application/xml`, or the default `application/octet-stream`, the MUA will immediately discard the response. There is no content-sniffing or second guessing. It's a hard-fail condition.

You can verify this with a simple `curl` command:

curl -I https://your-cdn.com/logo.svg

HTTP/2 200
content-type: image/svg+xml
cache-control: public, max-age=86400
accept-ranges: bytes

If that `content-type` line says anything else, you need to fix your CDN configuration. On Amazon S3, this is part of the object's metadata. On Cloudflare, you might need a Page Rule or a Worker to enforce the correct header. Do not overlook this.

Cache Policy and CORS

While not as critical as `Content-Type`, your caching headers matter. During debugging, you want a short `max-age` (like 300 seconds) so your changes propagate quickly. In production, a longer TTL (e.g., one day, `max-age=86400`) is fine. The server does not need to send any specific Cross-Origin Resource Sharing (CORS) headers; BIMI validators don't operate with the same-origin policy of a browser.

The Final Verdict: Using an End-to-End Checker

After you've run local checks and configured your hosting, it's time for a full, end-to-end validation. Several online tools, including the official BIMI Group checker, will simulate the entire process a mail provider performs. They check your organization's DMARC policy, find the BIMI record in DNS, fetch the SVG from its endpoint, and validate its contents against the SVG P/S profile.

Using one of these tools is the closest you can get to a definitive answer without waiting for email propagation. They provide clear pass/fail results for each step. A failure message like 'The SVG file is not a valid SVG Tiny P/S image' is your cue to revisit the file's contents, while an error like 'Could not fetch SVG' points directly to a hosting or network issue.

This final check separates theory from practice. It confirms not just that your SVG and DNS records are syntactically correct, but that they work together as the BIMI specification intends.

The takeaway

The strict requirements for a BIMI SVG aren't arbitrary hurdles; they're deliberate security controls. Your logo is being granted privileged access to a user's inbox, a surface where even a minor rendering bug or scripting vulnerability could be a major incident. The mail providers are defending their users and their platform, and your SVG must prove it can be trusted.

Getting the logo to appear is a process of elimination. Start with the file, validate it locally, strip it of anything non-essential, host it with the right headers, and run an end-to-end test. When you see that logo finally pop up, it's not just a branding win—it's a confirmation that you've successfully navigated a complex and important email security standard. These are precisely the kinds of linked dependencies MailSleuth.AI is designed to untangle when an analyst is tracing a message's full authentication story.