Moving off NiftyImages, Movable Ink or Liveclicker without breaking mail already sent

A dynamic image vendor keeps serving the mail you have already sent. The image address inside a message delivered eighteen months ago still points at that vendor’s hostname, and it is fetched again every time somebody scrolls back and reopens the message. So a migration is two jobs, not one: moving new sends, and deciding what happens to the old ones.

The second job is the one that gets skipped. Search for how to switch dynamic image vendors and you will find partner integration docs, alternative listicles, and general advice that migration is straightforward as long as the new vendor supports merge tags and external image addresses. That advice is about the next campaign. Nobody writes down what the archive does, which is why this page exists and why it sits under choosing a vendor for an enterprise email programme.

What follows is written for the person who has to answer that question in a renewal meeting, including the parts of the answer that are awkward for us.

The mechanic, stated plainly

An email is HTML, and the HTML is the copy that sits in the recipient’s mailbox. When a vendor gives you a “dynamic image”, what you paste is an ordinary <img src> pointing at a hostname they own. Nothing about that address changes after the send. Nothing can, because the message is already gone.

When the request goes out, and what it produces, differs by client.

Gmail routes the request through Google’s proxy. Google’s Workspace documentation describes it in one line: “When your users open email messages, Gmail uses Google’s secure proxy servers to serve images that might be included in these messages.” The fetch happens at open. Google publishes no cache lifetime and offers no purge endpoint, so how long a copy is reused is not something either vendor controls. What the Gmail proxy does to a timer goes through the observed behaviour.

Apple Mail with Mail Privacy Protection fetches at delivery rather than at read, so the request often reaches the vendor before the recipient has seen the message at all. That is covered on the Apple Mail page.

Outlook for Windows requests the image and then draws only the first frame of an animation, which Microsoft documents. The request still goes out. A vendor switch that kills the hostname turns that first frame into a broken image icon in a corporate inbox.

The volume is the part that surprises people. A three year old programme with monthly newsletters has hundreds of image addresses pointing at one vendor, spread across every mailbox that ever received one. None of them can be edited or recalled.

What the incumbent’s documentation says happens when you stop paying

Only one of the three vendors names the behaviour, and the answer is worth reading twice.

NiftyImages’ own FAQ says that if you stop paying or go over your impression allowance, “All of your images will default to a 1×1 pixel.” That is not a graceful degradation. A 1x1 transparent pixel in place of a 600 pixel banner collapses the layout of every message that carried one, in every inbox, going back to the first send. Their Critical Messages feature is the same mechanism pointed the other way: because the image is resolved at open, the vendor can change what an already delivered message shows. Useful when you own the account. The same lever exists when you do not.

Movable Ink and Liveclicker publish nothing comparable that we could find on 23 September 2026. Movable Ink’s own migration post on its blog, the one about ESP migration and IP warming, is about moving between email service providers and keeping personalization running through the move. It says nothing about mail already delivered, and neither does Liveclicker’s public documentation. For those two the answer is whatever your contract says, and if your contract does not say, you do not have one.

Ask for it in writing before you give notice. The question to send is narrow enough that a support desk can answer it: on the day our subscription ends, what does a request to an image address from a campaign sent last year return, and for how long.

The bottom two rows are the ones that reach a customer service queue.

The order of operations

Five steps, in this order. The order is the whole point: every expensive mistake in this category comes from doing step four before step three.

1. Count what is already out there. Pull the sends of the last 24 months and count the campaigns carrying a vendor image address, the recipients they reached, and the oldest one still getting opens. The number that matters is that last one, because it is what the wind-down question is really about. Pay particular attention to the evergreen flows, the welcome series and the renewal reminders and the abandoned cart mail: they are automated, they are still sending today, and they are the ones nobody remembers to audit.

2. Get the wind-down behaviour in writing, with a date. A vendor that answers “the images keep serving” without a period attached has told you nothing, because the period is the thing you are buying.

3. Overlap the contracts. Run both vendors at once for at least one full cycle of your longest automated journey. If your renewal series runs for 90 days, the overlap is 90 days. This costs one extra invoice and it is the cheapest insurance in the migration.

4. Cut new sends over, and leave the old mail alone. Change the templates, the content blocks and the journey steps so that everything sent from the cutover date carries the new addresses. Touch nothing that has already been delivered. There is no edit to make there anyway.

5. Decide the end date for the old hostname deliberately. This is a decision, not an expiry. Somebody should choose it, write it down, and tell customer service the week before, so that the first “your email looks broken” ticket is expected rather than investigated.

What a delivered EmailTimer.App address does

Everything below is how this product behaves, verified against its own code rather than described from a data sheet.

The signature covers the path and the query, not the host. Every image address is signed with an HMAC over the pathname plus the canonicalised query string. The hostname is not part of the message that gets signed, and the render service never reads the Host header. Swapping img.emailtimer.app for a hostname of your own does not invalidate anything.

Every address pins the version it was sent with. The address carries a v= parameter naming the published version, and that parameter is inside the signature, so it cannot be rewritten by a recipient. A later publish creates a new version and leaves the delivered one alone. The API refuses to delete a template that has published versions, with a 409 and the message “Published versions are never deleted, so archive it instead”. Archiving hides a template from the dashboard and keeps serving the mail that quotes it.

Signing keys rotate without breaking the archive. When a workspace rotates its key, the displaced key stays active and keeps verifying addresses already sitting in inboxes. There is a separate, deliberate action that revokes retired keys, and that one is the “stop every outstanding address now” button.

Nothing returns an error status. An invalid signature, an unknown id, a template that will not load or an exception anywhere in the handler all return the same neutral fallback card at HTTP 200. That is a design rule rather than a happy accident: these responses go to a message that has already been delivered and cannot be recalled. Fallback images covers the one you can set yourself.

Going over the plan does not blank anything. Past 110 percent of a period’s opens, new renders carry a small line of grey text in the corner, and the countdown, the animation and the personalization are unchanged. Details are on what happens when a workspace goes over its plan, and how opens are counted defines what one open is. Compare that with the 1x1 pixel above, because it is the single clearest difference between the two products at the moment a bill goes unpaid.

Where this product is no better

If a subscription lapses through the full dunning sequence, the workspace is suspended and its images serve the fallback card instead of the render. That is a plain card, not a collapsed pixel, and it returns 200 so the layout holds. It is still not the banner you sent. Leaving us has the same shape as leaving anyone else, and the honest version of the sentence is that the card degrades better, not that nothing happens.

There is no cache purge anywhere in this system. If a wrong deadline is already delivered and already cached, the headers decide when a copy expires and nothing can pull it back sooner. A live countdown is sent with max-age=0, s-maxage=30, so shared caches hold it for half a minute. An expired render is sent with a day for private caches and a week for shared ones.

Erasing a recipient’s data on request stops their personalized values drawing in mail already delivered. That is the correct behaviour and it is still a change to a message somebody already received.

We hold no SOC 2 report and no ISO 27001 certificate, and the security page says so and explains what is done instead. If your review needs an audit report, that is a real reason to stay where you are.

Serving from a hostname you control

The structural answer to all of this is to stop pointing delivered mail at a vendor’s domain. On the Agency plan, listed on pricing, images can be served from a subdomain you own, such as images.yourbrand.com, with a CNAME to us. The address stays the same in every other respect, because the signature does not cover the host. One caveat, current on 23 September 2026: the certificate step of that setup depends on a service this deployment has not switched on yet, so a hostname passes the DNS check and stops short of Active. Nothing should be sent on a custom domain until it reads Active.

Two consequences matter at renewal time. Your delivered mail carries your own name rather than ours, so the next migration is a DNS change rather than an archaeology project. And removal is split into two different actions on purpose: Remove stops the hostname being offered for new links and leaves it serving, so delivered images keep loading, while Stop serving takes the hostname down and makes you type it back to confirm, because every image already sent from it stops loading for ever. The setup steps are on serving timer images from your own domain.

Ask your current vendor whether they will do the same. The answer tells you how the next renewal will go.

Questions and answers

Do images in already sent emails stop working when I cancel a dynamic image vendor?

Usually, yes, at some point. NiftyImages documents that its images default to a 1x1 pixel when payment stops or the impression allowance is passed. Movable Ink and Liveclicker do not publish a wind-down behaviour, so the answer depends on your contract. Every delivered message refetches its image on every open, so whatever the vendor serves after your last invoice is what your archive shows.

How long do I need to keep paying the old vendor?

At least one full cycle of your longest automated journey, counted from the cutover, plus whatever notice period the old contract carries. A renewal series running 90 days means a 90 day overlap. Broadcast campaigns need less; evergreen flows are the ones that keep sending. Both invoices run through that overlap, which is a budget line rather than a rounding error: what dynamic images cost at enterprise volume has the per-open arithmetic for each side of it.

Can I rewrite the image addresses in emails already delivered?

No. The message is a copy in the recipient’s mailbox and nothing in the sending stack can reach it. The only lever is what the hostname in that message returns, which is why who owns the hostname is the decision that matters.

Does moving vendors affect deliverability?

The image host is a different system from the sending domain, so authentication is unaffected. What changes is a new hostname appearing in your HTML, which some corporate gateways treat as an unknown. Send a seed test through the gateways your list actually uses before the cutover.