Yes, with two conditions attached, and the conditions are the reason the feature disappoints people who switch it on expecting an acknowledgement email. Google Forms can send the person who filled out the form a copy of their own answers. It cannot, on its own, send them a message you wrote.
Those are different products, and the distance between them explains most of the frustration in this area. Someone turns on the setting, submits a test, receives a plain list of their own answers back, and realises that what they actually needed was a short note saying the application arrived and somebody will reply within two working days.
The two emails Google Forms can send
There are two separate mechanisms, controlled in two different places, and they are easy to mix up because both get called a confirmation email in conversation.
The receipt that goes to the responder
This one requires email collection to be on first. In Settings, under Responses, set Collect email addresses to either Verified or Responder input. Verified takes the address from the signed in Google Account, and Google notes that responders have to confirm their Google Account email address gets collected with their response, with the confirmation shown on each page of the form. Responder input asks the person to type an address into a field.
With that in place, the same Responses panel offers Send responders a copy of their response, with two choices: When requested or Always. When requested puts a checkbox on the form and leaves the decision to the responder. Always sends the receipt on every submission.
The notification that goes to you
Open the form, click Responses, open the three dot menu, and click Get email notifications for new responses. This sends an alert to the form owner when a submission arrives. It is unrelated to the responder receipt and has its own switch.
Both are useful. Neither writes a message to the person who submitted.
What the built-in receipt is, precisely
It is a copy of the answers that were just submitted, sent to the address collected on the form. That framing matters, because it determines what you can and cannot do with it.
What it is good for: giving the responder a record of what they wrote. For a long application, an expense claim, or a registration with a lot of fields, that record is genuinely valuable, and it reduces the number of people who write in later asking what they put down.
What it is not: a channel you control. The receipt is a system message about a submission, not correspondence from your organisation. If the requirement is a branded acknowledgement, a message that varies by what the person selected, an attached PDF, or a reply that arrives from an address someone can write back to, the built-in receipt is not the mechanism, and no amount of configuration will turn it into one.
Google's own documentation points elsewhere for that. The tip attached to the notification setting says that to get more notification options and send customised follow up emails to respondents, you download the Form notifications add-on. That is an honest signal about where the built-in feature stops.
The confirmation message is a third thing
Under Settings, next to Presentation, there is a Confirmation message that can be edited. This is the text shown on screen after someone presses submit. It is not emailed anywhere. A surprising number of teams have written a careful acknowledgement into this box and assumed it was going out by mail. It has been sitting on a page that responders see for four seconds.
Why the receipt did not arrive
The complaints about this feature cluster into a handful of causes, and they can be worked through in order.
Email collection is off. The receipt setting depends on it. With collection off, there is no address to send to and the option has nothing to work with.
When requested is selected and nobody requested it. This is the most common one. With When requested, a checkbox appears on the form and the receipt is sent only to people who tick it, which in practice is a minority. If the receipt should go to everyone, the setting has to be Always.
The address was typed wrong. In Responder input mode the address is whatever the person entered, unverified. A missing letter in a domain produces a silent failure on your side. Verified mode removes this class of problem entirely, at the cost of requiring a Google Account.
Spam filters. Google states directly that in certain circumstances responders may not receive expected response receipts due to spam filters or other counter abuse measures. A receipt that lands in a junk folder is indistinguishable, from your side, from one that was never sent. Check a spam folder before concluding the feature is broken.
The test was run as the form owner. Submitting your own form while signed in as the owner produces confusing results and is a poor test. Use a second address on a different mail provider.
The realistic options, compared
| Approach | What the responder gets | Setup | Where it runs out |
|---|---|---|---|
| Built-in response receipt | A copy of their own answers | Two settings, no code | No custom wording, no branding, no attachments |
| Form notifications add-on | A customised follow up email | Install and configure an add-on | Another tool to maintain and re-authorise |
| Apps Script | Anything you can write in code | Development and ongoing upkeep | Somebody has to own the script permanently |
| A form tool with replies built in | A message written by a person or a template | Choosing a different tool | Migrating the forms you already have |
The middle two options are real and plenty of teams run on them. The question to ask before committing is who maintains them. An Apps Script written by a colleague who has since moved teams is a liability discovered on the morning it stops working, usually because an authorisation expired and nobody knew the script existed.
Test what happens when somebody presses reply
Whatever mechanism ends up sending the acknowledgement, one test tells you more than reading any documentation about it. Submit the form from an address outside your organisation, open the message that arrives, and press reply.
Where that reply lands is the whole answer. If it goes to a monitored address, the confirmation has quietly become a working channel and people will use it, which is fine as long as somebody is watching. If it goes somewhere nobody reads, every responder who answers the acknowledgement with a follow up question is sending mail into a void, and they will conclude that nobody is handling their request. That failure is invisible from your side, which is what makes it worth ten minutes of testing.
The same test surfaces two other things. Whether the message landed in the inbox or the junk folder on a mail provider other than Google, which is the practical measure of deliverability rather than a theoretical one. And what the message looks like on a phone, where most responders will read it.
Run the test again whenever the form changes in a way that affects who receives what. Settings get toggled during a busy week and nobody remembers doing it.
The question underneath the question
Most searches for this end up being about something larger than an email. The reason a confirmation is wanted is that the person who submitted has no idea whether anything happened, and the team has no way to show what was done. The receipt is being asked to carry a job it was never designed for: reassurance that the request is in a queue and someone owns it.
Seen that way, the useful test is not whether an email goes out. It is whether the following four things are true one week after a submission arrives.
The responder knows the submission landed. Somebody on the team is identifiably responsible for it. Anyone else on the team can see whether a reply has been sent. And the reply itself is findable, next to the submission it answers, without searching an inbox.
The built-in receipt covers the first point and none of the other three. That is not a criticism of a free feature. It is a description of scope. Forms was built to collect answers, and it collects them well. The work that follows a submission is a separate problem that different tools solve, and it is worth seeing what handling a response through to the reply on one screen looks like before building a script to patch one corner of it.
What a sensible setup looks like without changing tools
If Google Forms is staying, three settings make the experience considerably better than the default.
Set Collect email addresses to Verified where the audience will already be signed in, such as an internal form or a school. Use Responder input for public intake, and add a second question asking for the address again if a wrong address would be expensive.
Set Send responders a copy of their response to Always rather than When requested, unless the answers are sensitive enough that a copy in an inbox is a risk.
Write the on screen Confirmation message as though it is the only acknowledgement the person will read, because for anyone who does not receive or does not open the receipt, it is. State what happens next and how long it takes. Two sentences is enough, and it is the cheapest improvement available here.
There is a fourth adjustment that costs nothing and prevents a recurring argument. Decide, in writing, where a responder is supposed to go if they need to add something after submitting. The receipt will not tell them, and the confirmation message is the only place on the whole journey where you can. Naming a monitored address there turns a dead end into a route, and it stops the pattern where people submit the same form three times because each attempt felt like it vanished.
Turn on Get email notifications for new responses only if one person is genuinely responsible for the form. When three people receive the same alert and none of them can see what the others have done, the notification stops being a prompt to act and becomes background noise, which is worse than no notification at all. Volume decides this: a form receiving two submissions a week is fine on alerts, and one receiving twenty a day is not.
What to change first
Switch the receipt from When requested to Always and rewrite the on screen confirmation message to say what happens next. If what you actually need is a written reply from a real address, with the form response and the reply stored together, that is a tool choice rather than a settings change, and Halict is one place to see the difference.
Q1. Can Google Forms send an automatic confirmation email to respondents?
It can send them a copy of their own answers, which is not the same as a message you wrote. Turn on Collect email addresses in Settings under Responses, then set Send responders a copy of their response to Always. For custom wording, Google's own documentation points to the Form notifications add-on.
Q2. Why are respondents not receiving the copy of their response?
Check four things in order: that email collection is turned on, that the setting is Always rather than When requested, that the address was typed correctly if you are using Responder input, and the recipient's spam folder. Google notes that receipts can be blocked by spam filters and other counter abuse measures.
Q3. Can the confirmation email be customised with your own wording and logo?
Not with the built-in setting, which sends a copy of the submitted answers in a fixed format. Custom wording requires an add-on such as Form notifications, an Apps Script, or a form tool that sends replies as part of its normal operation.
Q4. What is the difference between the confirmation message and the confirmation email?
The confirmation message is text shown on screen immediately after someone presses submit, edited under Settings next to Presentation. It is never emailed. The response receipt is the email, controlled separately under Responses, and it requires email collection to be turned on first.
Q5. How do you get notified yourself when someone fills out the form?
Open the form, click Responses, open the three dot menu, and click Get email notifications for new responses. This alerts the form owner and is independent of anything the responder receives. For a shared address, forwarding rules or a tool with per response assignment will scale better than everyone watching the same alert.