The most common mistake with form auto-reply emails is treating "enabled" as "delivered."
Those are not the same state.
When a respondent says, "I did not get the confirmation email," the cause might be in the form, the rule, the job queue, the email provider, the recipient mailbox, or the copy itself.
If you start with SPF, DKIM, and DMARC every time, you may waste time.
If you only check that the auto-reply setting is enabled, you may miss the actual failure.
I have been building FORMLOVA, a form operations product where auto-replies, notifications, response status, analytics, and workflows are handled as post-submit operations. One pattern keeps showing up:
Auto-reply debugging is a workflow trace, not a single email setting.
Here is the debugging order I use.
Separate the States First
Before checking settings, split the problem into states.
auto-reply configured
recipient field resolved
send rule matched
email job created
provider accepted the message
provider delivered, bounced, or suppressed it
recipient mailbox placed it somewhere
respondent understood what to do next
These are different facts.
A useful trace might look like this:
type AutoReplyTrace = {
responseId: string;
autoReplyEnabled: boolean;
recipientEmail: string | null;
ruleMatched: boolean;
jobCreatedAt: string | null;
providerMessageId: string | null;
providerStatus: "not_sent" | "accepted" | "delivered" | "bounced" | "suppressed" | "failed";
lastError: string | null;
};
You do not need this exact schema.
The important part is that configuration, send attempt, provider result, and inbox result are not collapsed into one boolean.
1. Check the Recipient Field
Most form auto-replies are sent to an email address submitted by the respondent.
That sounds obvious, but this is where many failures start.
Check:
- Does the form have an email field?
- Is the email field required?
- Does the auto-reply setting point to the same field?
- Did the test submission include a real email address?
- Did the field name or ID change after the template was configured?
- Is the value actually valid enough to send?
This failure often looks like an email-deliverability problem, but it is really a data-mapping problem.
If the template expects email and the form now stores work_email, the provider never gets a valid recipient.
Start there.
2. Check Whether This Response Matched the Send Rule
An enabled auto-reply does not always mean every response should receive an email.
Many workflows have conditions:
- send only for "contact us" submissions
- skip obvious sales pitches
- skip test submissions
- send only after booking approval
- send different templates by inquiry category
- do not send if the email field is empty
This is why I prefer to log both the configuration state and the decision state.
Auto-reply template: enabled
This response: skipped because recipient_email is empty
or:
Auto-reply template: enabled
This response: matched template "Resource request confirmation"
Those two logs are much more useful than a generic "auto-reply enabled" badge.
3. Check Whether a Send Job Was Created
Next, find out whether the system attempted to send.
You are trying to distinguish:
No job was created.
A job was created but failed locally.
A job was sent to the provider.
The provider accepted it but later bounced it.
If there is no job, the problem is probably still in the form workflow: recipient mapping, send rule, trigger, queue, or permission.
If the job exists and failed before reaching the provider, inspect the local error.
If the provider accepted the message, move to provider delivery state.
4. Check the Provider Log
If you use an email provider, the provider log is the next source of truth.
Look for:
- message ID
- accepted or failed state
- bounce
- complaint
- suppression
- invalid recipient
- domain authentication issue
- rate limit or quota issue
For example, Resend exposes email and domain logs, and its domain setup flow verifies DNS records for sending domains. Google Apps Script's MailApp.sendEmail() can send messages from scripts, but you still need to think about quotas, authorization, sender identity, and the recipient mailbox.
Do not treat provider "accepted" as the same thing as "the human saw it."
Accepted usually means the provider accepted responsibility for sending or processing the message. It does not guarantee the respondent read it.
5. Check the Recipient Mailbox Path
If the provider says the message was delivered, the respondent may still not see it.
Ask them to check:
- spam folder
- promotions tab
- updates tab
- inbox filters
- company email gateway
- quarantine system
- typo in the submitted address
For B2B forms, the company gateway can matter more than the personal inbox.
For consumer email, the message may be in a tab rather than spam.
This is also why the thank-you page should set expectations:
We sent a confirmation email.
If you do not see it, check your spam folder and make sure the email address was entered correctly.
That text does not fix deliverability.
It reduces confusion during the debugging window.
6. Check Reply-To and Copy
Sometimes the email arrives, but the operation still fails.
Common example:
If you have questions, reply to this email.
But the email is sent from a no-reply address, or Reply-To is not monitored.
That is not a delivery failure. It is an operations failure.
Check:
- Is
Reply-Toset to an inbox someone reads? - Does the copy say "reply to this email" only when replies actually work?
- If you use no-reply, does the email include another support path?
- Who owns replies to auto-reply emails?
Confirmation emails are not only about sending a message.
They are part of the respondent's next step.
7. Check Domain Authentication
If you send from your own domain, email authentication matters.
At minimum, check:
- SPF
- DKIM
- DMARC
Google Workspace documentation recommends setting up authentication methods such as SPF, DKIM, and DMARC for organizations. Resend's domain documentation also treats SPF/DKIM verification and DMARC as part of domain trust.
This does not mean authentication fixes every inbox-placement problem.
It means that without authentication, you are making mailbox providers more suspicious of your transactional email.
Also check the content:
- Is the subject clear?
- Is the email short and expected?
- Are there too many links?
- Does the sender name match the form or company?
- Is a confirmation email trying to act like a marketing campaign?
A confirmation email should usually be short, specific, and operational.
8. Keep the Debug Output User-Friendly
The internal trace can be technical.
The operator-facing output should be clear.
For example:
Auto-reply is enabled.
This response matched the auto-reply rule.
The email was sent to alex@example.com.
The provider accepted the message.
No bounce has been reported.
Ask the respondent to check spam, tabs, and company quarantine.
or:
Auto-reply is enabled.
This response did not have a recipient email address.
No email job was created.
Check the form's email field and the auto-reply recipient setting.
This is the distinction I care about in FORMLOVA: the product should not only say "enabled." It should help explain what happened after the response arrived.
A Practical Checklist
When a form auto-reply email does not arrive, debug in this order:
1. Recipient email field exists and is required.
2. Auto-reply points to the correct field.
3. This response matched the send rule.
4. A send job was created.
5. The provider accepted or rejected the message.
6. Bounce, complaint, or suppression state is checked.
7. Recipient checked spam, tabs, filters, and quarantine.
8. Reply-To and copy do not create a dead end.
9. SPF, DKIM, and DMARC are configured for custom domains.
10. Test email was checked in a real inbox before launch.
The main idea is simple:
Enabled is configuration. Sent is an event. Delivered is provider state. Seen is human behavior.
Debug those separately.