Our contact form is not sending emails: what should we check?

Find where the enquiry stops before changing the mail settings. Did the form accept the submission? Did the website hand the message to a mail service? Did that service deliver it, reject it or place it in spam? A thank-you screen alone cannot answer all three questions.

Check the intended mailbox, including spam

Agree a controlled test using dummy details, record its time and check the actual destination address. Look in spam and junk as well as the main inbox. Check forwarding rules and shared-mailbox access too: the message may be somewhere other than the folder your colleague is watching.

Jetpack’s WordPress guide starts with spam checks and describes sender settings, hosting restrictions and plugin conflicts as possible causes. These are leads to investigate, not proof of the cause on your site. WordPress is an example here; the same enquiry can stop at different stages on another platform.

Separate authentication from successful delivery

Google’s rules for personal Gmail accounts require SPF or DKIM for all senders. Above 5,000 messages daily to those accounts, both and DMARC are required. These are provider-specific requirements, not a universal exemption below that volume.

Have the host or developer check the real sending service, domain configuration and recipient’s requirements. Authentication and transport encryption answer different questions. Adding DNS records does not by itself prove that a message reached the inbox, and the use of PHP mail() alone does not establish the encryption used along the delivery route.

WordPress documents that a true result from wp_mail() does not prove receipt. PHP likewise distinguishes mail accepted for delivery from mail reaching its destination. Ask for evidence from the sending service and the receiving mailbox instead of treating a successful function call as the final result.

Check settings and recent changes

Verify the destination address, the configured sender and the reply-to setting. Check which service is actually responsible for sending, rather than assuming the website host also runs the mailbox. If several tools can send mail, find out which handled this particular test.

Compare the first observed failure with recent changes to the form, plugins, hosting, DNS or mail credentials. A nearby update is a useful lead, not proof of blame. Ask the maintainer to inspect the relevant logs before replacing components or changing several settings at once.

Work through the enquiry path in order

Record an agreed test time and destination, then check the form’s visible result and any saved submission.
Check whether the site created a send request and whether the configured mail service accepted it.
Look for delivery events, rejection details or a bounce, and check spam and mailbox rules.
Review the sending domain’s authentication and the recipient provider’s requirements with the responsible maintainer.
Correct the identified fault and repeat the controlled test through to the intended inbox.

An authenticated SMTP connection or a transactional mail service may be part of the repair if the current sending arrangement is the problem. Neither option guarantees inbox placement. Check the actual configuration, credentials, error reporting and final receipt after the change.

What should you send to the host or developer?

Provide the page address, test time, intended recipient, visible message and any relevant error or delivery identifier. Explain whether the submission was saved and whether another message from the site can be delivered. Keep passwords and private customer message content out of a routine support request.

Ask who owns the next check: the form maintainer, website host, sending service or receiving-mailbox administrator. If the first service accepted the message, ask for its next delivery result. This keeps the investigation attached to the point where evidence ends.

Questions

It worked last month. Does that prove an update broke it?

No. Check the timing of updates and configuration changes against the first observed failure. Credentials, routing, quotas and recipient filtering also need examination. Change the identified cause, then verify the complete enquiry path again.

Does authentication matter for a form with very few messages?

Check the receiving provider’s rules even at low volume. A small form is not automatically exempt from authentication requirements. Valid authentication is one part of the sending arrangement; it is not a promise that every message will arrive in the inbox.

Do we have to buy a tool just to inspect DNS records?

No separate subscription is inherently needed for an ordinary DNS lookup. Your host or developer can inspect the published records. Choosing the right values and checking the live sending configuration are separate tasks; avoid adding guessed records or sharing credentials to make a check.

Sources

Include an inbox delivery check in regular monitoring

Monitoring and Care includes a test enquiry through your form on a regular schedule, to help detect a broken enquiry flow. The check should confirm receipt in the intended inbox, rather than stop at a thank-you screen.

Ask about monitoring

or write to contact@ergostrat.com