Best time of day for email marketing, and how to find yours.

Key takeaway

Midweek, mid-morning, in the recipient's local time is the consensus answer, and it's a hypothesis rather than a finding. Almost every chart behind it is built on open rate, and an open is an image fetch a proxy performs with nobody present. Work across 16 billion messages found that the more mail people get in a day, the smaller the share they answer. I treat the default as test one and measure a click instead.

What a best send time actually measures.

The send time is the moment you release a campaign to the queue. Every best-time chart you've ever seen is built from that moment: take a pile of campaigns, bucket them by the hour they were released, average a response metric inside each bucket, and draw the line. That's the whole method, and it's the same method on every page that publishes one.

So the chart is a picture of the sender's clock. What you want to know is when your reader is willing to look at mail, and that's a different variable the chart is standing in for. The gap between the two is narrow on a list of two thousand people in one country, and it widens fast, because an average computed over one population, with its own mailbox-provider mix and its own definition of a response, doesn't transfer to yours.

None of which makes the question silly. "When do I press send" is a reasonable thing to want an answer to, and there's one.

The consensus answer, and what it is worth.

Midweek, mid-morning, in the reader's local time. That default turns up everywhere because it describes an office rhythm rather than an email one: Monday morning goes on the weekend's backlog, Friday afternoon has already left, and the middle of the week at the middle of the morning is when a working inbox gets triaged instead of cleared. Three things fall out of that, and they're worth stating separately because two of them disagree.

1. Best day: Tuesday through Thursday, on more or less every chart anyone publishes.
2. Best hour for opens: roughly 9am to 11am where your reader is, not where you are.
3. Best hour for clicks: later, often well into the evening, which is why a chart of opens and a chart of clicks recommend two different sends.

Take that and treat it as what it is. It's a starting position, worth exactly what a starting position is worth: it saves you the first guess, and it commits you to one test rather than to a schedule.

Open rate is the wrong ruler for this question.

An open is a remote image fetch. Your platform drops a tracked image into the message, and when something requests that image, the platform writes down an open at that timestamp from that IP address. That's the entire mechanism, and every hourly chart in the section above rests on it.

The fetch and the human have come apart. Apple's Mail Privacy Protection hides the recipient's IP address so senders can't determine their location, and it prevents senders from seeing whether a message was opened at all. Two of the chart's axes go at once. What survives on those addresses is a timestamp for a request nobody made deliberately, sitting under a location that belongs to infrastructure rather than to a reader. On a list with a meaningful share of Apple Mail, an hourly open curve is partly a picture of a proxy's day.

So measure something a person had to decide to do.

• Clicks: somebody chose a link, which is a decision rather than a render.
• Replies: rare, the clearest evidence that the send reached a human at all, and the one signal you count in the inbox you reply from rather than in a sending platform.
• Conversions: the thing the campaign was for, and the only number on this list that shows up in revenue.
• Unsubscribes: the cost side of the test, because an hour that lifts clicks and doubles opt-outs isn't a better hour.

That swap costs you resolution. Clicks are much rarer than opens, so a test built on them needs a bigger list or a longer run before a difference between two hours means anything. The constraint shapes the method below, and it's the honest reason most senders never get a clean answer.

Send time is not delivery time.

Pressing send delivers nothing. It starts a queue draining. Your platform offers messages to each mailbox provider at whatever rate that provider is willing to take, some of them get deferred and retried, and the tail of a large campaign lands well behind the head. At five thousand recipients that spread is seconds. At five hundred thousand it isn't.

The receiving side has opinions about the rate, too. Google's sender guidelines ask you to send at a consistent rate and avoid bursts, to start with low volume to engaged users and raise it slowly, and they warn that suddenly doubling your previous volume can get you rate limited or cost you reputation. Dropping an entire list into one golden hour is a burst by design, so the timing advice and the delivery guidance are pulling against each other.

I have watched teams solve the wrong half of this. They tune the send hour to fifteen-minute precision, release the whole list at once, then spend the afternoon watching deferrals climb at one provider and wondering what happened to the subject line. The hour was never the variable under test. The shape of the volume was.

Below the point where a provider starts pacing you, none of this bites. A few thousand recipients land inside a couple of minutes, the send hour really is the delivery hour, and you can tune it freely. The tension only appears as the list grows, and when it does it appears as a deliverability problem rather than a timing one, which is why it gets diagnosed late.

What send time optimisation actually does.

Send time optimisation is a per-contact scheduler. Rather than one release time for everybody, the platform holds an optimal hour for each contact, derived from that contact's own engagement history, and releases each message when that contact's hour comes round.

Oracle's Responsys documentation spells the mechanism out. When a contact reaches the send time stage, the system looks up the earliest optimal time between arrival and the next 24 hours, a window that documentation calls the send period, and a contact whose optimal times fall outside that window, or who has none recorded, is routed down a "Without STO Data" path instead. Names vary across vendors. The shape doesn't.

Which tells you what one of these needs before it can help you.

• Engagement history: per contact rather than per segment, and recent enough to describe how that person behaves now.
• A bounded window: the hours the scheduler may move a send inside, so a campaign with a deadline still arrives before it.
• A fallback path: a defined answer for everybody the system knows nothing about.

My take is that it's a useful scheduler fed by a noisy signal, and the signal is mostly the open data the previous section just disqualified. The weak spot is that fallback path. New contacts, quiet contacts, and anyone reading through a mail proxy all live there, which on plenty of lists is a large minority taking the default send anyway. It also can't rescue a campaign nobody wanted, at any hour. I built something in that shape once: a machine-learning personalization system at Bluethumb that improved engagement and accounted for more than 10% of revenue off that one feature. It still needed the same fallback path for anyone the model had nothing on.

A static schedule relies on old assumptions. We built our platform to adjust to your buyers. The system works, as I put it on Developer Podcast, because "it can actually improve its recommendations over time, because we measure revenue per email, per store." You stop guessing when the software tracks actual sales.

The test that answers this for your list.

The only send time worth having is the one your own list voted for, and getting it takes five steps and a couple of months of ordinary sending. None of the steps are hard. The discipline is in holding everything else still while the clock moves.

1. Pick one variable. Same segment, same subject line, same content, same offer, two send hours. Anything else you change buys a result you can't attribute.
2. Split by contact, at random. Not by list, not by signup date, not by the first half of the alphabet. A split that tracks tenure or geography measures tenure or geography.
3. Measure a click, a reply, or a conversion, and record unsubscribes beside it. Opens belong in the notes, not in the verdict.
4. Repeat it across several sends. One campaign is an anecdote, and a point or two of difference on a single send is noise wearing a result's clothes.
5. Re-run it when the list changes shape. A big intake, a new market, or a new offer means your answer describes a list you no longer have.

On a small list a two-hour shift is undetectable, and running the test for longer won't change that. That's a real answer rather than a failure. Spend the time on the offer and the segment, and come back to timing when the volume can carry it.

Inbox volume beats the clock.

The lever competing with your send hour is how much mail your reader already has. Not yours: everybody's. Attention on a Tuesday morning is divided by the size of the pile in front of somebody, and that pile is what your campaign is really up against.

A study of over 2 million users and 16 billion messages found that as people receive more mail in a day they reply to a smaller fraction of it and write shorter replies, while their responsiveness itself holds up. Load doesn't slow people down. It makes them selective.

Set that beside the consensus answer and the trap is easy to see. The golden hour is the most crowded hour by construction, because every sender read the same charts and moved into it. Competing there is a choice, and so is declining to, which is what the following-the-sun and off-peak tactics amount to once you take the packaging off.

Off-peak isn't a strategy either, though. It's the second hypothesis, and it earns the same test as the first on the same metrics over the same several sends. The claim isn't that 6am on a Sunday is better. It's that the crowding of an hour is a variable you can test, and few senders ever do.

Make the test cheap enough to repeat.

Here's why most senders never run the test above, and it isn't analytical. Building the split, cloning the campaign, scheduling two cells, waiting a week, and reading the result back out of a reporting screen is an afternoon of clicking, and it's another afternoon next quarter, and another one after that. So it gets done once, if at all, and the answer gets treated as permanent long after the list it described has turned over. That afternoon isn't a discipline problem. It's what a product designed around a screen costs you every time you want to ask it something, and an agent bolted onto that screen still has to click through it.

A send time answer you can't cheaply re-run is an answer about a list that no longer exists. That's the operational half of this question, and it's the half we built for. Nitrosend is MCP-first: every capability is an API endpoint and an MCP tool before it's a screen. Segments, campaigns, and flows are addressable, so setting the test up is a command rather than an afternoon, and running it again in October is that command with a different date on it. Contacts are unlimited on every plan, including Free, so splitting a list into test cells never shows up on the bill.

You can't answer a timing question once and then keep the answer. If you'd rather stop re-asking it by hand, the free tier is enough to run it: 8,000 emails to start, then 500 a month, unlimited contacts, and full MCP, API, and CLI access with no credit card. Build the split, send both cells, and let your own list settle the argument instead of somebody else's chart.

Go deeper

Sources

• Apple, Use Mail Privacy Protection: hiding the recipient's IP address so senders can't determine their location, and preventing senders from seeing whether a message was opened.
• Google, Email sender guidelines: sending at a consistent rate rather than in bursts, starting at low volume to engaged users, and the reputation cost of suddenly doubling volume.
• Oracle, How Send Time Optimization works: the 24-hour send period, the per-contact lookup for an optimal time inside it, and the "Without STO Data" fallback path.
• Kooti et al., Email Overload, WWW 2015: over 2 million users and 16 billion emails, and how reply rates and reply length fall as daily volume received rises.

Common questions