Insights and best practices for digital media professionals, by Manning Krull.

Home About Hire me!

OFT emails, part 1: the worst format in the universe

OFT emails are the absolute worst. It's a terrible format, at least for the ways people use them in my industry — advertising, specifically in the healthcare/pharma space.

I know way, way, way too much about OFT emails. They've haunted me for the last 15 years or so. I'm going to tell you everything about them, in the sincere hope that I can convince you to never use them, and/or convince your clients to never use them.

What are OFT emails?

Terrible, that's what they are! Ha! Okay. OFT (Outlook file template) emails are email messages that can be sent directly by our clients from their own Outlook account — this means no email deployment vendor is needed. Not needing to engage with a deployment vendor is something that's very attractive to our clients, because this means they save a ton of money. Deployment vendors may be expensive, but that's because they provide a tremendous amount of safety for our clients when it comes to sending emails. Lots more info on that below.

OFTs are relatively quick and cheap to create, but they come with some very significant drawbacks — these drawbacks, in my opinion, are serious enough to make this format simply not viable.

OFTs can look more or less like regular marketing emails; we design and program them as usual, and then we format the html file as an OFT file for handoff to the client. The one big difference, visually, is that they are desktop-only, so there's no mobile view; this format is not mobile-responsive, and that's a terrible thing in a world where most users open emails on mobile devices. Mobile users can open and view OFT emails, but they'll just see the desktop version, shrunk down, and possibly with some formatting errors.

OFTs can be used to send static content, or the content can be edited by the sender before sending (and this comes with some big risks).

OFTs can be considered relatively safe to use for internal communications — e.g. an announcement from our client to their internal team — but they are extremely risky for public communications; I'd argue they are way too risky to be considered a viable format for sending anything to the public. More on all of this coming up.

Issues and risks

Now, the good (bad!) stuff! My hope is you'll read this long list of issues and risks and ask yourself how this is a real format and why anyone would want to use it. It's absolutely critical that we and our clients understand and accept the risks associated with the OFT email format if we're going to consider creating one (which we should not). Send your client this article!

Okay, here we go...

Not mobile responsive

On mobile devices, OFT emails display as the desktop layout, simply shrunk down to fit the screen. This means the text will be very small, making the email not readable at normal size when viewed on mobile. The user has to zoom in to read it. Bad user experience. Bad for accessibility.

There's no mobile support for this format — so any unexpected sizing/spacing/font/etc issues on mobile generally cannot be corrected.

Mobile usage for email is huge; well over 50% for some brands — do we really want to make an email that doesn't look great on mobile, and/or isn't readable on mobile?

(Not mobile responsive means we only have to lay out the desktop view in art. We should not lay out a mobile view.)

Only supported for Windows/Outlook

OFT is a Microsoft- and Outlook-specific format. We can only ensure this format will display correctly in Outlook for desktop on a Windows machine. We can't reliably troubleshoot for Mac, Gmail, Outlook webmail, Yahoo Mail, mobile, tablet, etc.

The simpler the layout, the safer it will be for non-Windows/non-Outlook platforms. The most common issues we see in non-Windows/non-Outlook platforms are minor spacing issues, sizing issues, and font issues. Again, these cannot be resolved for Mac, webmail, or mobile. You're sending an email out into the world that is likely to show minor errors for many users.

Sender can change the content

With any OFT email, the sender can edit the content however they wish before sending. This may be desirable in some cases — e.g. a newsletter template that the client wishes to edit and send monthly — but often it is not. There's no way to stop the sender from editing.

As mentioned above, this is less risky for internal communications, but extremely risky for public-facing communications, no matter whom is sending. Mistakes happen.

The absolute worst case is something like this: in an OFT email going from a pharma company to doctors, the sender accidentally deletes part of the Important Safety Information, or they type in a message that's not approved by legal, or they accidentally paste in something from the wrong source, etc. There is no way to prevent this. Scary!

Preheader not supported

There's no way to include a preheader in an OFT email. The preheader area in the user's inbox will either display the first line of content from the body of the email, or, if the first piece of content is the header image, then the alt text of that image will be displayed in the preheader area.

Preheader is an important tool for driving engagement and getting users to open an email. The fact that this format doesn't support preheader means there's a lower chance for engagement.

Unsubscribe link not supported

We can't include a typical unsubscribe link in an OFT. This is normally handled by the deployment vendor who's blasting the email and managing the list of subscriptions. No vendor = no unsub link. (If the brand has a manual unsubscribe page on their website, we can link to that, and then the user will have to enter their email address and click an unsubscribe button. This is very old-fashioned and not a great user experience.)

Web-based version not supported

We can't include a "click here to view in browser" link. This is normally generated and hosted by the email deployment vendor blasting the email. No vendor = no web-based version. (I mean, we could arrange web hosting space and host the web-based version ourselves, but this seems like way too much effort for an email.)

May be flagged as spam

Part of what professional email deployment vendors offer is a high sender credibility rating that helps the recipients' mail server recognize that the messages are legitimate, so they don't get flagged as spam. When a user manually sends an OFT email to someone outside of their organization, there's a greater possibility it will be flagged as spam.

Can't control "From" field

When we send an email through an email deployment vendor, we can have the From field say anything we want. With an OFT email, the From field will always be the name and email address of the sender; whoever that person is.

In some cases clients want the message to come from, for example, a program name or their brand name, rather than their real name. This just isn't possible with OFT emails.

Jump links not supported

Jump links (links that a user can tap/click to jump down to a section of content) do not work in OFT emails — for example, we can't include a link at the top that jumps down to a certain section below.

Pharma emails typically have a link at the top to jump down to the Important Safety Information section; this isn't possible in an OFT email.

Some clients have requested an internal newsletter template with a Table of Contents at the top that links down to each section; this is also just not possible in an OFT.

No tracking of opens or clicks

There is no native analytics or tracking in OFT emails. There's no way to check open rates or get data on which links were clicked by which users. This is something that's normally handled and provided by the email deployment vendor. No vendor = no tracking/data.

Many of our clients are very interested in this analytical data for their emails; without this data, how will they know if the email was successful?

Risk of user error

I touched on this above under "Sender can change the content." Since the OFT email is being deployed manually by our client and not by an email deployment vendor, there's a risk that the sender could do something wrong while deploying. They might send it to incorrect recipients. They might neglect to edit fields that need to be edited (e.g. "Dear Dr [NAME]"). They might edit or delete content in a way other than what our client desires, either intentionally or accidentally. They might neglect to fix text formatting that looks bad; this often happens when a user pastes in content from another source. The text may be a different font, different color, different size, etc.

They might forward the email from their sent mail — this can cause layout errors. We should always include instructions for editing and sending OFT emails, but the sender may ignore or forget them.

Must be sent from a Windows machine

OFT emails can only be sent from a Windows machine, using the Outlook desktop app. They can't be sent from a Mac, or from webmail (even Outlook webmail), etc. It's critical we discuss this with the client before agreeing to create an OFT email.

A lot of our individual clients use Outlook webmail (rather than the desktop application), and/or a Mac, as their default access to work email. If this is the case, they won't be able to send an OFT. I've seen it happen; the team creates an OFT for a client and then the client can't open and send it because they're on a Mac, and no one had this conversation with them ahead of time. Ugly situation.

To be clear, recipients can receive and view the OFT email on any platform, but the sender must use Windows and Outlook.

I've seen this happen: The agency team designed and built an OFT email for a client, so that the client's staff could all use it to send news to their customers. And then we found out their entire company uses Gmail for corporate email. None of the client's staff were able to open and send the OFT. Total failure.

Include's sender's email sig by default

If the client's Outlook is set to display their corporate email signature by default, then it will appear at the end of an OFT email when they open it to send. For some OFT emails this may be fine — depending on the strategy and the audience — but for others it may be a problem.

The sender can manually delete the sig before sending. However, if the email is long, they may not see their sig at the bottom, so they may not realize they need to delete it.

Link styling bug

This is a complicated one. OFT emails sometimes have a bug where the link styles default to blue and underlined, even if the links were designed and programmed to have a different style.

This might not be the end of the world, but if your CTA is designed to be (for example) a blue box with white text, and the link inside defaults to blue, now you have an unreadable CTA (blue text on blue background).

This bug appears to happen totally randomly. There is no fix.

Because of the risk of this bug, I recommend designing all links to be a dark color on a light background. This way if the link color defaults to blue, the link will still be legible.

Gmail attachment bug

Another random one. In some cases, when a recipient opens an OFT email in Gmail, they see an attached file that we did not include — it's often a blank image file named something like "image001.gif." There is no fix for this; the problem is due to the lack of support from Microsoft for any platform other than Windows/Outlook. I can't stress enough, we can only count on OFT emails to display correctly in Windows/Outlook. In all other platforms — Mac, webmail, phones, etc — there is the risk for very strange bugs and errors.

This bug doesn't cause any real harm, but the presence of a mysterious attachment may make the email look suspicious, like we're sending malware.

"Dear [Name]" not supported if sending to multiple recipients

It's fine to include editable "Dear [Name]" language in an OFT email. The sender can edit that before sending. However, be aware, this means the sender has to manually open, edit, and send the OFT email to each recipient, one at a time. There's no way to automate this, i.e. sending the OFT to a hundred people in one go and dynamically populating the "Dear [Name]" text. I've had some clients be very surprised and disappointed by that. Again, this is something that a proper email deployment vendor can handle easily.

Random inexplicable bugs

OFT emails produce some random, baffling, one-off bugs; they'll happen in just one email, completely inexplicably, and then magically never happen again. Here's an unbelievable example:

I worked on a set of three emails for a brand, all using the same html template. I programmed the emails myself; I created the first one, and then used that html file as a template for the other ones. They all containing long bulleted lists.

In one of the emails, the bullets displayed much too small; they looked like floating periods rather than round dots. Imagine that: three emails, all very similar, two with normal-looking bullets, and one with microscopic bullets. Exact same html markup for all three.

After tons and tons of experimenting, I determined that this was happening (inexplicably!) because this particular email had a much longer bulleted list than the others. When I removed some items from the list, the bullets became the normal size. There is absolutely no explanation for this, other than the fact that this format is extremely buggy, unstable, and generally wonky.

The potential for this kind of impossibe-to-predict, impossibe-to-solve problem is just one more reason no one should ever use this format. It's too risky for everyone involved.

Problems with tiny images

For some reason, any images smaller than 15x15 pixels end up causing very strange spacing issues that can't be resolved; the images float too high or too low, or they have weird extra space around them. This can sometimes be mitigated by slicing any very small images at larger dimensions, with extra white space in them. You still may encounter weird problems with spacing and alignment with small images in general.

New issues all the time

As web browsers, mail apps, and devices continue to change, new bugs periodically arise regarding how OFT emails are rendered across platforms. Microsoft's lack of support for non-Outlook platforms doesn't change, while email platforms continue to evolve. If a team member or client reports an unusual bug in an OFT email, the first thing to do is confirm that they're viewing the email in Windows/Outlook. If not, there's usually no fix.

"As long as the client is aware"

Notice how many times that phrase appears in the "Risk level" boxes above? Be aware: all of those "Low"s that we might want to casually dismiss will become "High"s if we do not communicate these things to our client.

No matter what's been discussed, very frequently, after an OFT email is built, the team and/or client asks if we can fix x/y/z, on phones, in webmail, etc. The answer is no, unfortunately! See above! These limitations of the OFT format are just that. There are no workarounds. Which is why I can't stress enough, the team and client must understand these limitations before proceeding. I can tell you so many horror stories...

Manning's soapbox

In closing...

As digital professionals, we should talk our clients out of using the OFT format for public communication. It's too risky and too poorly supported across platforms.

As a digital professionals, we should not create any media that is not supported for mobile. Does that mean I think we should not create OFT emails, period? Why yes! Yes, I do! I hope I've made that very clear. However, some clients love them, so OFTs are probably not going away any time soon.

It is very difficult to make an OFT email accessible to users with visual impairments and certain other disabilities, because the format is not mobile responsive. Since mobile devices will just show our desktop view shrunk down to fit the phone screen, this means most or all of the text will be smaller than our minimum recommended font size for accessibility. If the link styling bug (mentioned above) occurs, that can result in low color contrast that puts us out of ADA compliance. Remember, accessibility is our legal and ethical responsibility for all digital materials.

I've worked with teams whose clients have reported tremendous disappointment with OFT emails — every time, it's because they weren't aware of the risks and issues (or they conveniently forgot). I can't state this enough, it is absolutely critical that we explain the risks and issues of OFT emails to our clients and get them to accept before proceeding.

I've also had clients who were happy with OFT emails, because we were very careful to make sure they knew what they were getting into, and we designed the email in a way to reduce as much risk as possible.

If we want to avoid OFT emails, what other options exist? The only other real options are to send an email through an email deployment vendor (for mass emailing), or through Veeva Approved Email (for one-on-one communication to doctors), both of which are more expensive and time-consuming, but both are supported across all platforms and come without the risk of user error, compatibility issues, etc.

Let's talk to our clients about all of these things! We can and should spin all of this in a positive light — we want to make good digital things for our clients! Not... this crap. :)

Still haven't had enough?

I ended up breaking this whole thing into four parts! Here's the rest...

OFT emails, part 2: more info on this garbage format

OFT emails, part 3: info for creatives

OFT emails, part 4: info for devs

Good luck! You're gonna need it.

– Manning

Back to top  |  Articles list

Questions/comments? Feel free to contact me at manning@manningkrull.com. I update these articles pretty frequently — best practices evolve over time as the world of digital quickly changes, and I always welcome insights from others.

© 2009-2025 Manning Krull. All rights reserved.

A note on AI: While I believe the technologies commonly referred to as "AI" are fascinating tools with tremendous potential, as a writer I don't believe they should be used for expressing one's personal philosophies about complex subject matter. So every word on this site is written by yours truly, unless otherwise noted.