Quick answer
Follow one controlled form or application event from the new website through its handler and mail queue to a test recipient. Require both the correct application state and message arrival. A “sent” banner or accepted queue item is only an intermediate result.
A rendered form is not a delivered message
After a hosting move, a form can display normally while its handler, queue or mail route fails. Test the application’s actual sending path with its owner. This guide does not assume an included mailbox, outbound relay or particular mail provider.
Use a controlled test recipient and invented, non-sensitive form values. Avoid real payment, medical or personal data in a diagnostic submission. Record the expected event and what success should look like.
Map the old and new sender paths
Identify whether the application sends through local mail software, authenticated SMTP, an API provider or a queue worker. Record the actual service endpoint, sender identity, credentials location, DNS authentication dependency and environment-specific configuration without exposing secrets. A web DNS cutover can also change an SPF a mechanism or a contact-form host dependency; compare old and new routes rather than copying a stale password or server name.
Check that the new environment has the required job or queue worker running where the application uses one. Confirm form endpoints, CSRF handling and callback/webhook URLs are set for the canonical host, not a temporary preview address.
Follow one controlled event end to end
Submit the form from the public canonical URL and record the HTTP result, time and unique test token. A POST response indicates what the web application returned, not that an email was accepted by a mail server. Inspect the application’s own event or queue status using authorised access. Then verify the recipient actually received the message, including spam folder if relevant, and check From, reply-to and authentication results. For a transactional event, use its documented test mode or a reversible low-impact event and verify both user-facing and administrative notifications where intended.
Compare a test through the new host with the same workflow on the old host only if the migration plan permits dual operation; avoid duplicate real orders or customer messages. If the form handler errors, fix application code/configuration. If the queue accepts but mail never leaves, ask the operator for a delivery trace. If the recipient rejects it, use the exact bounce and authentication results.
Make a bounded fix and repeat the same test
Correct the verified application endpoint, worker, credential or sender policy through the authorised owner. Never disable TLS certificate validation, publish credentials or broadly allow unauthenticated SMTP as a workaround. If DNS authentication needs change, use the existing SPF/DKIM guides and preserve unrelated mail records. Repeat a fresh controlled submission and require actual recipient arrival plus correct application state before declaring success.
If the change creates duplicate sends or affects real users, restore the saved configuration and pause the test path. Share redacted event IDs, timestamps, HTTP status, queue state and bounce text with support. Remove test records and messages under the application’s retention policy.
Example: trace one contact-form submission
Submit invented values to an authorised test form and include a unique harmless reference such as migration-check-01. Match that reference and timestamp in the application event, queue or delivery trace and the received message. Check the intended recipient and Reply-To field without forwarding private message content into a ticket.
If the recipient receives two messages for one event, check for workers running on both hosts or a retried event before repeating tests. Pause the controlled test path and fix the duplicate-send cause.
Common questions
Does a “message sent” page prove delivery? No. Trace the handler, queue and recipient.
Could web DNS affect outgoing mail? Yes, if the sender route or SPF policy depends on that address.
Should I change MX? MX is for inbound routing; diagnose the actual outbound path first.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.