A quiet contact form is easy to explain away. It’s winter, it’s school holidays, the economy’s soft. Sometimes that’s true. But often enough to be worth checking, the enquiries are arriving on the website just fine and then quietly failing to reach your inbox. We’ve seen businesses go months without noticing, until a customer rings to ask why nobody replied.
The same problem hits WooCommerce order confirmations, booking notifications and password reset emails. The cause is almost always the same, and so is the fix.
Why WordPress email fails by default
Out of the box, WordPress sends email using PHP’s built-in mail function. That means your web server sends the message itself, directly, with very little proof that it’s allowed to.
From the receiving end (Gmail, Outlook, your own email provider), that message looks suspicious. It claims to be from you@yourbusiness.com.au, but it came from a web server that your domain’s email settings know nothing about. It may be a shared server that also sends mail for hundreds of other sites, some of them spammy. So the receiving server does what it’s built to do: sends it to spam, or drops it without telling anyone.
A few things make it worse:
- The “from” address doesn’t match the domain. A form set to send “from” the customer’s Gmail address is almost guaranteed to fail, because your server isn’t allowed to send as Gmail.
- Your email is hosted somewhere else. If your email runs on Microsoft 365 or Google Workspace and the website is on separate hosting, the web server is an outsider to your own domain.
- Some hosts limit or block PHP mail entirely to stop spam, and don’t always tell you.
- Email providers have tightened up. Google’s email sender guidelines require anyone sending to Gmail accounts to authenticate with SPF or DKIM, and bulk senders need both plus DMARC. Unauthenticated mail from web servers is exactly what those rules are designed to catch.
The fix: send through a proper mail service
The reliable solution is to stop the web server sending mail itself and route it through a service that’s set up and authorised to send for your domain. On WordPress, that’s done with an SMTP plugin.
There are two main ways to do it.
Your own mailbox’s SMTP. You connect the site to the email account you already have (Microsoft 365, Google Workspace, or your host’s email) and the site sends as that account. This works for low volumes, but these services aren’t designed for website mail, can have sending limits, and connections sometimes break when passwords change or security settings are tightened.
A transactional email service. Services like Postmark, Brevo, Mailgun, Amazon SES or SMTP2GO exist specifically to send automated emails from websites and apps. You verify your domain with them, they give you DNS records to add, and the SMTP plugin sends through them, usually using an API key rather than a password. This is what we prefer for most business sites, because it’s more reliable and gives you a log of every message.
Whichever route you take, look for an SMTP plugin that keeps an email log. Being able to see “this enquiry was sent at 10:42am and accepted by the mail service” ends a lot of arguments about whether the website is working.
SPF, DKIM and DMARC in plain English
These are three DNS records that prove email claiming to be from your domain really is. You don’t need to understand the technical detail, but it helps to know what each one does.
SPF: the guest list
SPF is a list of servers allowed to send email for your domain. When a message arrives claiming to be from you, the receiving server checks whether it came from somewhere on the list.
It’s a single TXT record on your domain. A typical one for a business on Google Workspace that also sends website mail through a transactional service might look like:
v=spf1 include:_spf.google.com include:spf.yourmailservice.com ~all
Two common mistakes. Having two separate SPF records (you can only have one, so everything must be combined into a single record). And adding so many services that the record goes over the limit of 10 DNS lookups, which makes the whole thing fail.
DKIM: the signature
DKIM adds a digital signature to each email. The sending service signs the message with a private key, and publishes a matching public key in your DNS. The receiving server checks the signature against the key, which proves the message came from an authorised sender and wasn’t altered on the way.
Each service that sends for you (your mailbox provider, your transactional service, the newsletter tool behind your email marketing) gives you its own DKIM record to add. They don’t conflict.
DMARC: the instructions
DMARC tells receiving servers what to do with mail that fails SPF and DKIM checks, and where to send reports about it. It also checks that the domain in the visible “from” address matches the domain that passed SPF or DKIM, which is what stops someone spoofing your address.
A sensible starting point is a monitoring-only policy:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourbusiness.com.au
That doesn’t block anything yet. It just starts reports flowing so you can see who’s sending as your domain. Once everything legitimate is passing, you can tighten the policy to quarantine or reject.
How to test it properly
Once the SMTP plugin is set up and the DNS records are in, test from the outside, the way a customer would.
- Use the plugin’s test email. Send one to a Gmail address and one to an Outlook or Hotmail address. If either fails, the plugin’s error message usually says why.
- Submit your real contact form, logged out, in a private browser window, using a different email address from your own. Then check it arrives in the inbox, not spam.
- Check the headers. In Gmail, open the test email, click the three dots and choose Show original. You’ll see SPF, DKIM and DMARC listed with PASS or FAIL beside each one. You want three passes.
- Check the email log in the plugin to confirm the message was handed over successfully.
- Test everything that sends email, not just the contact form: order confirmations, booking notifications, password resets, new user emails.
- Repeat after changes. Moving hosts, changing email providers or adding a new marketing tool can all break things. Retest every time.
Form settings that cause trouble
Even with SMTP working, a few form settings cause problems. If you use Elementor Forms (or any form plugin), check the following, and see Elementor Forms setup for the full walkthrough.
- From address: always an address on your own domain, such as website@yourbusiness.com.au. Never the customer’s email.
- Reply-to: set this to the customer’s email field. That way hitting reply goes to them, without pretending the email came from them.
- Recipients: send to an address that’s actually monitored, ideally a shared inbox rather than one person’s.
- Store submissions: keep a copy in the WordPress database too, so if an email ever goes missing the enquiry isn’t lost.
One more trap: staging sites. A copy of your live site can send real emails to real customers (order updates, reminders, newsletter confirmations) if mail isn’t switched off on it. Any staging setup worth using blocks or captures outgoing email, which is one of the things covered in WordPress staging sites explained.
Check yours today
Submit your own contact form now, from your phone, with your personal email address. If it doesn’t arrive within a couple of minutes, or lands in spam, you’ve found a leak that’s been costing you enquiries.
SMTP, SPF, DKIM and DMARC are everyday work in our business email and IT setup service, and we manage DNS and email for a lot of local businesses. Tracing a missing enquiry means checking the SMTP setup and the DNS records behind it, so if your own test didn’t arrive, tell us which address it was meant to reach.