Why “it looks fine” is not enough
Your website can look perfect and still stop collecting leads. Plugin updates, theme swaps, DNS or mail changes, CDN/WAF toggles, and host moves all touch the path from “Submit” to your inbox. A contact-form smoke test is the same-day check that proves a real message still arrives—before you assume the form is fine.
This is an operator checklist for small businesses. It is not a full security audit. It is the routine TwoQM recommends after any change that could break forms, mail, or captchas.
A form can render, validate, and show a thank-you page while the message never lands. Common silent failures:
Success page or AJAX “sent” UI, but SMTP or the form plugin fails in the background
CAPTCHA keys point at staging, so live visitors never clear Turnstile or reCAPTCHA
From / Reply-To addresses no longer match SPF/DKIM after a DNS or host move
Notifications still go to a departed employee’s mailbox
CRM webhook works on staging keys and fails in production
WAF or CDN challenge blocks the POST your form uses
Logging is off, so nobody notices until a week of empty leads
None of these require a breach. They require an untested change.
Name who owns the inbox
Before you test, write down:
Primary notification destination — shared inbox, CRM, or both?
Who is on-call if that destination fails today?
Where spam lands — company spam folder, provider tools, host mail logs?
Who can change form settings, DNS (SPF/DKIM/DMARC), and captcha keys?
If “whoever built the site” is the only answer, fix ownership first. A smoke test without a named owner becomes theater.
When to run the smoke test
Run it the same day as:
Plugin, theme, or form-builder updates
Theme or page-builder changes that touch the form block
DNS changes (hosting, mail, CDN, subdomain moves)
Mail provider or SMTP plugin changes
CDN, WAF, bot-fight, or rate-limit toggles
Host migration or staging → production cutover
Captcha provider swaps (Turnstile ↔ reCAPTCHA ↔ hCaptcha)
CRM or notification routing changes
Do not wait for next month’s marketing report. Lead silence is quiet until it is expensive.
Staging vs live keys
Staging and production break forms in different ways. Treat them as separate systems.
Captcha: Staging keys on staging only; live keys on live only. A live form with staging keys often fails for real visitors while an internal test (whitelisted IP or test key) “works.”
SMTP / API: Staging should send to a monitored test mailbox. Production should send to the real shared inbox or CRM—never leave production pointed at a developer’s personal email.
Webhooks: Confirm the production CRM endpoint and auth token, not last week’s Zapier test URL.
Document which environment you are testing. Mixing them is how teams ship green checkmarks and zero leads.
What to verify in one pass
Open an incognito window (or a phone on mobile data). Submit the live form with a unique subject like SMOKE-2026-09-23-A. Then verify:
UI path — Expected success message or thank-you page (not a blank screen, 500, or endless spinner).
Message arrives — Within your expected window, the note hits the shared inbox or CRM with the correct fields.
Reply path — Reply-To (or From, if that is your design) lets you answer without bouncing.
Spam / CAPTCHA — Turnstile or reCAPTCHA completes for a normal visitor; you are not only passing because you are whitelisted.
No silent fail — If mail fails, the form should not pretend success. Prefer a clear error and a log entry over a fake thank-you.
Routing — CRM vs shared inbox vs both, and the right people get notified.
Logging — Form plugin or server log shows the submission. If logging is off, turn on enough to debug the next failure.
Optional: submit once from mobile data so CDN/WAF rules that trust your office IP do not hide a block.
DNS and mail after changes
After DNS, host, or mail-provider changes, forms fail in boring ways:
SPF/DKIM mismatch — The form sends as noreply@yourdomain.com from a host that is no longer authorized. Messages bounce or land in spam.
From vs Reply-To — Deliverability often needs a domain you control plus a Reply-To your team monitors.
Orphaned forwarding — Notifications go to an address that no longer exists.
You do not need to redesign mail during a smoke test. Confirm today’s submission arrives and is replyable. If it lands in spam, fix authentication before you celebrate.
Same-day checklist
Use this after every relevant change:
Named owner of inbox / CRM notifications
Confirm live (not staging) captcha keys on production
Confirm SMTP/API and webhook targets for production
Submit unique test lead from a clean browser / mobile data
Success UI matches expectation (no silent fail)
Message arrives in shared inbox and/or CRM
Reply-To works; From passes basic spam checks
WAF/CDN did not block the POST
Submission appears in form or server logs
Note backup notification path if primary fails
Log time, triggering change, pass/fail, owner initials
If any box fails, fix before you close the change ticket. “We’ll watch it next week” is how empty pipelines start.
Make it a habit
Pair the smoke test with your release notes. One named person, one unique subject line, one confirmation in the real destination. That is enough for most small-business stacks.
TwoQM’s bias is simple: after you touch plugins, themes, DNS, mail, CDN/WAF, or hosting, assume the form is broken until a real message proves otherwise. The smoke test is cheap. Missing a week of quote requests is not.