Test form delivery as a chain, not a single Submit button. Send a marked enquiry, confirm the form endpoint accepted it, verify the website only shows success after that response, inspect the generated email, check SPF and DKIM results, search spam or quarantine, confirm the final inbox receives it and test Reply-To. Record the first failed checkpoint and fix that layer.

A contact form can work perfectly in the browser while its notification email never reaches the person who needs to answer it.

That is why “I clicked Submit and saw a green message” is not a deliverability test.

The enquiry passes through several systems: the page, form endpoint, email service, sending domain, receiving mail server, spam controls and final inbox. Test the chain in order so you can identify the first place it breaks.

Mark the test so you can find it

Use a unique name and subject inside the test message.

For example:

FORM DELIVERY TEST - 09 AUG 2026 - 10:45

Include the same marker in a name or message field. Record the exact submission time.

This gives you something specific to search for in the server logs, mailbox, quarantine logs and CRM.

Do not test using a real customer’s private information. Use a controlled address you can access.

Checkpoint 1: did the browser send the request?

Open the form on a phone or computer and complete every required field.

If the page uses JavaScript, the browser may send the form through fetch() rather than perform a normal page navigation. A working interface should tell the visitor when the request is still sending, when it succeeds and when it fails.

If you can inspect browser developer tools, open the Network panel and submit the test. Look for the request to the form endpoint.

Record:

  • request URL;
  • HTTP status;
  • response time;
  • whether the response says the submission succeeded.

A JavaScript animation is not evidence that the server accepted the message.

Checkpoint 2: does success appear after the endpoint confirms it?

The success message should depend on the response from the submission endpoint.

A reliable AJAX form waits for the endpoint response before treating the action as complete. If your website immediately changes the button to “Sent” before the request finishes, a network failure can create a false success state.

Test failure deliberately on a staging copy or by disconnecting the network before submission. The website should explain that the message did not send and preserve the customer’s typed information where possible.

This checkpoint answers one question:

Did the form system accept the submission?

It does not yet prove that an email arrived.

Checkpoint 3: did the server create the submission event?

If your form workflow records server logs, database events or delivery records, search for the marker.

If the request exists in the server record but no notification email arrives, the website-to-server part of the chain is working. The problem is further downstream.

Check whether:

  • email delivery is enabled;
  • the receiving address is correct;
  • an old employee or mailbox is still configured;
  • notification rules differ by form;
  • OAuth, API or account limits have interrupted delivery.

If the server did not record the submission, return to the website endpoint and browser request before changing DNS records.

Checkpoint 4: inspect the notification email authentication

When a notification arrives in any mailbox, inspect the message headers or authentication details.

Look for results for:

  • SPF;
  • DKIM;
  • DMARC where available;
  • the visible From domain;
  • the Return-Path or envelope sender;
  • Reply-To.

Google recommends authenticating sending domains with SPF or DKIM and requires stronger authentication and alignment for higher-volume senders. DMARC builds on SPF and DKIM alignment.

A form notification may legitimately be sent from the authenticated mailbox while using Reply-To for the customer. Problems appear when the sending setup tries to impersonate the customer’s address or a domain that has not authorised the sending system.

Do not “fix” deliverability by publishing a random SPF record copied from another company. SPF must reflect the services actually authorised to send for your domain.

Checkpoint 5: search spam, junk and quarantine

Search by the unique test marker, sender and submission time.

Check:

  • Inbox;
  • Spam or Junk;
  • Google Workspace quarantine where used;
  • Microsoft 365 quarantine where used;
  • shared mailbox folders;
  • forwarding destinations;
  • server-side mail filters.

A message can pass authentication and still be filtered. Content, sender reputation, forwarding and recipient behaviour can affect delivery.

If the message appears in quarantine, capture the reason before releasing it. The reason is more useful than simply adding the sender to an allow list.

Checkpoint 6: confirm the right person receives it

A technically delivered email can still become an operational failure.

Open the final mailbox and ask:

  • Is this the inbox the team actually monitors?
  • Can more than one responsible person access it if needed?
  • Is there an owner for new enquiries?
  • Does a forwarding rule send a copy somewhere unexpected?
  • Is the message easy to identify as a website enquiry?

A generic subject such as “New submission” can disappear inside a busy inbox. Include enough context to identify the website or service without exposing unnecessary private data.

Checkpoint 7: test Reply-To

Press Reply on the notification.

The new message should address the customer’s email when that is the intended workflow.

A common configuration mistake sends the reply back to the notification mailbox instead of the customer.

Do not use the customer’s email as the authenticated From address when your mail system is not authorised to send as that customer’s domain. Use the authenticated business mailbox as From and set Reply-To correctly.

Checkpoint 8: test more than one recipient environment

A message that reaches one Gmail inbox does not prove universal delivery.

Where practical, run controlled tests to:

  • Gmail;
  • Microsoft Outlook or Microsoft 365;
  • the business’s actual receiving mailbox.

You are looking for patterns. If Gmail receives the message but the company mailbox quarantines it, investigate the company’s filtering and domain configuration. If every provider rejects or filters it, investigate the sending system and authentication first.

Keep form conversion and email delivery as separate tests

The existing IDJoy contact-form conversion test focuses on what the customer experiences: field friction, validation, mobile usability, success states and fallback contact routes.

This deliverability test focuses on what happens after the browser sends the message.

You need both.

A low-friction form that never reaches the inbox loses leads. A perfectly delivered notification from a form nobody finishes also loses leads.

Record the first failed checkpoint

Do not change five systems at once.

Use a simple log:

Checkpoint Result Evidence Next action
Browser request Pass / fail HTTP status
Server record Pass / fail Request or event ID
Notification generated Pass / fail Timestamp
Authentication Pass / fail SPF/DKIM/DMARC
Spam/quarantine Pass / fail Folder/reason
Final inbox Pass / fail Received time
Reply-To Pass / fail Correct address

Fix the first broken link, then rerun the same marked test.

That approach is faster than guessing whether the problem is “the website”, “Gmail” or “DNS”.

Retest after changes that touch the chain

Run the test again after:

  • moving a website;
  • changing the form backend;
  • changing DNS;
  • moving from one email host to another;
  • changing the receiving mailbox;
  • adding a CRM;
  • changing spam protection;
  • editing SPF, DKIM or DMARC;
  • changing a domain name.

For a website that generates regular leads, schedule a routine test and keep the last successful date in your maintenance records.

IDJoy can review the website form and professional email setup together because the customer journey crosses both systems. Check IDJoy service and support options if you want the full enquiry route tested rather than only the visible form.