Part of the guide From inquiry to record in the UAE, without copy-paste
Key takeaways
- A thank-you message after sending only proves the form ran, not that anyone received the enquiry.
- The notification address is often set once at launch and never checked again.
- Forms that send as the visitor's own address fail sender checks and end up in spam or nowhere.
- Many web servers are not allowed to send mail for your domain unless you configure it.
- A weekly test enquiry and a second copy of every submission make losses visible.
Where do enquiries from a UAE website get lost?
Say a visitor finds a Dubai real estate agency and fills in the enquiry form. They press send. The page says "Thank you, we will be in touch." Nobody ever is. They call a competitor instead. The agency never learns that the enquiry existed.
This is one of the most expensive faults a UAE company website can have, and one of the quietest. The form looks fine, the confirmation looks fine, and the missing enquiry leaves no trace. Most help articles on the topic are plugin troubleshooting guides. This one is for the owner who wants to know where to look, and why the thank-you message proves less than it seems. It belongs to our series on what happens between a form and a reply.
Why does the thank-you message prove nothing?
The confirmation only tells you that the form's own code ran. Whether an email left the server, and whether it reached a person, are two separate questions.
WordPress is explicit about this. Its documentation for the function most forms use to send mail says that a true return value does not automatically mean that the user received the email. The form reports success when the message was handed over, not when it was delivered. Everything after that point can fail silently. The opposite case is at least honest: a red message such as `There was an error trying to send your message` tells you the form is not sending emails at all, and someone will usually report it. The silent success is the one that costs enquiries.
Who actually receives the notification?
Start with the simplest question: which address does the form send to? Open the form's settings and find the recipient field. It is often called "To" or "Notification email".
In practice the answer is surprising more often than it should be. The address was set by the developer on launch day. It points to the developer's own test mailbox, or to a colleague who left last year, or to an `info@` inbox that three people can read and nobody owns. Say a trading company in Sharjah changed its sales team and closed the old mailboxes. The form still sends to one of them, and the mail server rejects every notification. No one on the current team has ever seen one.
The fix takes a minute: send notifications to a mailbox a named person reads every day, and add a second recipient, so one absence does not stop the flow.
Does the notification come from your own domain?
Many forms are set up to send the notification "from" the visitor, using whatever address they typed in. It feels natural, because you can hit reply. To a receiving mail server it looks like forgery: your web server claims to send mail as `someone@gmail.com`, and it is not allowed to.
SPF (RFC 7208) and DMARC (RFC 7489) exist to catch exactly that. A message that fails them goes to spam or is rejected, and Google's sender guidelines make authentication a requirement for delivery to Gmail. The Contact Form 7 documentation puts the rule plainly: in the From field, use an email address that belongs to the same domain as the site.
What that looks like in a form's mail settings: `From: Website <website@yourcompany.ae>` with `Reply-To: [visitor-email]`. The notification comes from you, passes the checks, and the reply button still reaches the visitor.
Is the web server allowed to send mail at all?
Even with the right sender address, the message has to leave from a server your domain trusts. By default many sites hand mail to the web server's own mail function. That server is usually not listed in your SPF record, and some hosts block or throttle it outright.
For example, a clinic moves its site to a cheaper host. On the old host, form mail happened to work. On the new one, outgoing mail from the web server is not permitted, and every notification since the move has been dropped. The site itself works perfectly, so nobody suspects anything. The reliable setup is to send form mail through your actual mail provider with a login (SMTP), the same way a person's mailbox does. Our guide to business email for a new UAE company covers the records that make this pass.
How would anyone notice that enquiries are missing?
This is the real gap. Every fault above is invisible from the website and from the inbox. You only notice the absence of something, and absence is hard to see.
Two habits close it. First, a test enquiry every week from an outside address, with a subject like `Form test, please ignore, Monday`, checked by the person who owns the mailbox. If it does not arrive, you know within days, not months. Second, never let email be the only copy. Store every submission as well: in the form tool's own entries, or better, directly as a record in the CRM, so an enquiry exists even when the notification fails. That is the step our guide from inquiry to record describes, and the one that turns a form into a process.
If you would like someone to trace the whole path on your own site, from the form through mail delivery to the record, see our services.
Michael Wagner's take
Contact Forms are one of the most important points of interaction with your customers. Having them work flawless and reliable is crucial for everbusiness and unfortunately often overlooked.
Written by
Founder and Lead Engineer, Orentara
Michael Wagner founded Orentara and builds its websites and automations himself. An engineer by training, he has spent his career connecting websites, databases and business processes, and now focuses on automating compliance work under the GDPR, AML rules and the UAE PDPL.
