Contact Form Enquiries Not Reaching Your Inbox? The Usual Causes and How to Test

A customer says they filled in your website’s contact form on Monday. It is now Thursday, nothing has arrived, and you cannot tell whether they never sent it or something between the form and your mailbox swallowed it. This guide gives a non-technical owner a calm order of checks: what to look at first, how to test properly, the usual causes, and what to ask whoever built or hosts the site. It is deliberately generic. It does not describe how any particular form tool sends mail, and it makes no claim about how forms on Gotka-built sites do.

How a form message travels, and the first ten-minute checks

A contact form message passes through five links before you read it:

• The visitor’s browser. They press Send. A captcha or hidden spam check may stop the entry here.
• Your website. The form code receives the entry and decides whether to accept it. Some tools also save a copy; many do not.
• The sending step. The site hands the message to a mail server, either through the web server’s built-in mail function or by logging in to a real mailbox (SMTP).
• The receiving provider. The service that hosts the recipient mailbox checks who sent the message, then accepts it, puts it in junk or rejects it.
• Your mailbox and its rules. Storage limits, filters, forwarding and shared-mailbox settings decide where it lands.

A break at any link is usually silent. The “Thank you” the visitor sees only means your website accepted the entry (link two); it says nothing about links three to five. That is why looking at the form alone rarely finds the cause. Before anything technical, spend ten minutes on these checks:

• Search every folder, not just the inbox. Check spam or junk, trash, archive, any “other” or promotions tab and folders created by rules. Search for the form’s subject line or a name from a known missed enquiry.
• Use webmail as well as the phone app. Some apps sync only the inbox and hide the junk folder.
• Ask the customer for details. The date and time, which page, the email address and phone number they typed, and whether they saw a confirmation.
• Look for the pattern. Everything missing since a certain date points to a change: an update, a mailbox change, a host move. Only some enquiries missing points to filtering, a nearly full mailbox or a blocked browser.
• Write down what you find. Dates and symptoms save time when you talk to your developer or host.

Confirm the address the form sends to

Every form has at least one recipient address stored somewhere: in a plugin setting, in a site builder’s form options or in the form’s code. It is usually chosen at launch and never looked at again, which makes it one of the most common causes and one of the easiest to check. Typical problems:

• A mailbox that no longer exists. It was set up for a former staff member, a designer, or an old domain that was not renewed.
• A mailbox that is full. Once a mailbox is over its storage limit, new mail can be rejected or delayed. The guide on a full business mailbox explains what counts against the limit and how to clear space.
• A typo or an address left over from a change. After a rename or a new domain, the form can keep sending to the old address. See what changes when you rebrand.
• An address nobody reads. A personal mailbox of someone who has left, or a shared address with no owner.
• An alias or forwarder. A name that only passes mail to another address adds a link that can break.

Ask whoever manages the site to show you, by screenshot or screen share, the exact recipient fields, including any copy (CC) or hidden copy (BCC) addresses. Then send a plain email from an outside account to that exact address and confirm a person received it.

Test properly: three tests that separate the causes

Guessing wastes time. A few deliberate tests tell you which link is broken. Use only your own addresses, never real customers’, and put a unique phrase in each test message, such as the date, the time and an odd word, so you can search for it.

After each test, wait about fifteen minutes and check the inbox and junk folders. Use a different provider on purpose: a message between two mailboxes on the same service can be handled internally and pass, while one arriving from the wider internet would not. If a test lands in junk, note it, because that points to the next section. If you can open the message’s full headers (often “show original” or “view source”), look for lines showing SPF, DKIM and DMARC as pass or fail, and forward them to whoever runs your email.

Is your domain’s email authenticated, and what is the From address?

When a website sends mail that appears to come from your domain, the receiving provider asks whether that server is allowed to. Three records in your domain’s DNS answer the question. SPF lists the servers allowed to send for the domain. DKIM adds a digital signature. DMARC says what to do when those checks fail and can send you reports. If the server that sends your form mail is not covered, providers may junk or reject it. Setting these records up is covered in the business email on your own domain guide, so it is not repeated here.

What matters for forms is that form mail often leaves from a different place than your normal mail, such as the web server or a plugin. A domain set up well for your mailbox can still fail for the form. Check:

• The From address. It should be an address on your own domain, with the visitor’s address placed in the Reply-To field so you can press Reply. A form that puts the visitor’s own address, say a free webmail one, in From is claiming to be that provider while sending from your server, which is exactly the pattern providers distrust.
• How the form sends. Through the server’s built-in mail function, or by logging in to a real mailbox with SMTP. Sending through a real mailbox on your domain is generally the more dependable route. Ask your developer which one you have.
• What SPF covers. Whichever service actually sends the form mail needs to be allowed. Many mail providers offer a free check tool.
• Where your mailboxes live. If your email is hosted with a different provider from your website, make sure the website’s server does not treat your domain’s mail as local. On cPanel-style panels this is the Email Routing setting. A wrong setting can make mail from the site to your own address go nowhere.

Take a copy of the current DNS records before anyone changes them. A wrong record can break all your email, not only the form.

What the form does when sending fails

This decides whether you ever find out about a problem. Ask these questions:

• Does it show “Thank you” even if the mail was not sent? Many forms do, because the message only confirms the site accepted the entry.
• Does the site keep a copy of each entry? A saved list in the dashboard or database lets you recover missed enquiries and compare against what reached your inbox. Without one, a failed email is a lost lead.
• Is there a mail log or an alert? Some setups record send errors. Others record nothing.
• Can the visitor see an error? “We could not send your message, please call or WhatsApp us” costs less than a false success.

If entries are stored, export them, find the ones you never received and reply with a short apology. If they are not stored, ask for storing to be switched on first, before any other fix.

Forwarding rules, filters and shared mailboxes

• Auto-forwarding. If the mailbox forwards to a personal address, forwarded mail is more likely to be junked there, the destination may be full, or the forward may have been switched off.
• Inbox rules. A rule written for newsletters, or one that moves messages containing words like “enquiry” or “quote”, can hide leads. Check rules in webmail and in each mail app; app rules run only while the app is open.
• Shared mailboxes and groups. Someone else may read it, mark messages as read or delete them. A group address that accepts mail only from its members will reject mail from the website.
• A company filter. A managed filter can quarantine messages. Ask for the quarantine list.
• Safe senders. Adding the form’s sender address to your contacts helps a little, but it covers up a cause rather than curing it.

Anti-spam, captcha and recent updates that stop real enquiries

Spam protection is worth having, but a rule that is too strict blocks real people without telling anyone. Watch for:

• A captcha that does not load. An ad blocker, a privacy setting or a slow mobile connection can leave the Send button doing nothing.
• A security or firewall plugin that blocks form submissions from some networks, countries or phone browsers.
• Word and link filters. Real enquiries often contain a website link, a phone number or Chinese characters, and some rules treat those as suspicious.
• Page caching. A cached form page can carry an expired security token, so entries fail after a while. The CDN guide mentions cached forms as a risk.

Then ask when it last definitely worked and list what changed around that date: a plugin, theme or core update, a rebuilt site, a PHP version change, a host move, a new email provider, a changed mailbox password or DNS edits. A password change on the mailbox the form uses for SMTP breaks sending quietly. Test updates on a staging copy first, keep a restore point from your backups, and treat updates as the routine described in why a website needs ongoing maintenance.

From “nothing arrives” to where to look next

Match what you see to the likely cause and the next place to look.

A five-minute weekly test and a backup channel

Silent failures stay silent unless someone looks. A routine takes five minutes:

1. Pick a fixed slot, such as Monday morning, and set a recurring reminder.
2. On your phone, on mobile data, submit the form with a unique phrase, using an address at a different provider.
3. Check the inbox and junk after fifteen minutes. Record the date and the result in one shared note.
4. Once a month, repeat from another browser and on the Malay and Chinese versions if your site has them.
5. Test again after every update, DNS change or email change.
6. If a test fails twice, stop and escalate using the questions below.

Keep a backup channel too, so one broken link costs fewer leads:

• A WhatsApp click-to-chat button on every page. See enquiry forms versus WhatsApp for placing it.
• A visible phone number that taps to call.
• A plain email address in text beside the form, one you have tested.
• A second recipient, such as another person or a shared mailbox with a named owner.
• A stored copy of every entry on the site.
• An error message that points visitors to these options.

What to ask whoever built or hosts your site

To the developer or agency:

• Which address or addresses does the form send to, and where is that set?
• Does it send through the server’s mail function or through a mailbox login? Which mailbox?
• Is From an address on our domain, with the visitor in Reply-To?
• Is the sending service covered by SPF, DKIM and DMARC, and can you show the test results?
• Are entries stored, where, and how do I export them?
• What does a visitor see if sending fails, and is there a log or an alert?
• What spam protection is on, and where do blocked entries go?
• What changed recently, and how are updates tested?

To the host: can you check the mail logs for my domain around the time of my test? Is the mailbox over its limit? Are there sending limits on my account? Is the domain’s email routing correct? If you are unsure who that is, see who hosts your website.

Common mistakes

• Testing from the recipient mailbox to itself. It can pass while mail from outside fails.
• Looking only in the inbox.
• Trusting the thank-you message. It proves the site accepted the entry, nothing more.
• Stacking mail plugins. A second tool on top of a broken first one makes the cause harder to find.
• Editing DNS without a copy of the current records.
• Testing once. Test again the next day and with another provider.
• Having no owner. A check nobody is responsible for does not happen.

Where Gotka Technologies fits

Email accounts are included with Gotka’s cPanel hosting: Go AI Lite includes 30 email accounts, and Go AI Plus and Go AI Pro include unlimited. Gotka offers 24/7 support, and customers can open a ticket through the client area for questions about their hosting account or mailboxes. Every web design package includes a contact enquiry form with anti-spam and a WhatsApp click-to-chat button at no extra charge. This guide is general advice: it does not say how any form on a Gotka-built site sends its mail, promises no delivery rate or response time and does not describe a form-fixing service. For background, see cPanel hosting explained, email on your phone and laptop and the first-week hosting checklist.

Key terms used in this guide

• Recipient address: the mailbox the form sends its notifications to.
• Spam or junk folder: where a provider puts mail it distrusts but does not reject.
• Bounce: an automatic message saying a message was rejected, sent to the sender address.
• SMTP: the standard way mail is sent; a form can log in to a real mailbox to use it.
• SPF, DKIM, DMARC: DNS-based checks that show a message really comes from your domain.
• From and Reply-To: the sender shown on a message and the address a reply goes to.
• Captcha: a check that tries to tell people from bots.
• Alias or forwarder: an address that passes mail on to another mailbox.
• Quarantine: a holding area where a filter keeps messages it has blocked.