A message arrives at 9:15 with three attachments and the line "please confirm receipt of this email" at the bottom. The actual work it describes will take a fortnight. The confirmation will take eleven seconds, and sending it now is almost always the right move, because the eleven seconds buy the fortnight.
That trade is the whole point of an acknowledgement, and it is the part most template lists skip. A confirmation of receipt is not a reply. It is a statement that the message has landed with a specific person, so that the sender can stop wondering and stop chasing. Get the wording wrong and it becomes a promise about the work itself, which is a debt rather than a breathing space.
What "please confirm receipt" is actually asking for
The phrase covers three different requests, and the right reply depends on which one is in play.
Proof that the message arrived. The sender is worried about delivery. They have sent something to a shared mailbox, or through a form, or to an address they are not sure of, and they want to know it did not vanish. Any reply at all satisfies this.
Proof that a human has read it. The sender is worried about the mailbox, not the network. Mail sent to info@ or support@ frequently sits unread, and a sender who has been burned by that before asks for confirmation as insurance. Here the reply needs to show comprehension, not just arrival. Naming what was received is what does that.
Proof that somebody now owns it. This is the version that appears on contracts, invoices, safety reports and legal correspondence. The sender wants a named person on the record who has accepted the item. A generic automatic receipt does not satisfy it, and pretending otherwise causes arguments later.
Reading which of the three is being asked takes a second and saves a round trip. A supplier confirming an invoice arrived wants the second or third. A candidate asking whether an application was received wants the first.
Read receipts and delivery reports answer a different question
Requesting a read receipt looks like the efficient path and generally is not, for reasons worth knowing before relying on one.
A delivery status notification, produced by the receiving mail server, says only that a message reached a mailbox. It says nothing about whether a person opened it, and it is generated by machines that do not care who is on holiday. A read receipt goes further and reports that the message was opened, but only if the recipient's client supports it and the recipient agrees to send it. Many clients prompt the user, and many users decline. Gmail's read receipt feature is limited to Workspace accounts and is controlled by the administrator, so a request sent to a personal address may simply be ignored with no indication that it was.
Open tracking, the pixel based method used by marketing and sales tools, has the opposite problem. It reports opens without asking, which is why image loading is blocked by default in many clients and why privacy proxies now pre load images and produce phantom opens. The signal exists but is noisy.
None of the three tells the sender that anyone has taken responsibility. That is the thing a two line human reply does that no automatic mechanism can, and it is why the phrase persists despite decades of technical alternatives.
What belongs in a confirmation, and what it commits you to
The difference between a confirmation that helps and one that creates a problem is usually a single clause.
| Reply | What it tells the sender | What it commits to | Use when |
|---|---|---|---|
| "Received, thank you." | The message arrived and a person saw it | Nothing | The sender only needs delivery comfort |
| Received, with what was received named | Somebody read it and understood the contents | Nothing, but implies attention | Documents, invoices, anything with attachments |
| Received, with a date for the substantive reply | It landed and when to expect an answer | That date | The work will take time and the sender needs to plan |
| Received, with the next step and the owner named | It landed, who has it, what happens next | The process, not the outcome | Applications, claims, formal processes |
| Received, plus an answer | Everything | The answer given | The reply genuinely takes under two minutes |
The rows in the middle are where most of the value sits. Naming a date for the real reply is the single most useful thing a confirmation can contain, because it removes the sender's reason to follow up, and a follow up costs both sides more than the sentence did.
The trap is the vague version of the same thing. "Will come back to you shortly" and "will look into this as soon as possible" are worse than saying nothing about timing, because they set an expectation without defining it, and the sender's definition of shortly will not match yours. If a date cannot be promised, say when a date will be known. "A timeline should be clear by Thursday" is honest and still actionable.
Replies worth keeping
A bare acknowledgement, where nothing more is needed:
Subject: (reply in the existing thread)
Received, thank you. Nothing further needed at this stage.
An acknowledgement that names the contents, for documents:
Subject: (reply in the existing thread)
Confirming receipt of the signed agreement and the two schedules,
received this morning. These have been filed against the March
contract record.
No action is needed from your side.
An acknowledgement that buys time:
Subject: (reply in the existing thread)
Confirming this arrived and has been read. The detail in the second
section needs a review with the finance team, who meet on Tuesday.
A full reply will follow by Wednesday 8 October. If anything changes
before then, a reply to this message reaches the right person.
An acknowledgement for a formal process, naming the owner:
Subject: Claim reference 20261487, received
The claim submitted on 26 September has been received and assigned
to the assessments team.
What happens next: an assessor reviews the documents provided and
requests anything missing. Expect either a request or a decision
within ten working days. This reference number reaches the file if
anything needs to be added in the meantime.
An acknowledgement where the answer is going to be no:
Subject: (reply in the existing thread)
Received, thank you for sending it through.
This falls outside what this team handles. The right route is the
procurement address on the contact page, and the message has been
forwarded there so nothing needs to be resent.
That last one matters more than it looks. Confirming receipt and then doing nothing because the item was not yours is how things disappear. Confirming, redirecting and saying where it went costs one extra sentence.
Asking someone else to confirm, without the edge
"Please confirm receipt" reads as slightly cold in some contexts and slightly legalistic in others, which is why it appears so often in complaints about email tone. The phrase is not the problem. The absence of a reason is.
Attaching a reason converts it from a demand into a courtesy. "Please confirm receipt so the file can be closed" and "a quick confirmation would help, since the last submission did not arrive" both give the recipient a purpose for the eleven seconds. Adding a time frame does the same work: "a line by Friday confirming this arrived would be appreciated" is easier to comply with than an open request, because it can be scheduled.
Softer alternatives carry different amounts of force, and choosing among them deliberately is better than defaulting to the softest. "Let me know this reached you" is casual and appropriate between colleagues. "Please acknowledge receipt" is firmer and normal in formal correspondence. "Please confirm receipt and that the terms are agreed" is two requests in one sentence and should be split, because a recipient who is comfortable with the first and not the second will answer neither.
Where the stakes are genuinely high, the honest approach is to say so rather than to lean harder on the phrasing. A sentence explaining that the confirmation is needed for a filing deadline or an audit record gets a faster response than any amount of formality.
How fast, and who from
Speed is most of the value. A confirmation sent within a few hours does the job it was asked to do. The same words sent on day four arrive after the sender has already chased, so both messages were wasted and the chase has been rewarded.
Same working day is the standard worth holding for anything that names a deadline, arrives with documents, or comes from outside the organisation. Within the hour is worth the effort for anything time critical, and there is no harm in a confirmation that is faster than the sender expected. Overnight is acceptable for internal traffic and for messages that arrive after hours, provided the acknowledgement then goes out first thing rather than after the day's meetings.
Who it comes from matters almost as much. A confirmation from a shared mailbox signed by nobody satisfies the delivery question and leaves the ownership question open, which is why senders so often reply to a generic receipt asking who is dealing with it. Signing with a name, even without a job title, closes that loop in four words. Where the person confirming is not the person who will handle it, saying so avoids a worse outcome: the sender addressing all subsequent correspondence to whoever answered first.
Shared mailboxes introduce one more failure that is easy to miss. Two people can both confirm receipt of the same message within minutes of each other, and the sender then has two contradictory statements about who owns the item. The usual patch is a rule that only one named person answers a given queue each day, which works until that person is away. Attaching the acknowledgement to a record that shows whether it has already been sent removes the duplication without depending on anybody remembering the rota.
When the confirmation should not be typed at all
Every acknowledgement discussed so far is a human decision about a single message. At volume that model breaks, and the failure is predictable.
A team taking in forty submissions a week through a form cannot acknowledge them by hand, so the acknowledgements stop, so the senders write to ask whether anything arrived, so the inbox fills with follow ups that would not exist if the first message had been confirmed. The cost of not acknowledging is paid in the same inbox that was being protected.
The fix is to separate the two jobs. The arrival confirmation is mechanical and should be automatic: sent the instant a form is submitted, containing a copy of what the person wrote, a reference, and what happens next with a date. That covers the first of the three requests above completely, and it covers the second well enough for most situations, because a copy of their own answers proves the submission was captured rather than merely delivered. Form tools that handle the reply side send this as standard and let the wording be edited, which matters, because a receipt that says only "thank you for your submission" leaves the sender exactly as uninformed as silence would.
What cannot be automated is the third request, the named owner accepting the item. That still needs a person, and the practical approach is to make it cheap: a saved template with the reference and the name dropped in, sent from the record itself so the send is logged where the next person will look. When an acknowledgement is one click from the response it belongs to, it gets sent. When it requires switching to a mail client, finding the address and retyping the reference, it does not.
One detail worth checking on any automatic receipt is the address it comes from. A receipt sent from a no reply address tells the recipient their confirmation cannot be answered, which defeats a good part of the purpose. A reply that reaches a monitored mailbox, ideally the one where the response record lives, turns the acknowledgement into the start of a usable thread.
What to change first
Add the date. Go through the last few acknowledgements sent by hand and check whether any of them said when the real reply would arrive. Replacing "as soon as possible" with an actual day removes most of the follow up traffic those threads will otherwise generate.
Then make the automatic receipt say something. A confirmation that repeats what was submitted, gives a reference and names a date does the work of three emails, and setting the wording once covers every submission after it. The Halict questions page covers what a receipt of that kind can include.
Q1. How do you reply to an email that says "please confirm receipt"?
Reply in the same thread with one or two sentences stating that the message arrived, naming what was received if there were attachments, and giving a date for the substantive reply if one is needed. "Received, thank you. The signed schedules are filed and a full response will follow by Wednesday" satisfies every version of the request and commits to nothing beyond the date.
Q2. Is there a difference between acknowledging receipt and confirming receipt?
In everyday business use the two are interchangeable, and no recipient will read a distinction into them. Where a difference is drawn, confirming tends to imply a check that the contents are correct and complete, while acknowledging implies only that the item arrived. If the contents have not been checked yet, say so plainly rather than relying on which verb was chosen.
Q3. Can a read receipt replace a confirmation email?
No, because it answers a different question. A read receipt reports that a message was opened, depends on the recipient's client supporting it, and in Gmail is limited to Workspace accounts under administrator control. None of that tells the sender who now has the item or what will happen to it, which is usually what they are actually asking for.
Q4. Should every email be acknowledged?
No. Acknowledge anything with attachments, anything tied to a deadline or a process, anything from someone who has no other way to know it arrived, and anything where the real reply will take more than a day. Skip it for messages inside an active back and forth, for internal notes that need no action, and where a one word reply would add a message to a thread without adding information.
Q5. What should an automatic receipt for a web form contain?
A copy of what the person submitted, a reference they can quote, what happens next, and a date or range for when to expect news. It should come from an address that accepts replies. A receipt that says only "thank you for your submission" leaves the sender with the same uncertainty as no receipt at all, and they will write again to resolve it.