Website Contact Form Stopped Sending Emails? A Small-Business Troubleshooting Checklist

If a website contact form says a message was sent but nobody receives it, do not replace the form immediately. First determine where the message stopped: in the browser, inside the form system, during mail handoff, or at the recipient mailbox.

Use this checklist to isolate the failure without making risky changes to DNS or business email.

Start with one controlled test

Submit the form from an incognito or private browser window. Use a test address that is different from the business recipient address, and record the exact time, page URL and device used.

• Does the form show a success message?
• Does the form platform or website store the submission?
• Does an automatic confirmation reach the test address?
• Does the business mailbox receive the notification?
• Does the message appear in spam, junk or quarantine?
• Does the same result occur on mobile data and the office network?

Test while logged out and, if possible, from a second device. If every form is affected, suspect a shared mail, hosting or configuration problem. If only one form fails, inspect that form's settings and integrations first.

Trace the message in order

1. Check whether the submission was captured

Look in the form dashboard, website database, CRM or other configured storage. A stored submission usually means the visitor reached the form successfully and the problem is further along the delivery path.

If the form displays success but no submission is stored anywhere, treat that as a capture or application problem. A confirmation message alone is not proof that a lead was recorded.

2. Check the notification settings

Confirm the full recipient address, not just the saved display name. Check for a typo, an old employee address, a removed forwarding rule or a notification that points to a mailbox nobody monitors.

Review the sender and reply-to fields as well. The address shown to the recipient should match the sending setup supported by the mail provider; a visitor's address is often better placed in Reply-To than in the technical sender field.

3. Search beyond the inbox

Search for the form subject, sender domain and a distinctive phrase from the test message. Check spam, junk, quarantine, archive folders, inbox rules, forwarding rules and any security gateway used by the business.

Ask the mail administrator whether the message was rejected, delayed, quarantined or accepted and delivered elsewhere. “Not in the inbox” does not identify the failure by itself.

4. Identify the actual sending service

A website may send through its host, a transactional email provider, an SMTP relay or a platform integration. Find out which service generated the message before changing DNS records. The relevant logs and authentication settings belong to that sending service, not automatically to the mailbox provider.

5. Review authentication and alignment

SPF identifies authorised sending sources, DKIM applies a cryptographic signature, and DMARC checks whether authentication aligns with the visible sender domain. Microsoft explains how these standards work together, while Google's current sender guidance notes that authentication, alignment, DNS and TLS problems can contribute to rejection or spam placement. See Microsoft's email-authentication guidance and Google's sender requirements.

Do not copy an SPF record from a generic tutorial or publish multiple SPF records for the same domain. Confirm every service that sends mail for the domain, then make changes carefully and document the previous configuration.

6. Review recent changes and logs

Compare the first failure with recent changes such as a hosting migration, DNS edit, mailbox change, plugin or software update, PHP-version change, security rule or expired credential.

Where available, inspect form, application, web-server and mail-provider logs. Look for authentication failures, rejected messages, connection errors, rate limits and timeouts. Logs should be restricted and should not contain passwords or unnecessary sensitive form data. OWASP's logging guidance covers useful operational records, access controls and data exclusions.

A practical troubleshooting sequence

1. Send one test submission. Record the time, page, device and test address.
2. Check storage. Confirm whether the website or form platform retained the message.
3. Check recipient systems. Search inboxes, spam, quarantine, rules and forwarding destinations.
4. Verify form settings. Confirm recipient, sender, reply-to, subject and integration settings.
5. Identify the sender. Determine which host, SMTP service or provider handed off the message.
6. Inspect logs. Look for rejected, delayed, throttled or unauthenticated delivery.
7. Review SPF, DKIM and DMARC. Change records only after the sending service is known.
8. Test another recipient provider. Reaching one provider does not prove delivery everywhere.
9. Keep a change record. Save the current settings before restoring a documented known-good configuration.

What not to change blindly

• Do not delete the form before exporting or recording existing submissions.
• Do not change MX records merely because website notifications are missing. MX records control where incoming mail for the domain is handled.
• Do not publish mailbox passwords, API keys or SMTP credentials in a ticket, plugin field shared with untrusted users or chat message.
• Do not add random TXT, SPF, DKIM or DMARC records without identifying the mail service involved.
• Do not assume that installing an SMTP plugin fixes a rejected message, a bad sender address, a rate limit or recipient filtering.
• Do not test only while logged in; permissions, caching and browser scripts can hide a form failure.

Make lead capture easier to monitor

A dependable process should provide more than one signal when a form fails.

• Store submissions in a controlled system with limited access.
• Send notifications to a monitored business mailbox or shared team address.
• Use a confirmation message that does not promise a response time the business cannot meet.
• Run a periodic test submission and record the result.
• Monitor website errors, integrations and credential expiry where the platform supports it.
• Keep a visible phone number or alternative contact method for urgent enquiries.

Form submissions can contain personal information. Limit access, collect only what is needed and establish a reasonable retention process. The Office of the Privacy Commissioner of Canada's privacy guidance discusses safeguards and retention as part of responsible information handling. If a form collects sensitive information, seek appropriate privacy advice rather than treating ordinary email as a secure document system.

When technical help is worthwhile

Ask a qualified website or email administrator for help when the issue involves DNS, sender authentication, hosting logs, malware concerns, repeated lead loss or several providers sharing the same domain. Pause before changing settings if the website and business email are managed by different companies.

Certtech's website security and hacked-site recovery service covers security assessments, forms and user-input review, logging and recovery work. Its Website as a Service offering describes ongoing website maintenance, backups, security and email hosting. For a rebuild or conversion-focused technical review, see the web design service. You can also book a 15-minute discovery call to discuss the problem and the systems involved.

The takeaway

When a website contact form stops sending emails, trace one test from submission to storage, mail handoff and recipient filtering. That evidence is more useful than replacing the form or changing DNS by guesswork. Once the failure point is known, the appropriate fix may be a form setting, mailbox rule, authentication change, provider correction or application repair.