These two features get grouped together in every feature list, and they could not be more different in how much you can rely on them.
Scheduled send is deterministic. The server holds your message and releases it at the time you picked. Close the laptop, lose the connection, go to sleep — a scheduled send still goes out.
Read receipts are a request. You ask the recipient's mail software to tell you when the message was displayed, and it's entirely free to decline, ask its user first, or ignore you. A receipt that never arrives means almost nothing.
Both are useful. They are only useful if you know which one you're holding.
How Scheduled Send Works
To use scheduled send: write the message, open the dropdown next to Send, and pick a time. Presets cover tomorrow morning, tomorrow afternoon, and next Monday morning; the date picker handles everything else. The message moves to a Scheduled folder and sits there until it's due.
The important property of scheduled send is where the message sits. It's stored on the server, and a dispatcher checks every minute for anything due. Your device isn't involved — no browser tab has to stay open, no app has to be running, the machine can be off. That's the difference between server-side scheduled send and the client-side kind some desktop clients offer, where "scheduled" means "your computer will send it if it happens to be awake".
Until it fires, a scheduled send is fully editable. Open the Scheduled folder to cancel it, change the time, or edit the content. Cancelling returns it to Drafts rather than deleting it.
One restriction worth knowing up front: scheduled send isn't available when you're acting as a shared mailbox. A message queued hours in advance from a team inbox has no clear owner at send time — the person who wrote it may have left the team, and no one else can see it waiting. Sending immediately from a shared address is unaffected.
Undo Send Is Not Scheduled Send
Undo send and scheduled send get confused constantly, and they solve different problems. Undo send catches a mistake in the five seconds after you click; scheduled send picks a delivery time that may be weeks away.
Undo send adds a five-second hold to every message. Click Send, the message is queued rather than transmitted, and a countdown appears. Click Undo and it comes back to the composer, fully editable. Let it run out and it goes.
Five seconds is the deliberate choice. It's long enough to catch the two mistakes that actually happen — the missing attachment and the wrong recipient, both of which you notice within about two seconds of the window closing — and short enough that the message still feels sent.
Longer undo windows sound better and are worse. A thirty-second window means every message sits in limbo for half a minute, so you can't answer "did it go out?" without checking, and your Sent folder lags behind reality.
| Undo send | Scheduled send | |
|---|---|---|
| Purpose | Catching a mistake | Choosing a delivery time |
| Duration | 5 seconds | Minutes to months |
| Applies to | Every message | Only messages you schedule |
| Editable while waiting | Recalled to the composer | Yes, in the Scheduled folder |
Time Zones, Where Scheduled Send Goes Wrong
"Tomorrow at 9am" is ambiguous the moment two people are in different places, and scheduled send is where that ambiguity turns into a message arriving at 3am.
The times you pick are in your time zone, taken from your browser. If you schedule from a laptop in Berlin for a colleague in San Francisco, 9am means 9am in Berlin — midnight for them.
The same class of problem used to affect calendars far more seriously, which is why calendar events now store an explicit time zone per event rather than a floating wall-clock time. A meeting created in Berlin and opened in San Francisco shows the correct local hour on both screens instead of the same digits in the wrong place.
For scheduling a message, the practical habit is to think in the recipient's morning rather than yours, and to be careful the week clocks change — a message scheduled three weeks out across a daylight-saving boundary will land an hour off from the wall-clock time you had in mind.
Read Receipts: What an MDN Is
A read receipt in email is a Message Disposition Notification, standardised in RFC 8098. It works like this:
- You send a message carrying a
Disposition-Notification-Toheader with your address in it. - The recipient's mail software sees it. What happens next is entirely up to that software.
- If it decides to comply, it sends you a small structured message back — a machine-readable note saying this message was displayed, at this time, by this user.
- That note arrives in your inbox like any other message, and is matched to the original by its
Original-Message-ID.
On our side, requesting a receipt records one pending entry per recipient at send time. When an MDN lands, it's matched and the corresponding entry is stamped. The Sent list shows an indicator, and opening the message shows a per-recipient report: who has confirmed, who hasn't.
Recipients on Bcc are deliberately excluded from the report. A receipt from a hidden recipient, displayed in the sender's own report, would reveal that the Bcc existed to anyone looking over your shoulder — and a feature that quietly undermines Bcc is a bug.
You can turn receipts on per message from the composer, or set a per-mailbox default in settings if you genuinely want them on everything. Most people shouldn't.
Why This Is Not a Tracking Pixel
The other way to know whether a message was opened is to embed a 1×1 transparent image hosted on a server you control, and log the request when the recipient's client loads it. This is what most "email tracking" browser extensions and sales tools do.
Three reasons that approach isn't on the table here.
It's covert. The recipient has no indication that anything is being recorded. An MDN request is visible: the recipient's client either tells them or asks them. Consent is built into the mechanism.
It leaks more than open time. An image request carries an IP address and a user agent, which means approximate location and what device someone reads mail on. That's a materially different thing from "the message was displayed", and it's collected without asking.
It barely works anymore. Apple Mail Privacy Protection pre-fetches every image in every message from a proxy, so every message registers as opened, immediately, from a location that isn't the recipient's. Gmail proxies images through its own cache. The signal is now mostly noise.
MDN gives you less data and the data is honest. That's the trade, made on purpose.
What a Missing Receipt Tells You (Almost Nothing)
Here is the part that has to be said plainly: most read receipt requests are never answered, and the reasons have nothing to do with whether the message was read.
| Recipient's setup | Typical behaviour |
|---|---|
| Gmail web, personal account | Doesn't send MDNs. Read receipts are a Workspace administrator feature, off by default. |
| Outlook desktop | Honours the request; the default is to ask the user first, and users usually say no |
| Apple Mail | Doesn't send MDNs without configuration most people have never done |
| Thunderbird | Supports it, prompts by default |
| Most mobile mail apps | Ignore the header entirely |
So a silent report is consistent with: not read yet, read on a phone, read in Gmail, read in Outlook by someone who clicked No, or read and deliberately not acknowledged. You can't distinguish these.
The correct reading is asymmetric. A receipt that arrives is solid evidence the message was displayed. A receipt that doesn't arrive is evidence of nothing at all. Treat the first as a signal and the second as silence.
If what you actually need is proof of delivery rather than proof of reading, that's a different and much more reliable question — the outbound log records what the receiving server said when it accepted the message, including its SMTP response, and a rising bounce rate is the signal worth watching. Delivery is a fact your infrastructure observes. Reading is a courtesy the recipient extends.Reading the Report
The Sent list marks messages sent with a receipt requested. Open one and the report lists each To and Cc recipient with either a confirmation time or nothing.
Use it as a prompt, not as a verdict. "Three of five confirmed, and the two who didn't are the ones I need an answer from" is a reasonable basis for a follow-up. "You read my email at 14:32 and didn't reply" isn't a sentence to build on, and saying it out loud makes people uncomfortable for good reason.
When Each One Is the Right Tool
Use scheduled send when you write outside working hours and don't want to look like you work at 1am; the recipient is in another time zone and you want their morning; something must go out on a specific date — a renewal notice, a contract deadline; or you want to think about it once more before it leaves.
Request a receipt when the message genuinely matters and a confirmation would change what you do next, and you've accepted in advance that no answer isn't an answer. Turning receipts on by default is a good way to annoy people who get prompted every time, and it degrades the signal for the messages where it mattered.
Frequently Asked Questions
Does scheduled send work if my computer is off?
Yes. The message is held on the server and a dispatcher checks every minute for anything due. No device of yours needs to be awake or online.
Can I edit a scheduled send before it goes out?
Yes. Open the Scheduled folder to change the content, change the time, or cancel it. Cancelling returns it to Drafts.
Why is scheduled send unavailable from a shared mailbox?
A message queued hours ahead from a team inbox has no clear owner when it fires and is invisible to other members while it waits. Sending immediately from a shared address works normally.
Do read receipts work with Gmail?
Rarely. Personal Gmail accounts don't send MDNs at all. In Google Workspace, receipts are an administrator-controlled setting that's off by default. Assume no receipt from a Gmail recipient.
Can the recipient tell I asked for a receipt?
Yes, and that's intentional. Their client either notifies them or prompts them for permission. It's a request, not surveillance.
Is a read receipt proof the message was delivered?
A receipt that arrives proves delivery and display. Its absence proves nothing. For delivery specifically, look at the sending log, which records the receiving server's SMTP response.
Do you use tracking pixels?
No. Receipts use the standard MDN mechanism, which the recipient's software can decline. There's no embedded image, no open-tracking beacon, and no IP or user-agent logging on the recipient side.
Will a receipt tell me if the message was forwarded?
No. MDN reports a disposition for the original recipient only. Forwarding is invisible to it.
