Forms and email are the two things a migration most often breaks silently — the site looks perfect, but contact submissions never arrive and order confirmations never send, and you find out only when a customer complains that they emailed you and heard nothing. Because these functions fail invisibly, behind a working-looking front end, testing them deliberately after a migration is essential, not optional. This guide shows you exactly how to test both, and why email in particular deserves a re-test after DNS has settled.

You will learn why forms and email break in a migration, how to test forms end to end (not just that they display), how to test email sending and receiving, the DNS timing that makes email a two-stage test, how to diagnose the common failures, and how to confirm everything is genuinely working. By the end you will be able to verify the money-and-communication paths your site depends on, catching the failures that a visual check would miss.

Why forms and email break in a migration

Forms and email depend on parts of your setup that a migration can disturb without any visible sign. A form works by taking a submission and sending it somewhere — usually an email notification to you, and often a record in the site. Email on your domain depends on mail routing (MX records) and on the sending method the site uses. A migration can change the server, the DNS, and the configuration all at once, and any of those can quietly sever how forms deliver or how mail flows.

The reason the breakage is invisible is that the front end — the form displaying on the page, the site loading correctly — is entirely separate from the delivery mechanism behind it. A contact form can render perfectly and accept a submission, showing the visitor a cheerful ‘thank you’, while the notification email that should reach you silently fails to send. Nothing on the page reveals the problem, because the failure happens after the visible interaction, in the plumbing.

So forms and email break for the same underlying reason they are easy to miss: their real work happens behind the scenes, in mail routing and sending configuration that a migration can change and a visual check cannot see. This is precisely why you must test them by actually using them end to end — submitting a real form and sending a real email — rather than trusting that a good-looking site means working communication. The whole point of the test is to exercise the invisible half.

Testing forms end to end

Testing a form properly means submitting it and confirming the submission genuinely arrives where it should — not merely checking that the form appears and accepts input. Go to each important form on your migrated site (contact form, quote request, newsletter signup, any lead form) and complete it as a real visitor would, with test details you will recognise, then submit it.

Then verify the two things a form is supposed to do: that you receive the notification (check the inbox where form submissions are meant to land, including spam), and, if your form also stores entries, that the entry was recorded in the site. A form that shows a success message but produces no notification and no stored entry is broken — the visitor thinks they reached you, but nothing arrived. Test every distinct form, since they can be configured differently and one may work while another fails.

So end-to-end form testing is: fill in and submit each form with recognisable test data, then confirm the notification actually arrives and (where applicable) the entry is stored. This exercises the whole path from the visitor’s click to your inbox, which is the only way to know the form truly works. If the notification does not arrive, the problem is almost always in email sending — which is the same underlying issue as broken site email, covered next, since form notifications are just one kind of site-sent mail.

Testing email sending and receiving

Email on your domain has two directions to test, and both matter. Receiving: send a test message from an outside account (a personal address on another provider) to an address on your domain, and confirm it arrives in the right mailbox. Sending: from your domain’s mailbox, send a message out to an outside account, and confirm it arrives there (and not in spam). Both directions must work for your domain email to be functional.

Separately, test the email your site itself sends — which is distinct from mailbox email. Sites send transactional mail: contact-form notifications, order confirmations, password resets, account emails. Trigger each of these (submit a form, place a test order, run a password reset) and confirm the resulting email actually arrives. Site-sent mail can fail even when your mailbox email works, because the site uses its own sending method, so test it specifically.

So testing email covers three things: receiving to your domain mailboxes, sending from them, and the transactional mail your site generates. Work through all three, using recognisable test messages and checking spam folders as well as inboxes. Email is the single most commonly broken and overlooked thing in a migration, so this thoroughness is warranted — but there is an important timing wrinkle, because some of these depend on DNS that only takes effect after cutover, which makes email a two-stage test.

The DNS timing that makes email a two-stage test

Email routing depends on DNS — specifically your MX records, which tell the world where to deliver mail for your domain — and DNS changes only take full effect after propagation. This means some email behaviour cannot be conclusively tested before cutover, because the mail routing that will apply live is not yet in force. So email testing is genuinely a two-stage affair, split across the migration.

Before cutover, you test what you can: that mailboxes exist and are set up correctly on the new setup, that the site can send mail from the new server, and that your MX plan is correct. But the definitive test of live mail flow — that messages to your domain actually land in the right place, and that sending works under the live DNS — can only be done once the DNS change has propagated, because until then mail is still routing according to the old records.

So plan to test email in two stages: as much as possible before cutover, and then a mandatory, thorough re-test immediately after DNS has propagated. This is why email appears both in pre-cutover testing and again in the post-migration checklist. Do not treat a pre-cutover email check as final — the real confirmation comes after propagation, when the live routing is active. Re-testing email right after the DNS settles is the step that catches mail-flow problems the pre-cutover test could not have revealed.

Diagnosing the common failures

When a form or email test fails, the cause usually falls into a short list of culprits, and knowing them speeds the fix:

• Form notification not arriving: almost always a site email-sending problem — the site cannot send mail from the new server. Configuring a reliable sending method (such as authenticated SMTP) usually fixes it.
• Domain mail not arriving: an MX-record problem — mail is routing to the wrong place (often still the old host, or nowhere). Check the MX records point to the correct mail server.
• Mail landing in spam: missing or misconfigured sender-authentication records (the DNS records that vouch for your mail), which a migration can leave incomplete on the new setup.
• Site email delayed or intermittent: often a sending-method or server issue worth stabilising with a dedicated sending service rather than the default server mail.

So diagnosis follows the symptom: a missing form notification points to site sending, missing inbound mail points to MX records, and spam-foldering points to sender authentication. Most of these trace back to two areas — mail routing (MX) and sending method/authentication — both of which a migration can disturb and both of which are fixable once identified. Matching the failure to its cause turns ’email is broken’ into a specific, addressable problem, which is exactly what a deliberate test is for: not just finding that something is wrong, but pointing you at what to fix.

Confirming everything works

You have confirmed forms and email are genuinely working when every test passes in both stages: forms submit and their notifications arrive (and entries store), domain mailboxes receive and send correctly, and site-generated transactional emails all land — all verified after DNS has propagated, under the live routing. That is the standard, because anything less leaves a silent-failure gap in the functions your site relies on.

Be systematic in the confirmation: keep a short list of every form and every kind of email your site sends, and tick each off as you verify it arrives, checking spam as well as inboxes. Missing even one — a rarely-used form, an order-confirmation email you did not trigger — is how a broken path slips through, so cover them all rather than testing one form and assuming the rest work.

So confirming everything works is a matter of exercising each form and each email type end to end, after propagation, and checking that every one actually delivers. Because these are the invisible, high-value functions a migration most often breaks, this thorough confirmation is what turns ‘the site looks fine’ into ‘communication genuinely works.’ Done properly, it closes the single biggest silent-failure risk of a migration — the one where the site appears perfect while quietly failing to send or receive the messages your business depends on.

FAQs

How do I test forms after a migration?

Submit each important form on your migrated site with recognisable test data, then confirm the two things a form should do: that the notification email actually arrives (check spam too) and, if your form stores entries, that the entry was recorded. A form that shows a success message but produces no notification is broken. Test every distinct form, since they can be configured differently and one may work while another fails.

How do I test email after changing hosts?

Test three things: receiving (send a message from an outside account to your domain mailbox and confirm it arrives), sending (send from your domain mailbox to an outside account and confirm delivery, not spam), and site-generated mail (trigger contact-form notifications, order confirmations, and password resets, confirming each arrives). Do this after DNS has propagated, since live mail routing only applies then.

Why do form notifications stop arriving after a migration?

Almost always because the site can’t send mail from the new server — the sending method didn’t carry over or isn’t configured. The form accepts the submission and shows a success message, but the notification email silently fails. Configuring a reliable sending method (such as authenticated SMTP) usually fixes it. It’s the same underlying issue as broken site email, since form notifications are one kind of site-sent mail.

Why is email a two-stage test in a migration?

Because email routing depends on DNS (your MX records), and DNS changes only take full effect after propagation. Before cutover you can test that mailboxes exist and the site can send, but the definitive test of live mail flow can only be done once DNS has propagated, since until then mail routes by the old records. So test what you can before cutover, then do a mandatory thorough re-test right after propagation.

Why is my migrated site’s email going to spam?

Usually missing or misconfigured sender-authentication records — the DNS records that vouch for your mail’s legitimacy — which a migration can leave incomplete on the new setup. Setting up proper sender authentication for your domain on the new configuration typically resolves it. Using a dedicated, reputable sending method for site mail also improves deliverability compared to default server mail.

What are the most common form and email failures after migrating?

Form notifications not arriving (a site email-sending problem), domain mail not arriving (an MX-record problem — mail routing to the wrong place), mail landing in spam (missing sender-authentication records), and intermittent or delayed site mail (a sending-method issue). Most trace back to mail routing (MX) or sending method/authentication, both of which a migration can disturb and both of which are fixable once identified.

The bottom line

Forms and email are the functions a migration breaks most invisibly, because their real work happens behind a working-looking front end: a form can render perfectly, accept a submission, and show a cheerful ‘thank you’ while the notification silently fails to send, and your domain mail depends on routing and sending configuration that a migration can change without any visible sign. That is exactly why you must test them by using them end to end, not by trusting that a good-looking site means working communication. For forms, submit each one with recognisable test data and confirm the notification actually arrives (spam included) and any entry is stored. For email, test all three paths — receiving to your domain mailboxes, sending from them, and the transactional mail your site generates (form notifications, order confirmations, password resets).

The crucial subtlety is timing: because email routing depends on DNS that only takes full effect after propagation, email is a genuine two-stage test — check what you can before cutover, but do a mandatory, thorough re-test immediately after the DNS settles, when the live routing is finally active. When a test fails, match the symptom to its cause: a missing form notification points to site sending, missing inbound mail to MX records, spam-foldering to sender-authentication records — most trace back to mail routing or sending method, both fixable once identified. Work through every form and every email type systematically, after propagation, ticking each off as you confirm delivery. Do that, and you close the single biggest silent-failure risk of a migration: the one where the site looks flawless while quietly failing to send or receive the messages your business depends on.

When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. Test forms by submitting each with recognisable data and confirming the notification arrives (check spam) and entries store. Test email in three directions — receiving to your domain, sending from it, and site-generated mail (form notifications, order confirmations, password resets). Because mail routing depends on DNS, re-test email AFTER propagation, not just before cutover. Missing notifications point to site sending; missing inbound mail to MX records; spam-foldering to sender authentication.