Key takeaway
Almost no mainstream inbox plays an embedded video, so what ships is a picture of one and a link. That makes video email marketing three decisions rather than one procedure: where the file is hosted, which artifact goes in the message, and where the click lands. Only the artifact is constrained by the inbox, and it's the decision written about most and mattering least. Outlook has blocked video since 2021 and is supported to 2029, so I plan for the still.
What video email marketing actually is.
Video email marketing is the practice of using a video as the payload of a marketing email. That's the flat version, and it's the one every guide opens with. The qualifier is the part that changes the job: in almost every inbox, the message doesn't contain the video at all. It contains a picture of the video and a link to somewhere the video plays.
So the phrase describes something that mostly doesn't happen. What people call a video email is an image, a link, and a landing experience. Once that's clear, most of the advice written about the subject turns out to be advice about images and links, which is a different craft with different failure modes and a much shorter list of options.
It matters because three separate decisions get collapsed into one procedure. You choose where the file is hosted, you choose what artifact goes in the message, and you choose where the click lands. Only the middle one is constrained by the inbox, and it's the one that gets almost all the words on every page written about this. I'd settle the landing experience first, because it's the half a reader actually watches.
Knowing it's a picture and a link doesn't tell you which picture, though. The answer isn't the same in every inbox.
What the inbox does with a video file.
HTML5 gives you a <video> element, and email clients mostly don't run it. The shape of the number is worth stating plainly: roughly a fifth of tracked clients render the element and a further twentieth render it only partially, so a native embed renders in a minority of clients by a wide margin. The total isn't the interesting part. What's interesting is that the four client families fail in four different ways, and one of them fails for a reason that has nothing to do with the reason everybody gives.
| Client | Video support | Reason |
|---|---|---|
| Apple Mail and iOS Mail | Plays it | On iOS it needs the controls attribute and won't autoplay, so a video here is something the reader chooses to start. |
| Gmail | Strips it | Across desktop webmail, iOS, Android, and mobile webmail the element is replaced with <u></u> tags, so whatever you nested inside it is what the reader sees. |
| Outlook.com, and Outlook on iOS and Android | Blocked | A strict Content Security Policy since May 2021, a security decision about loading remote media, not a limitation of an old rendering engine. |
| Classic Outlook for Windows | No support | No support from 2007 onwards. Only Outlook 2003 played it at all, buggily. Outlook for macOS 16.80 will play a video, but only from the right-click menu. |
The usual explanation for Outlook is the Word rendering engine, and the estate is moving off it: classic Outlook is in a staged migration to the new client, and existing installations are supported until at least 2029. The engine changing doesn't rescue video, because what blocks it in Outlook.com is a policy about remote media rather than a renderer. Interactive email doesn't rescue it either: the AMP for Email tag list carries no video, audio, or iframe element.
The three things you can actually put in the message.
Whatever the plan says, one of three artifacts ends up in the HTML, and that's the whole of this decision. The question isn't which one is best, because each of them fails somewhere. It's which failure you'd rather ship. The default worth defending is the still image, because its failure is a broken promise you can fix with a line of copy, and the other two fail in ways you can't.
| Artifact | Renders where | Trade-off |
|---|---|---|
| A still image with a play button | Renders everywhere, weighs nothing, honest about being a link | The play button promises playback the message can't deliver, which is about the promise, not the picture. |
| An animated GIF | Shows motion in nearly every inbox | The heaviest thing most senders will ever put in a message. Classic Outlook 2007 to 2019 shows the first frame and stops there. |
A native <video> element with a fallback | Plays for the Apple readers | Degrades to whatever you nested inside it in most other clients. That's two artifacts rather than one, and both of them have to be right. |
The artifact decides what the reader sees, and none of the three decides whether they can follow it. Captions belong to the video wherever it plays, and the requirement is explicit: prerecorded audio in synchronized media needs captions at Level A. A GIF in the message carries no audio to caption, and it still needs alt text that says what it shows.
Don't attach the file.
An attachment is a copy of the file inside the message, and that's the trouble with it. Gmail caps an attachment on a personal account at 25 MB and leaves work and school accounts to whatever their Workspace administrator has set. Past the cap, Gmail removes the attachment and puts a Google Drive link in the message instead, so a carefully attached video arrives as a link anyway, pointing at a page you didn't choose and can't design.
The cap is the least of it. A bulk send carries the payload once per recipient, so the weight multiplies by the size of the list instead of being paid once, and receiving servers apply their own limits well below Gmail's. A message heavy enough to be interesting is also heavy enough to be treated as suspicious. Attachments are for mail one person wrote to one person, with no exception worth naming.
Three decisions, and only one of them is about video.
The file lives somewhere with a player and a URL. YouTube, Vimeo, Wistia, and your own site are all real answers, and choosing between them isn't really a question about playback. It's about who owns the player, who owns the analytics, and what sits beside the video when the reader arrives. A public host puts your video inside somebody else's interface with somebody else's recommendations next to it. Your own site puts it inside yours and hands you the embedding work in exchange. This gets decided once for a programme rather than once per send.
The artifact is the decision already settled: a still, a GIF, or a native element with a fallback. It's the only one of the three the inbox gets a vote on, and that's the wrong proportion, because it's also the decision with the fewest options and the clearest answer.
The destination is the decision the other two get made around. A click from an email lands somewhere, and the real choice is between the host's page and a page of your own with the video on it. The host's page is one click to the video and one click to somebody else's recommendations. Your page is your context, your next step, and a player you have to embed and maintain. The destination decides what the video is worth, because it decides what can happen after the play, and it's the decision most often made by default, because the builder asked for a URL and the URL to hand was the one on the clipboard.
None of these three decisions makes a bad video worth watching. Correct plumbing doesn't fix a message nobody wanted, and it was never going to.
Producing the artifact, every time.
Five steps, in this order, because each one produces the input the next one needs. The sequence isn't the interesting part. The repetition is: it runs again for every send, and a weekly newsletter with video in it runs the whole thing fifty-two times a year, which is what turns a procedure into a pipeline.
- Publish the video and take its URL, plus the timestamp of the frame worth showing.
- Cut the artifact from that frame: a still, or a short loop under a weight you decide in advance and then stick to.
- Write the alt text before you upload the image, because it's the version of the message a stripped render shows, and it's the one nobody writes.
- Assemble the template: image, alt text, a link to the destination you chose, and a text link underneath for readers whose images never load.
- Send a seed test to one Apple client, one Gmail account, and one Outlook account, and look at what each one renders.
Three of those five steps are file handling and template assembly, and none of them needs a person in a builder clicking an image element. I've watched this run weekly on more than one programme, and what wears people down isn't the video. It's the image, the alt text, the link, and the seed test, every single week.
Nitrosend is MCP-first, so templates, campaigns, contacts, and sends are API endpoints and MCP tools before they're screens. The repeat is instructable rather than manual.
A dashboard-first product can expose an API for these same steps, but the campaign is still assembled in a builder and the API is a second surface beside it, which is why the weekly repeat stays somebody's Tuesday morning.
The video still gets hosted somewhere else, the frame is still yours to pick, and the page the click lands on is still your site. What answers to the agent is the message that carries them. Step 2 is a judgment about which frame and step 5 is a person looking at a screen, and neither should be automated.
The click and the play are two different numbers.
Your sending platform records that a recipient clicked a link. The video host records that a player started and how far it got. Those are two events in two systems, and nothing joins them by default: the click identifies a subscriber, and the play identifies a session. A campaign report showing a healthy click rate and a host dashboard showing thin watch time are both telling the truth about different things, and the gap between them is usually the landing page rather than the video.
The join is a parameter you add to the destination URL and then read on the other side, which is work somebody has to do rather than a setting to switch on. Even done properly, the two numbers answer different questions. The one worth optimising is usually the click, because that's the one your list controls and the one that tells you whether the artifact and the subject line did their job.
The video is the easy part. What makes this expensive is doing the same file handling and template assembly again next week, and the week after that. Nitrosend specialises in email, and it's built so templates, campaigns, and sends answer to an agent command instead of a builder. The free tier is 8,000 emails to start and then 500 a month, with unlimited contacts, full MCP, API, and CLI access, and no credit card.
Sources
- Can I email, HTML video support: the share of tracked clients that render the element, iOS Mail requiring
controlswith no autoplay, Gmail replacing the element with<u></u>tags, and Outlook.com, Outlook for iOS and Outlook for Android blocked by a Content Security Policy since May 2021. - Can I email, GIF image support: near-universal support for the GIF format, and classic Outlook 2007 to 2019 showing the first frame without animating it.
- AMP for Email, supported HTML tags: the specification's allowed-tag list, which carries no video, audio, or iframe element.
- Google, send attachments with Gmail: the 25 MB cap on a personal account, administrator-set limits on work and school accounts, and oversized attachments replaced with a Drive link.
- WCAG 2.2, Captions (Prerecorded): captions for all prerecorded audio in synchronized media, at Level A.
- Microsoft, new Outlook migration stages: the staged move to the new Outlook for Windows, and classic Outlook installations supported until at least 2029.
Common questions
In a small minority of inboxes, yes. Apple Mail and iOS Mail play a <code><video></code> element if you give it a <code>controls</code> attribute. Gmail and Outlook don't: Gmail strips the element, and Outlook.com blocks the remote media behind a security policy. For a campaign going to a real list the practical answer is no, and what you send instead is an image linked to the video.
Put an image in the message, link it to the page where the video is hosted, and add a short text link underneath for readers whose images never load. The image is either a still frame with a play button on it or a short animated GIF cut from the video. Write alt text that says what the video shows, because that's what a stripped render leaves the reader with.
No. A YouTube embed is an iframe, and no mainstream email client runs one. Link a thumbnail image to the YouTube watch page instead, or to a page of your own with the player embedded on it. Choose between those two on the basis of what you want the reader to see beside the video when they arrive.
No. Where the <code><video></code> element renders at all it wants a <code>controls</code> attribute and a deliberate press, and iOS Mail won't start playback on its own. An animated GIF is the closest thing to autoplay that works across inboxes, because it's an image rather than a video and nothing has to run it.
It doesn't arrive as a file. Gmail swaps an oversized attachment for a Google Drive link, so the reader gets a link either way, and it opens a file page rather than anything you designed. There's no next step on it and nothing to style. Since a link is the outcome regardless, pick the link yourself and point it at a page you control.
Nearly. The format itself is supported almost everywhere, and the exception worth planning for is classic Outlook on Windows, which shows the first frame and doesn't animate it. That makes the first frame the one that matters: if it works as a still image with a play button on it, the Outlook readers still see something sensible.
Short enough that the opening seconds carry the point, because that's what the still or the GIF in the message is promising and it's what most viewers give it. The email's job is the click rather than the watch, so pick the frame and the length that make the click worth making, and let the landing page carry anything longer.
Say what the video shows and what happens when the reader clicks, not that it's a thumbnail with a play button on it. Where images are blocked, the alt text is the entire message, so "video" or an empty attribute leaves a blank rectangle where the point of the send was. It's also the only part of the picture a screen reader has to work with, so it's carrying two jobs at once.