How to Test Your Website Contact Form: An Owner’s Checklist

A success message does not prove the message reached you

A contact form can look correct while a later step fails. A visitor may submit a valid message, the website may save it, and the notification email may still be rejected or misplaced. A useful test follows the enquiry all the way to the place where someone will act on it.

Separate these outcomes: the form accepted the input; the enquiry was saved; the visitor saw an acknowledgement; the owner’s notification arrived; and any promised customer confirmation arrived. Record each outcome independently.

Download the contact-form test record (CSV). Use it after a launch, a mail-provider change, a form edit, or an integration update. Tell the inbox owner that you are testing, and label the message clearly so it is not mistaken for a real lead.

Prepare one controlled test message

Use an email address you control and a unique reference such as “Website form test — October 14 — mobile.” Do not use a real customer’s details. Record the page URL, device, browser, time, and expected recipient. If the form connects to a CRM or booking tool, identify the destination record as well.

Before pressing submit, confirm that the form asks for the information needed to handle an enquiry. Extra required fields can make the task harder without helping the person who responds. Check that the privacy explanation and the next step are understandable.

Run the acceptance checklist

Test	Expected result	Evidence to record
Mobile layout	Fields and the submit control are usable without sideways scrolling.	Device and a screenshot of the completed form.
Keyboard navigation	You can reach fields and submit using the keyboard, with visible focus.	Any field or control you cannot reach.
Required field left empty	A specific error explains what needs correction.	The error text and whether entered values remain.
Invalid email format	The form requests a correction before accepting the enquiry.	The validation response.
Valid submission	One enquiry is accepted and saved to the intended destination.	A matching saved record, where your system provides one.
Visitor acknowledgement	The result explains what happened and what comes next.	The acknowledgement text or confirmation page.
Owner notification	The notification reaches the configured inbox with usable enquiry details.	Recipient, received time, and provider delivery event if available.
Customer confirmation	If promised, the confirmation reaches your test address.	Received time and the reply address.
Repeated click	The sending state is clear and does not encourage accidental repeats.	Whether duplicate records or emails were created.

Repeat the valid-submission test on a phone and a desktop browser. Check the spam folder as well as the main inbox, but do not call a spam-folder arrival a complete delivery fix. Keep the result in your test record and investigate why it happened.

Find the step that stopped

• No saved enquiry: check validation, the network request, server errors, and the destination configuration. A developer may need to inspect those boundaries.
• Saved enquiry, no owner email: inspect the configured recipient and the email provider’s accepted, rejected, or delivery events. A saved record and a sent-email request are different pieces of evidence.
• Owner email arrives, no customer confirmation: inspect the confirmation recipient, sender, reply address, and the separate delivery event.
• Email arrives but cannot be acted on: check the subject, required details, reply path, and the person responsible for following up.

Do not repeatedly submit the same message while the state is unclear. First look for the saved record or delivery event; otherwise you can create duplicates and obscure the original failure. On Astra’s contact workflow, an enquiry can be saved before an email step reports a problem. The interface distinguishes that partial success so the visitor does not need to start over blindly.

Check accessibility and sender configuration

Visible labels, understandable instructions, useful validation errors, and a clear completion message help people finish the task. The W3C forms tutorial explains those practices. A quick keyboard check is a useful starting point; it is not a complete accessibility audit.

If Gmail delivery is involved, ask the email provider to check sender authentication and the applicable Gmail sender guidelines. Requirements depend on the sender and sending volume. Changing the button colour will not correct a rejected email or a wrong recipient.

Keep an owner and a next test date

Record who is responsible for the form, where notifications should arrive, and which account has access to delivery logs. Re-test when the form, domain, inbox, or connected service changes. Decide a routine test interval that fits how important enquiries are to your business.

If a step fails, bring the URL and your test record to a website support discussion. That makes the investigation more specific than “the contact form does not work.” Our hosting and maintenance service can be scoped around the systems you actually use.