A domain change affects more than the visible URL. WPForms can still store an entry while notification mail fails because WordPress URLs, sender identity, SMTP credentials, CAPTCHA keys or DNS authentication still refer to the previous domain.
Trace a new synthetic submission first, then update only the stale dependency you can prove.
Establish what still works
Submit the public form while logged out and record the new URL, time, form ID and expected recipient. Check the browser request and confirm whether WPForms stored an entry.
If no entry exists, inspect JavaScript, reCAPTCHA, nonce, REST/AJAX and PHP errors. If the entry exists but email is absent, focus on notification generation and delivery.
Review entries received since the domain switch so authorised staff can recover missed enquiries.
Confirm WordPress uses the new URL
Check the WordPress Address and Site Address, including HTTPS and www choice. Search the rendered form page for old-domain script, REST or AJAX URLs. Mixed origins can be blocked by the browser or a security policy.
Run a careful serialized-data-aware search and replace only if the migration process left old URLs in the database. Take a database backup and preview the replacement scope first.
Do not use a plain SQL string replacement across serialized WordPress data.
Inspect the active WPForms notification
Open the exact form used on the page and verify that notifications are enabled. Review Send To, subject, From Name, From Email and Reply-To smart tags.
Use an address on the newly authorised sending domain as From. Put the visitor’s submitted email in Reply-To. Confirm conditional notifications still match their field values after any form edits.
Test the real form because a general SMTP test may bypass WPForms rules.
Reconnect the mail transport
Determine whether the site uses SMTP, a transactional mailer or local PHP mail. Domain migrations can invalidate encrypted credentials, API authorisations or redirect URLs.
Re-enter credentials through the plugin interface if necessary and verify the selected From domain in the provider account. Check that the new server can connect to the required SMTP port and that its clock and TLS certificates are correct.
Never disable TLS verification or expose API keys in logs.
Publish authentication for the new sender
Review SPF, DKIM and DMARC for the domain shown in From. Use the exact records supplied by the current mail provider. Keep a single SPF TXT policy and avoid copying obsolete authorisations from the old host without checking them.
Changing the website A record does not automatically update email authentication. Likewise, MX records govern inbound routing and normally should not be changed to repair outbound form notifications.
Allow DNS changes to propagate, then inspect a delivered message’s headers.
Update CAPTCHA and security allowlists
Confirm reCAPTCHA or hCaptcha keys permit the new hostname. Check consent tools and Content Security Policy for old-domain script rules. Review Cloudflare, ModSecurity and WordPress security events at the test time.
If the old domain redirects to the new one, ensure the final page does not retain a stale cached form, nonce or endpoint. Purge only the affected cache after the source settings are corrected.
Do not permanently exempt all form requests from security controls.
Check redirects and confirmation actions
WPForms may redirect successful submissions to a thank-you page or use a confirmation URL. Update old-domain targets and ensure analytics fires only after a genuine server success.
Review webhook, CRM and automation endpoints separately; a working email does not prove those integrations survived the move.
Test both a normal submission and any conditional route or upload path in use.
Verify from visitor to mailbox
Make a fresh labelled submission on the canonical HTTPS domain. Confirm one browser success, one stored entry, the correct WPForms notification, one provider acceptance and final mailbox arrival.
Check Reply-To and SPF/DKIM/DMARC results. Test the business recipient rather than relying only on a personal inbox.
Request urgent repair when entries are accumulating, DNS ownership is uncertain or the old and new domains remain mixed. Share timestamps, URLs and redacted errors—never credentials or customer entry content.