Contact form not sending email

When the mail fails

The visitor clicks submit, the form shows "thanks", and nothing arrives. Failure is usually silent: the browser gets a 200 response back while the mail call itself fails further down the chain. Sometimes mail arrives from one sender address but not another, or lands in spam instead of the inbox, which is a routing and authentication problem rather than a script problem.

Track where the email stops by knowing the pieces between the button and the inbox:

Trace the mail path

1. Take the form out of the equation. Craft a raw mail test that bypasses the form handler. With WordPress, a single wp_mail() from a test script calls the same route the form uses.
2. Read the mail log. The log names the failing step: 450 for a rejected sender, 535 for an authentication failure, or 421 for a temporary delivery problem.
3. Test SMTP in isolation. If the form runs a plugin that uses SMTP, run the plugin's test through its settings page; it does a DNS lookup, a connection, and an authenticated send in one shot.
4. Check the web server error log. A mail() call disabled by disable_functions or a missing MTA shows up as an empty return more than an error. See error log reading.

Common fixes

• The site relied on mail() and the host turned it off. The fix is an SMTP relay with the host's or your domain email account.
• The SMTP password or port changed. Most services expect port 587 with STARTTLS, or 465 with implicit TLS; "Port 25" is usually blocked by the host.
• The plugin hides failures. View the mail log or enable debug logging in the plugin's config and look at the last row.
• The domain's mail policy changed. When SPF or DKIM broke, the receiver still accepts the message but the spam filter buries it. Fix the policy in DNS, not in the form.

Fix order

1. Restore a known-good send. Test a plain wp_mail() from a test page that sends to your own inbox. If that works, the problem is in the form handler; if it fails, the mail route is the problem.
2. Switch the transport path. Replace core mail with an SMTP plugin, add a real sending account, and retest the same test page.
3. Fix authentication. Read the error code, correct the port/TLS pair, or re-enter the app password the provider generated.
4. Set quality expectations. Add headers the MTA expects, set a reply-to that exists, and let the plugin handle line endings.
5. Verify against a real inbox. Send the test message again and confirm delivery, then watch the mail log: a clean send pointer appears where the failure used to be.

Prevention

• Keep form-to-mail routes on a provider you control, not a shared-mail function on a host that disables it.
• Watch SPF, DKIM and DMARC; the mail can be perfect and still land in spam without them. Start with email DNS records.
• Test the whole path on a schedule: one script, one SMTP pass, once a month.

When to involve a professional

If a clean SMTP test succeeds but real visitors on some ISPs never see the email, the policy and DNS are suspect, not the plugin. A DNS audit is the right professional call, not another mail plugin.