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

Disclaimer: The views expressed on this site are my own and do not necessarily reflect those of my employers. :)   – Manning Krull

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

If you're new to OFT emails, start here! OFT emails, part 1: the worst format in the universe

If all my caveats in part 1 didn't convince you not to make an OFT email, then here's some further info about the format that you might find helpful.

Three ways to make an OFT email

1. In my career most OFT emails I've seen were first laid out in art (Figma, XD, Photoshop, etc), then a developer programs the email in html, and then they package up the html as an OFT file. This is the method I recommend, and it's the method that gives us the most control over visuals.

However, OFT emails can also be created without art and dev.

2. Another way to make an OFT is to create it directly in Outlook. Anyone with the Outlook desktop app for Windows can open a new mail message, enter some content, paste in some images, do some formating of the text, etc, and then save that as an OFT file. However, with this method it's much more difficult to achieve something that looks like a traditionally-designed marketing email. Option 1 is the way to do that.

3. You can also lay out an email in Word, then highlight all and copy, and then (using Windows and the Outlook destkop app) paste into a new Outlook message, and save that as an OFT file. Again, this probably won't result in something that looks like a traditionally-designed email.

If you're going with option 2 or 3, remember to use Arial for all of your text. If you use a different font, the recipient's machine may not have that font installed, and the text will default to something ugly like Times New Roman.

How does mobile first apply to OFT emails?

It doesn't. :( Normally, all digital materials that will be viewed on both mobile and desktop screens should be designed mobile-first. However, the OFT format is not mobile-responsive. On mobile, OFT emails simply appear as the desktop view, shrunk down. This can create challenges for readability and accessibility on mobile, and it's just a poor user experience overall.

My recommendation is to design for desktop only, but to use the largest font sizes possible that look okay for desktop. This will ensure that the email is still fairly readable on mobile. Bigger is going to be better every time.

Some teams I've worked with have chosen to design OFT emails at 480 pixels wide (rather than 600) for desktop — and, again, with the largest font sizes possible. This means that when the email shrinks down for mobile, it doesn't need to shrink as much; there's a greater chance it will be readable and look good on mobile. On desktop the email will occupy a narrower space than what we see in most emails, but not drastically so. I think this is a great approach for creating something that's not responsive but still looks decent on both mobile and desktop.

Subject

The email subject line is handled differently in OFT emails than it is in typical marketing emails.

With typical marketing emails, the email deployment vendor adds the subject; they receive it from the creative agency and they simply paste it into a field in their dashboard when they're sending the email.

This isn't the case for OFT emails (as there's no deployment vendor). In OFTs, the subject can be added at two different stages:

1. The developer who's programming the email can add the subject when they're saving the OFT file. This means that when the sender opens the OFT email to send it, the subject is already populated along with all of the content.

2. The developer can also leave the subject field blank, and the sender can add a subject when they're ready to send the OFT email.

Both of these methods are easy. The first method is a little nicer for the client/sender.

In any case, the sender is able to edit the subject whether the dev has added it in the OFT or not. I've worked on some OFT projects where the client wants to change the subject a bit when they send it to different people. That's no problem.

One of the reasons I wanted to explain all of this is that, for typical emails, when the dev receives the creative file(s) to program the email, they don't need to receive the subject line. Dev normally never touches the subject at all; it's not part of their html file. With OFT emails, we should provide the subject line to dev if we have it.

Instructions for sending

Here are instructions and notes that you can share with your client when you're delivering an OFT file to them that they're going to send. I've written slightly different versions of all of this for OFTs that are meant to be static content, and OFTs where the sender will do some editing before they send.

Instructions for sending — static email

Instructions for sending — editable email

Notes to include

When I've made OFT emails for clients (usually at gunpoint), I include these three notes along with the sending instructions, every single time; this is my attempt at one more layer of CYA for this unstable, unpredictable format.

Can we lock the content?

I get asked this a lot — "Can we lock the content in the OFT email so the sender can't edit it?" The answer is: not exactly...

We can format all the content as an image*, making the content harder to edit. However, the sender can still select and delete the image — either accidentally or intentionally. The sender can also still type in the body of the email above or below the image — either accidentally or intentionally.

The reality is, we can't stop them from pasting in new images, or even editing the images in Photoshop and putting them back in. If the client is that paranoid, the OFT format is not for them. Have I mentioned this format is terrible?

So, there's really no 100% foolproof way to lock the content so the sender cannot change it.

(*Note for devs: if you're ever doing this in an email, make sure you slice all the content into images that are no taller than 800 pixels. Don't just export the whole layout as a super-tall image; break it up into pieces and stack 'em. Extremely tall images won't display in some email platforms.)

Editable text areas

I've worked on some OFT emails where we're asked to include an area of editable text, like "Dear Dr. [NAME]." All text in an OFT is editable by default, so this is no problem, but there are a few caveats:

The sender must remember to edit the text before sending — so there's a risk of user error.

We could format the text to be magenta or another color (e.g. "Dear Dr. [NAME]"), which could help draw attention to the text and remind the sender that they need to edit it, but then they have to not only change the text, they have to remember to change the text color as well — another risk of user error.

However, if we don't format the text as magenta or some other color, it may be easy for the sender to miss.

If the editable area is at the bottom of a long email (e.g. a sign-off), it won't be visible when the sender opens the OFT file (unless they scroll down through the whole thing), and so they may forget to edit it before sending — another risk of user error.

There's simply no way to ensure that the sender addresses all editable areas before sending.

Sending one-on-one versus sending to a group

The sender can send an OFT to just one person, or to a group of people. It's just a matter of how many recipients they add in the "To" field (or Cc or Bcc).

However, if your OFT has an editable salutation, like "Dear Dr. [NAME]," then the sender must manually edit the name. This means they can only send this email to one person at a time. There's no way to send the email to multiple recipients and have the name get populated individually for each of them.

In a typical marketing email that's deployed by a vendor, it's possible to have a dynamic salutation that's automatically populated for each recipient. There's simply no way to do that in an OFT email. I've had some clients who were surprised/disappointed by this.

A note on editable OFT templates

Sometimes we want to create an OFT that's an editable, reusable template for a client. This is fine! It's what the format is intended for. However, there are limits to how editable we can make them.

If we're creating a simple newsletter template with, say, a header image with paragraphs below, this is no problem; the client can easily type into the content area, paste in content, delete content, create links, change font colors, etc.

However, if we're going for a more complex layout, with things like (for example) images floating next to text, columns and tables of text, bulleted lists, etc, then this content may be much more difficult or even impossible for the client to edit in a way that looks nice. We should not design editable templates with complex content layouts.

Think about it like editing content in Word. Regular paragraphs are easy to edit, but editing tables, adding rows and columns, swapping images, resizing images, changing spacing between elements, inserting boxes, adding background colors, etc — all of these things require more effort and a much better understanding of the editing tools in Word. Outlook uses essentially the same tools. When errors occur during editing, the layout can break.

So before we get too far with designing a template for our clients, we should gauge their comfort level and ability for doing this kind of rich content editing. Simple is always going to be safer and more successful.

Routing OFT emails

If you work for a digital agency you may be familiar with the way projects get routed through a team for feedback. Routing of an OFT email must be handled differently from how we handle routing for a typical responsive marketing email.

First, once the email is programmed, the person taking screenshots to route should only take a screenshot of desktop. Mobile simply shouldn't be routed, as there's no way to fix any issues that come up for mobile.

This is the big one. I'll make it big:

For desktop, it's important that any screenshots are taken on a Windows machine in the Outlook desktop app — not Mac, not webmail.

The team should not review the email on any other platforms — Mac, mobile, webmail, etc — but if they do, any comments or changes for those platforms should be stet. I can't say this often enough: there is no fix for any issues that occur in OFT emails on on non-Windows, non-Outlook platforms. It's a waste of time to even look at those platforms, let alone mark them up.

Another important one: team members should not forward the email; this may cause formatting errors. If someone receives the OFT as a forward and they notice any issues, there is no fix for them.

Snagit or other screen capture software may not be able to take a scrolling screenshot in Outlook. In that case, my recommendation is simply to take several screenshots to capture the whole email, and route them together with a note explaining why it's broken up.

QA and OFT emails

I recommend only QAing OFT emails in Outlook and on a Windows machine, as this is the only platform that fully supports the OFT format. If the layout and content are correct, and the links work, then it's fine.

I strongly recommend against QAing an OFT in any other platforms. Issues in non-Windows/non-Outlook platforms generally cannot be resolved. Trying to QA for other platforms will be a waste of time and most likely result in failure.

Remember, the simpler the layout, the more likely the email will look fine in all platforms. But it's not something we can guarantee.

Note on attachments

Is it possible to send an OFT with a file attachment (e.g. a pdf)? Yes!

However, we should not have the developer include the attachment when they generate the OFT file. The sender should be required to add it manually before sending.

Let me clarify what I'm talking about here:

Scenario 1. We create the OFT, we deliver it our client, they open it, add an attachment, and send. This is totally fine.

Scenario 2. When we create the OFT, we add the attachment ourselves, before saving it as an OFT. This means the OFT file contains both the email message and the attachment, ready to send. This sounds great! But we should avoid this method.

I used to use this method, but recently I ran into some issues where this makes the OFT not open correctly, especially if the attached file is large. So it's safer to just have the sender add the file manually. (However, that introduces a risk of user error; the sender may forget to attach the file.)

If the sender is adding an attachment, it's important to make sure it's not a very large file. Huge files may be blocked by the recipient's mail server. If they're not blocked, they may take a very long time to download, and the user may cancel the download.

My recommended file size for an attachment in any email is up to 5 mb. Up 10 mb is fairly safe, but 5 mb or smaller is much safer and will usually download pretty fast.

Note: when sending a marketing email to the public, the presence of an attachment can cause it to get flagged as spam. This is why most email deployment vendors simply don't allow attachments at all.

Animated gifs

Animated gifs are supported in OFT emails, with a few big caveats:

Gifs don't play in older versions of Outlook for Windows. When they don't play, they just show the first frame of animation. If the email is internal for your clients, or for HCPs, both of these audiences are very likely to use Outlook for Windows, so the risk that the gif will not play is high.

Animated gifs usually have a very large file size and may cause the email to download very slowly. Not a great user experience, and may result in people bouncing.

For reference: for normal marketing emails (non-OFT emails), the deployment vendor gives us a file size limit of around 150-300 kb — this is to ensure that the email will load quickly. Most animated gifs are many times larger than that.

Manning's soapbox: I recommend simply avoiding animated gifs in email, period. That goes for OFT emails and regular emails.

Mac version?

There is a similar format for Mac called .emltpl, but I don't have much experience with it, so I can't tell you if there are additional watchouts; I bet there are!

Next up: creative specs, dev specs

You still want to make an OFT email? Really? Okay, these articles should help...

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.