Why Your Logo Shows a Red X in Outlook — And How to Actually Fix It

You designed the signature. You tested it. It looked perfect on your screen. Then a client replied with a screenshot and a polite question: "Is something broken on your end?"

Where your logo should be, there's a small red X in a box. Or an empty grey rectangle. Or, on newer builds, just the alt text sitting awkwardly on its own line.

Here is the frustrating part. That red X almost never means your image file is corrupt. It means the recipient's email client tried to fetch or read the image and couldn't — and there are four completely different reasons that happens. They look identical to the person receiving your email, which is exactly why so many teams spend an afternoon "fixing" the wrong one.

This post walks through all four, how to tell which one is yours in about two minutes, and what the actual fix is for each.

First, understand what a red X actually means

An HTML email signature is just a small block of HTML. Your logo inside it is an <img> tag, and that tag has a src attribute pointing somewhere. When the recipient's email client renders your message, it follows that pointer.

The red X appears when it follows the pointer and comes back empty-handed.

That's it. The image itself might be a flawless 400×120 PNG sitting happily on your server. The failure is in the pointing — the path, the permission, the format, or the network in between. So the diagnostic question is never "what's wrong with my logo?" It's "where is my logo, and what stopped the recipient from reaching it?"

There are only two ways to answer the "where" part.

Linked images live on a web server. The src looks like https://cdn.yourcompany.com/logo.png. The image travels separately from the email; the recipient's client downloads it on open.

Embedded images travel inside the email itself, attached to the message and referenced by a Content-ID. The src looks like cid:logo123. Nothing gets downloaded from the internet.

Almost every red X story is a story about one of those two mechanisms failing. Let's take the causes in the order you should check them.

Cause 1: Your signature points to a file that only exists on your computer

This is the single most common cause, and the most maddening, because the signature looks completely fine to the person who built it.

When you build a signature by pasting content from a browser, a Word document, a CMS page, or an exported email template, you frequently drag along an image reference rather than the image. Sometimes that reference is an external URL. Sometimes — and this is the nasty version — it's a local file path.

Outlook for Windows stores signature files in your user profile, at:

%APPDATA%\Microsoft\Signatures\

Inside that folder you'll find your signature as an .htm file, plus a companion folder named something like Company Signature_files holding the images. Normally, when Outlook sends a message, it converts those local images into proper embedded attachments with Content-IDs. That's the system working as designed.

But when the HTML contains a hard-coded absolute path — something like file:///C:/Users/priya/Desktop/logo.png — Outlook doesn't always convert it. It renders it. On your machine, that file genuinely exists, so you see your logo. On every other machine on earth, it doesn't. Recipients get the red X.

Same story, different flavour: pasting from Google Drive, Dropbox, or OneDrive. Those share links aren't images. They're links to an HTML viewer page that usually requires authentication. Your browser resolves them because you're already signed in. Your recipient's email client requests them, receives an HTML login page instead of image bytes, and gives up.

How to confirm it

Send the signature to a personal email address on a completely different provider — a Gmail account if you're on Microsoft 365, or vice versa. Open it on your phone, on mobile data, signed out of your work account. If the logo is broken there but fine in your sent items, you've found your cause.

The fix

Don't paste images. Insert them properly.

In classic Outlook for Windows, open File → Options → Mail → Signatures, edit your signature, and use the Insert Picture button rather than pasting from a browser or document. This forces Outlook to take ownership of the image file and embed it correctly on send.

If you're maintaining hand-written HTML, pick one strategy deliberately:

• Host the image on a real web server on a stable, public HTTPS URL — ideally on a subdomain you control, like assets.yourcompany.com. Not a file path, not a cloud-drive share link, not a link to an image inside your CMS media library that might get reorganised next quarter.
• Or embed it as a CID reference, which most signature tools handle for you automatically.

One warning about HTTPS: if your image URL is http:// and the email client is enforcing secure content, the image gets blocked as mixed content. Always serve signature assets over HTTPS.

Cause 2: The message is being composed in plain text or RTF

This one has a tell that makes it easy to spot: the image is missing, but so is everything else. No colours, no font, no spacing — just a flat wall of grey text with your name at the bottom.

Email supports three composition formats, and only one of them can carry a logo.

HTML renders your signature the way you designed it. This is what you want.

Plain text carries no markup at all. There is no <img> tag to render, so the image doesn't appear as a red X — it simply vanishes, sometimes leaving the alt text behind.

Rich Text Format (RTF) is a Microsoft-specific format that predates modern HTML email. It technically supports images, but it handles them through a proprietary mechanism that frequently mangles signature graphics, and it converts attachments into a winmail.dat blob for anyone outside Outlook. Avoid it entirely.

The trap is that format can be set in more than one place, and a per-message setting quietly overrides your default. You can have HTML configured globally and still send a plain-text message because you replied to a plain-text email — many clients match the format of the message they're replying to.

How to confirm it

Open the message in your Sent folder. If the signature is unstyled — no brand colour, no layout, everything left-aligned in the default font — it's a format problem, not an image problem.

The fix

Set HTML as your default:

File → Options → Mail → Compose messages in this format → HTML

Then check the individual message. In an open compose window, look at the Format Text tab and confirm HTML is selected. If you frequently reply to plain-text senders, be aware that you may need to switch each reply back to HTML manually.

There's a related edge case worth knowing. If you copy your signature and paste it using Paste as Plain Text — or paste it into a field that strips formatting — you'll strip the markup even inside an HTML message. Always paste signatures with formatting intact.

Cause 3: The image is hosted somewhere that refuses to serve it

Now we're into the cases where your setup is technically correct and the image still breaks. This one catches people who've done everything right.

Your logo is a linked image on a real HTTPS URL. You paste that URL into a browser and it loads instantly. But when it's requested from inside an email, the server says no.

This happens for a few reasons.

Hotlink protection. Many web hosts and CDNs are configured to block requests for images that originate from outside your own domain. The server inspects the Referer header on the incoming request, sees that it isn't coming from your website, and returns a 403 Forbidden. This is a bandwidth-theft protection that works exactly as intended and just happens to break email signatures, because an email client is by definition not your website.

Authentication walls. If the image sits behind any kind of login — an intranet, a private S3 bucket, a staging environment with basic auth, a company Drive — the recipient's client gets a login prompt instead of image data.

Link rot. The single most under-appreciated cause. Your logo lives at /wp-content/uploads/2023/09/logo-final-v3.png. Someone tidies the media library. Someone migrates the site. Someone renames a folder. Every signature your company has ever sent now has a broken image in it, including the archived ones sitting in your clients' inboxes. Nobody notices for months.

Non-image URLs. A link to a page that displays an image is not a link to an image. If the URL doesn't end in a real image extension and return an image content type, it won't render.

How to confirm it

Copy the exact src URL out of your signature's HTML. Open a private or incognito browser window — this matters, because it strips your session cookies — and paste it in. If it loads in your normal window but fails in incognito, the problem is authentication. If it fails in both, the path is wrong or the file is gone.

For hotlink protection specifically, you can test with a command-line request that mimics an external referrer:

curl -I -e "https://mail.google.com" https://yourdomain.com/path/to/logo.png

A 200 OK is healthy. A 403 Forbidden means hotlink protection is blocking you.

The fix

Host signature assets somewhere purpose-built for it and treat those files as permanent infrastructure:

• Use a dedicated, publicly readable path — assets.yourcompany.com/email/logo.png — separate from your CMS media library, so a website redesign can't break it.
• Whitelist your signature asset directory in your hotlink protection rules, or disable protection for that specific path.
• Never rename or move these files. If the logo changes, update the signature template properly rather than swapping the file behind the same URL and hoping.
• Serve over HTTPS with a valid certificate.

Cause 4: The recipient's client or network is blocking external content

Here's the cause that many people never even consider, because there is nothing wrong with your signature at all.

Outlook — and most modern email clients — block the automatic download of external images by default. This is a deliberate privacy protection. Remotely hosted images can function as tracking pixels: the moment the image loads, the server hosting it learns that the message was opened, roughly when, and from what IP. Blocking automatic downloads shuts that surveillance channel down.

The side effect is that legitimate signature logos get caught in the same net. Your recipient sees a placeholder and an information bar along the top of the message offering to download pictures.

Layered on top of that, corporate networks add their own controls. Firewalls, proxies, and secure email gateways in banks, hospitals, government departments and large enterprises frequently strip or block outbound requests to external image hosts entirely. In those environments, the recipient can't unblock your logo even if they want to.

How to confirm it

If the recipient tells you the image appears after they click "Download Pictures," or after they add you to their Safe Senders list, this is your cause. It is also strongly indicated when the same signature renders correctly for most people and breaks consistently for contacts at one particular organisation.

The fix — and an honest caveat

You cannot control settings on the recipient's machine. Anyone promising otherwise is selling something. What you can do is reduce the blast radius:

Use embedded (CID) images for critical branding. Because embedded images travel inside the message rather than being fetched from the internet, external-content blocking doesn't touch them. The tradeoff is real, though: embedded images add weight to every single email, they show up as attachments in some clients, and they are frequently stripped out of long reply chains — which is precisely why so many people report that their logo appears in the first email of a thread and turns into a red X three replies down.

Always write meaningful alt text. This is the highest-value, lowest-effort fix in this entire post and almost nobody does it. When an image is blocked, the alt text is what shows instead. alt="" gives your recipient a naked red X. alt="Acme Technologies" gives them your company name in clean, readable text. Your signature degrades gracefully instead of looking broken.

Never make an image load-bearing. If your phone number, address, or job title exists only as pixels inside a graphic, then a blocked image doesn't just cost you a logo — it costs you the entire signature. Keep all text as real HTML text. Use images only for the logo, headshot, and social icons.

A two-minute diagnostic

Run these in order. Stop at the first failure.

1. Look at your Sent folder. Is the signature unstyled — no colours, no layout? → Cause 2, message format.
2. Send it to a personal address on a different provider and open it on mobile data, signed out. Broken there, fine in Sent? → Cause 1, local or unreachable path.
3. Copy the src URL and open it in an incognito window. Fails there, works normally? → Cause 3, hosting or authentication.
4. All of the above pass, but specific recipients still see a red X? → Cause 4, client or network blocking. Add alt text and consider embedding.

The part nobody tells you: fixing it once isn't the hard bit

Everything above is solvable for one person in about twenty minutes.

The real problem is that email signatures aren't a one-person artifact. They're a distributed system with a copy running on every laptop and phone in your company, and each copy drifts independently.

Someone rebuilds their signature after a laptop refresh and pastes the logo from the website instead of inserting it. Someone's Outlook decides to reply in plain text. A new hire copies a signature from a colleague's email, inheriting a two-year-old logo and a phone extension that no longer exists. Marketing migrates the website and every hosted logo URL 404s at once. You fix eight signatures, and three months later you're fixing eleven.

You can't audit what you can't see, and you can't see what leaves other people's outboxes. That's why the manual approach doesn't scale past roughly ten people — not because the fixes are hard, but because the drift is continuous and invisible.

Centralised signature management solves this structurally rather than symptomatically. One template, correctly built once, deployed to every mailbox from a single source of truth. Images hosted on infrastructure that doesn't move. HTML written as tables with inline styles so it renders predictably across Outlook, Gmail, Apple Mail and the rest. And when your logo changes, it changes everywhere at once, without a company-wide email asking people to please update their signature.

That's the whole idea behind Signforus — brand-consistent signatures deployed across your team in one click, built for teams of five to fifty rather than for enterprises with a dedicated IT department. We're in early access right now, and the first fifty teams get lifetime pricing locked in.

But whether or not you use a tool for it, the principle holds: a red X is a symptom of an unmanaged system, not a broken image. Fix the system and the symptom stops coming back.