Browse the documentation

The open rate looks wrong

An open rate in Issue Mint is the number of people whose copy loaded the tracking pixel, divided by the number of addresses the issue reached. Almost everything odd about the figure comes from one of those two halves, and this page is ordered by which is usually to blame.

Before working through it, the honest framing: an open rate counts images loading rather than people reading, so a figure that looks wrong is often a figure behaving exactly as designed. Open tracking covers what it is worth at all.

What the figure is measured against

The denominator is the delivered count, not the number of subscribers and not the number of recipients.

Delivered means addresses the issue reached as far as anything can tell: recipients handed over and confirmed, plus the ones who arrived and then reported the message as spam, since a complaint proves it got there. Hard bounces are excluded. So the denominator on a send to ten thousand people with four hundred dead addresses is nine thousand six hundred, and a rate worked out against your subscriber count in a spreadsheet will not match the issue report.

Why the figure moved after the send

An open rate rises over the hours after a send, without a single extra person opening anything, because the denominator shrinks as bounce reports arrive.

Bounces do not all come back at once. Some mailboxes reject during the handover and others report an hour later, and each one that lands takes an address out of the delivered count. An issue read at the moment the send finished and again the next morning will show two different open rates for that reason alone. The next morning’s figure is the more accurate one.

Why an open rate reads implausibly high

Apple Mail Privacy Protection loads images on the reader’s behalf, whether or not the reader ever looks at the message, so a share of your opens are Apple’s proxy rather than people.

Nobody outside Apple knows how large that share is. The fetch looks like a reader’s client, which is the design intent, and other prefetching clients do something similar. Gmail’s image proxy is counted as an open too, deliberately: Gmail proxies every image in every message it displays, so treating that as a robot would report almost no opens for the largest part of most lists. On a list of iPhone and Gmail readers, which is most lists, the figure is inflated and there is no honest way to say by how much. Issue Mint makes no attempt to guess, because a confident guess would be worse than an obviously high number.

Why an open rate reads low

A low figure is usually a list whose readers never load the image in the first place, and there are four common reasons.

Images off by default, which several desktop clients and most corporate configurations still do. A reader whose client shows the plain text version, which has nowhere to put a pixel and is therefore never counted. Open tracking switched off for the newsletter, in Settings under Subscribers, which makes the opened stage read zero rather than hiding it. And an issue that mostly landed in spam, where nobody opens anything, which shows up as a normal delivered figure with both opens and clicks collapsed together.

Corporate lists read lower again. Issue Mint discards a pixel fetch from a scanner user agent, and treats a request arriving with no user agent at all as a scanner too, so mail gateways that fetch everything before the recipient sees it are kept out of the figures rather than inflating them. That is the right trade for a click, and it means a list full of business addresses reports fewer opens than a consumer list reading the same issue.

Why your own SMTP server reads lowest of all

On your own SMTP server there are no delivery events, so every address handed over stays counted as delivered, including the ones nothing ever arrived at.

The denominator is therefore larger than the truth, and the open rate is diluted by exactly the addresses that could never have opened anything. Nothing is wrong with the send, and there is no fix inside Issue Mint, because the information does not exist to correct it with. It is one of the quieter costs of choosing your own sending route, and worth knowing before comparing the number with an issue sent any other way.

Which number to read instead

Clicks. A click needs a person, it is filtered for scanner traffic, and it is the one engagement figure a sponsor can check against their own numbers.

Unique clicks over delivered sits directly under the opened stage on every issue report, the hourly curve beside it shows the first 48 hours after the send, and the engagement segments on your subscriber analytics are measured over your last 5 sent issues, counting a first open or any click, so a reader with images blocked still registers as engaged. Click tracking on your own domain is the number to build a rate card on.

Still stuck

Write to us with the newsletter and the issue if the figure looks wrong in a way none of the above explains.

The one thing worth saying in that message is which direction it is wrong in and what you expected, because the checks differ completely. A figure that is too high is nearly always proxies, and a figure that is too low is nearly always the denominator, and knowing which you have saves both of us a day.

Questions

Does my dashboard disagree with the issue report?

No. The opened column on your dashboard, the figure on an issue report and the one in the weekly digest are all the same two counters divided the same way, so they cannot disagree. If two of them differ, one of them was read at an earlier moment, because opens carry on arriving for days.

Does a reader who opens twice count twice?

Not in the issue's figure, which counts people. Their second read adds to their own open count on their subscriber page, so somebody who reads on a phone and again on a laptop is one open on the report and two on their own record.

Last updated 21 August 2026.

Try it on your own list.

14 days, every feature, no card. Sending works from the moment you sign up.

Start your trial