Skip to content

Websites

Two hundred people read the services page last month and the phone did not ring. Contact forms fail silently: where the messages go, the three DNS records that decide the spam folder, and how to test a form properly once a month.

Oluwafemi Joseph Faleye5 minute readUpdated
ShareLinkedInXWhatsApp
The Enquiries Your Website Is Quietly Losing

A business tells us the website brings in nothing. The traffic report says two hundred people read the services page last month, and eleven of them opened the contact page. Somewhere between those two facts the messages are going missing, and the usual explanation is not that the market is slow.

Four ways a message disappears

  • It was never sent. The form shows a thank-you message written by the front end, and the send failed behind it. The visitor believes they made contact. Nothing happened at all.

  • It was sent and filed as spam, because the site sends mail claiming to come from your domain and nothing published in your domain records says it is allowed to.

  • It arrived at an address nobody reads. An info@ address set up during the build, forwarded to a person who left two years ago.

  • It arrived, and the reply took four days. The enquiry was real, the visitor was comparing three businesses, and the other two answered on the same afternoon.

Only the last one is a business problem. The other three are faults, and they are all invisible from the inside, which is why they can run for a year.

Test it rather than assuming it

  1. Send a real enquiry from an address outside the business, from a phone, on mobile data. Not from the office machine and not while signed into anything.

  2. Check the inbox. Then check the spam folder. Then send a second one to an address on a different provider, because a message that arrives at one provider can be filtered by another.

  3. Time the reply. Whatever number comes out of that is the number the business is actually running, regardless of the one in the policy.

  4. Repeat it on the first of every month. Forms break silently after an update, a plugin change or a password rotation on a mail account, and nobody finds out from the outside.

The three records that decide the spam folder

Mail sent by a website is mail sent on behalf of your domain by a machine that is not your mail server. Receiving servers decide what to do with that using three records published in DNS.

SPF lists the servers allowed to send as your domain. DKIM signs each message with a key so it can be verified as unaltered. DMARC says what should happen to mail that fails either check, and asks for a report telling you how much of that there is.

Finding out what is published today takes two commands.

Bash
# SPF, which lives on the domain itself
dig +short TXT example.com

# DMARC, which lives on a subdomain
dig +short TXT _dmarc.example.com

A domain with no SPF record returns nothing at all, which is the common case and the one that fills spam folders. A working record names every service allowed to send and ends in -all, along the lines of v=spf1 include:_spf.google.com include:sendgrid.net -all. Keep it to a single record, since two SPF records on one domain fail both.

DKIM is a key your mail provider generates and hands you as a record to copy in, so there is nothing to invent there. DMARC starts at v=DMARC1; p=none; rua=mailto:dmarc@example.com, which changes no delivery and starts the reports arriving. Read a fortnight of them, fix whatever legitimate mail is failing, then move the policy to quarantine. Doing it in the other order is how a business stops its own invoices being delivered.

One more thing that costs nothing: send the notification from an address at your own domain, and put the visitor's address in the reply-to field rather than the from field. Mail claiming to be from a stranger's Gmail account, sent by your server, is the exact shape of a forgery.

Store the enquiry, do not only email it

Email is a notification. It is not a record. A form should write the enquiry to a database first and send the notification second, so a failed send costs you the alert rather than the customer.

It also changes what the business can see. How many enquiries came in last month, which page they came from, how many are still unanswered, and how long a reply took on average. None of that can be answered by searching a mailbox, and all of it is ordinary once the enquiries live somewhere.

The form itself

  • Fewer fields. Every extra one costs completions, and most of what you want to know can be asked in the reply.

  • Labels above the fields, not placeholder text that vanishes the moment somebody starts typing and cannot be checked before sending.

  • Errors shown on the field that is wrong, in words, as the person leaves the field. Not a red banner at the top after everything has been cleared.

  • A confirmation that says what happens next and by when, and repeats the address it was sent to.

  • A phone number and an email address on the same page. Some people will never use a form, and they are frequently the ones ready to buy.

Keep the spam defence invisible where you can. A puzzle that takes four attempts on a phone stops as many customers as robots, and the businesses with the strictest checks tend to be the ones with the fewest enquiries.

Speed of reply is part of the build

State a reply time you can keep and then keep it. Ours is one to two working days, which is written on the contact page because a stated time that is honoured is worth more than a faster one that is not.

Every site we build stores enquiries in an inbox in the admin as well as sending the email, for the reasons above. That is part of what the web development page describes. If your form has not been tested since the day it launched, send us the address and we will put a test enquiry through it and tell you where it ended up.

Filed under

ShareLinkedInXWhatsApp

Get the next one by email

What we have built, what we learned building it, and news from the Event Space. A few times a month, and one click to stop.

Have a project that looks like this one?

Tell us what the system or the site has to do and who uses it. We will come back with questions first and a schedule and a figure after, usually within one to two working days.