Why contact form emails go missing, and how to fix it
Contact form emails go missing for three kinds of reason: the form fails before any email is sent, the message leaves your website in a way the receiving inbox does not trust, or the receiving side hides it. Each is fixable without a new website: the checks below cost nothing, and a site built from scratch, from EUR 600-900 at step 01, is not what this problem needs.
The fix is a handful of DNS records, a change to how the form sends, and one habit that stops a lost email from meaning a lost enquiry.
Why enquiries go missing
When your form sends a message, the receiving mail server checks who claims to have sent it and whether that sender is allowed to. If the checks fail, the message goes to spam, into quarantine, or nowhere. These are the causes worth checking:
- The form sends as the visitor. Some forms put the visitor's own address in the From line. Your website has no right to send as their email domain, and that domain's policy can tell receiving servers to reject or quarantine the message.
- Your domain is not set up to send. SPF is a DNS record listing the servers allowed to send for your domain. DKIM lets a receiving server verify a signature on each message. DMARC tells receivers what to do when those checks fail, and requires the domain in the From line to match a domain that passed.
- The web server sends the mail itself. A form using the hosting server's built-in mail function can send from a machine that is not in your SPF record and does not sign with your DKIM key.
- The mail goes to the wrong place. If the web server believes it handles mail for your domain, it can drop the message into a mailbox on that server that nobody reads.
- The form breaks before sending. A spam check that stopped working, a script error or a server error can reject a real submission. The visitor may see an error, or nothing at all.
- The receiving side hides it. A filter rule, a full mailbox, a quarantine folder, or notifications still going to a former colleague. Forwarding can also break SPF, because the forwarding server is not on the original list.
How to check, without being technical
- Send yourself a test. Fill in the form using an address at a different email provider from your business email. Note whether a success message appears.
- Look everywhere it could land. Inbox, spam, any other tabs, and quarantine if an IT provider manages your email.
- Read the verdict. If your business email runs on Gmail or Google Workspace, open the message, use the three-dot menu and choose Show original. The top of that page shows the SPF, DKIM and DMARC results the message carries, such as pass or fail. Other email programs let you view the message source or headers.
- Look up your records. Any public DNS lookup tool shows your domain's TXT records. Look for one record starting with v=spf1, and a DMARC record at _dmarc.example.com, with your own domain in place of example.com.
- Compare and confirm. If the site keeps a copy of each submission, compare that list with the emails you received, and check the destination address in the form settings.
What you see and what it points to
| What you see | What it points to | What fixes it |
|---|---|---|
| An error, or no success message, after pressing send | The form itself: a broken spam check, a script error or a server error | Repair the form, then test on phone and desktop |
| A success message and a stored submission, but no email | Delivery: rejected on the way, or dropped into a mailbox on the web server | Send through an authenticated email service to the right inbox |
| The email lands in spam, or Show original reports a fail | SPF, DKIM or DMARC missing or failing, or a filter trained by spam submissions | Authenticate the sending service in DNS, send from your own domain, keep bots out |
| Emails stopped after moving host, email provider or DNS provider | Records not carried over, or still pointing at the old setup | Update the records for the new setup, then test again |
What fixes it
- Send from your own domain. Use an address on your domain in the From line and the visitor's address in Reply-To, so pressing reply still reaches them.
- Send through an email service, not the web server. A transactional email service sends through servers you authorise in DNS.
- Publish the records. Exactly one SPF record covering every service that sends for your domain, the DKIM record your sending service gives you, and a DMARC record. Two SPF records break the check, and SPF limits how many lookups it may trigger, so remove services you no longer use.
- Start DMARC in monitoring mode. A policy of p=none with a reporting address shows what sends as your domain before you tell receivers to quarantine or reject failures.
- Store every submission. Save each enquiry in the site's database as well as emailing it, so email is the alert and not the only record.
- Keep bots out, and test after every change to the spam check, hosting, DNS or email. A broken spam check can block real people too.
DNS records live wherever your domain's DNS is managed, which is not always where the site is hosted, and domains and DNS explained shows how to find out. A change is not always visible everywhere at once, so if a test fails straight after one, test again later.
Process and timeline
On a site that is otherwise fine, the order is: run the checks, fix the records, change how the form sends, store submissions, then test from more than one email provider. None of it needs a redesign. If you want the site looked after afterwards, Care at EUR 100-300 a month covers updates, monitoring, backups and small fixes.
If you are rebuilding anyway, each of the first three steps includes a way to reach you: a form at step 01 (EUR 600-900, 1-2 weeks), a contact flow at step 02 (EUR 900-1.500, 2-3 weeks), and booking or contact at step 03 (EUR 1.500-3.500, 3-6 weeks). Whoever builds it, put the fixes above in the brief and check them in a proper pre-launch test. If you are moving the site, how to move an existing website covers what to carry over.
When to spend less
- The records are the only problem. Follow your email provider's SPF and DKIM instructions and have whoever manages your domain add the records. In this case, do not hire anyone.
- The form fills up with junk. Fix the spam protection first. A bigger site does not solve bots.
- You are tempted to replace the site because of the form. Do not buy a bigger build for an email problem. A form that sends correctly is a small fix, not a reason to start over.
Common questions
Is this a website problem or an email problem?
Both. The form decides how the message is sent, your domain's DNS says who may send for you, and the receiving inbox decides whether to trust it. Agree who owns the whole chain, so nobody assumes it is someone else's job.
Can spam submissions push real enquiries into spam?
They can. Marking junk from the form as spam can teach your mailbox to file similar messages there, and form notifications look alike. Keeping bots off the form protects the real enquiries too.
How do I know it is fixed?
Send tests from addresses at more than one provider and check that each arrives in the inbox. Show original, or your email program's equivalent, should show SPF, DKIM and DMARC passing, and the stored submissions should match the emails you received.
If enquiries are going missing and you want a second pair of eyes on the setup, send us a message here.
Building something?
JP Studio designs and builds websites, storefronts and product interfaces.