Email Deliverability for Contact Forms

Your website is an email sender. Not metaphorically — the moment you added a contact form, a booking form, or an order confirmation, your site started composing and dispatching email, and it started doing so with all the credibility of a stranger claiming to be your assistant. Because that's roughly what default website email is: a web server nobody vouches for, sending messages that claim to be from your domain, with no cryptographic proof and no reputation. Mail providers have spent twenty years learning to distrust exactly this pattern.

The result is the most common silent failure in small-business web operations: the form works, the visitor sees 'Thanks, we'll be in touch!', and the notification lands in spam or nowhere at all. Nobody complains, because the people affected are precisely the ones who can't reach you. This post covers the architecture side of fixing it — how website email should be set up so delivery is reliable by design. (This article is about building the system right; a section near the end covers what to check when it still misbehaves.)

Why default website email fails

When a WordPress form plugin sends a notification, it typically calls the platform's built-in mail function, which hands the message to whatever mail capability the web server has. Three structural problems follow:

• The sending server has no reputation — or a bad one. On shared hosting, your site's email leaves from an IP address shared with hundreds of other sites. If any of them has been compromised and used for spam, the IP's reputation is damaged, and your messages inherit the damage.
• The message claims an identity it can't prove. The notification says it's from you@yourdomain.com, but nothing authorizes the web server to send as your domain. To a receiving mail system, this is indistinguishable from forgery — because technically it is the same act.
• Nobody is watching the failures. Server-level mail has no dashboard. When a message bounces or gets silently dropped, there's no log a normal human ever sees. Failure is invisible by default.

The fix has two halves: authenticate your domain so receivers can verify your mail, and route your website's email through a real mail service instead of the web server. Do both. Either alone leaves a gap.

Half one: authentication — SPF, DKIM, and DMARC in plain terms

Three DNS records let the world's mail systems verify email claiming to come from your domain. They sound intimidating and are, in practice, six lines of configuration.

SPF: the approved-senders list

SPF is a DNS record listing the servers allowed to send email for your domain. When mail arrives claiming to be from yourdomain.com, the receiver checks whether the sending server is on the list. Your SPF record needs to include every legitimate sender: your mailbox provider (Google Workspace, Microsoft 365), your newsletter tool, and — this is the piece websites miss — whatever service sends your form notifications. One rule trips people constantly: a domain gets exactly one SPF record. Multiple SPF records don't add together; they invalidate each other. New senders get merged into the existing record with an additional include, not added as a second record. There's also a limit of 10 DNS lookups within the record — busy domains with many services can exceed it, which silently breaks SPF, so prune includes for services you no longer use.

DKIM: the tamper-evident signature

DKIM cryptographically signs each outgoing message; a public key published in your DNS lets receivers verify the signature. A valid DKIM signature proves two things SPF can't: the message genuinely came from an authorized sender and wasn't altered in transit. Every reputable mail service — mailbox providers and transactional senders alike — gives you DKIM records to publish when you set them up. Publish them. Of the three records, DKIM does the most heavy lifting for inbox placement.

DMARC: the policy and the feedback loop

DMARC ties the first two together: it tells receivers what to do with mail that fails SPF and DKIM checks (nothing, quarantine it, or reject it) and — underrated — asks them to send you reports about who is sending mail as your domain. Start with a monitoring-only policy (p=none) with a reporting address, watch the reports for a few weeks to catch legitimate senders you forgot about, then tighten to quarantine. Since the major mailbox providers began requiring DMARC for bulk senders, having no DMARC record at all has become an active deliverability penalty rather than a neutral omission. A minimal record is one line of DNS and lifts you out of the worst-treated category immediately.

Half two: routing — get email off the web server

Authentication tells receivers your mail is legitimate; routing determines whether it leaves from an IP anyone trusts. The universal fix is an SMTP plugin (WP Mail SMTP, FluentSMTP, Post SMTP and similar) that intercepts everything your site tries to send and delivers it through a proper mail service instead of the server. Your realistic options for what that service is:

For a typical small-business site sending a handful of notifications a day, a transactional service's free tier is the sweet spot: dedicated sending infrastructure, proper DKIM signing under your domain, and — crucially — a log. The dashboard showing sent/delivered/bounced per message converts email from a faith-based system into an observable one. When someone says 'I never got the confirmation', you look it up instead of shrugging.

Form configuration: the settings that sabotage you

With authentication and routing done, three form-level settings still commonly break delivery:

Never send 'from' the visitor's address

Many form plugins default to putting the visitor's email in the From field, so the notification appears to come from jane@gmail.com. This guarantees failure at any receiver checking DMARC: your server isn't authorized to send as gmail.com, and Gmail's own policy says to reject such mail. The correct pattern: From is always an address on your own domain (forms@yourdomain.com), and the visitor's address goes in Reply-To — so hitting reply still reaches them. This one setting fixes more form email problems than any other.

Send the notification somewhere it can't loop

Sending mail from yourdomain.com to yourdomain.com, through a third-party service, occasionally trips filters at your own mailbox provider. If notifications to your main address behave oddly, test with an external address to isolate the problem — and consider having notifications go to a dedicated address you check or forward, so form mail is easy to filter, search, and audit.

Add a second channel for forms that matter

Email is the primary channel, not the only one. Any decent form plugin stores submissions in the database — turn that on and treat it as the source of truth. For high-stakes forms (quote requests, bookings), add a webhook or integration that also pushes submissions to Slack, a spreadsheet, or your CRM. When email hiccups — and some day it will — the lead still lands somewhere a human sees it.

Verify it works, then keep verifying

Setup isn't done until you've tested it the way a stranger would encounter it:

1. Run one message through a checker. Send a form notification to a testing service like mail-tester and confirm SPF, DKIM, and DMARC all pass, and the score isn't dragged down by something unexpected. Ten minutes, once.
2. Test to the providers your customers use. Submit the form and check receipt at a Gmail address, an Outlook address, and your own domain. Inbox, not spam folder, on all three.
3. Schedule a monthly form check. A calendar recurrence: submit each important form, confirm arrival. Deliverability decays silently — a plugin update resets a From setting, an SPF include gets dropped during a DNS change, an API key expires. Three minutes a month catches all of it.
4. Skim the sending dashboard. If you used a transactional service, glance at the delivered/bounced counts when you do the monthly check. A sudden bounce spike is the early warning you otherwise never get.

When the basics are right and form email still misbehaves

Even with authentication and routing in place, a few other things can still push form notifications into spam or lose them. Work through them in this order, and read the message itself before you change anything: in Gmail, open the spam-folder message and choose "Show original" (in Outlook, view the message source). Near the top you will find the SPF, DKIM and DMARC verdicts, each marked pass or fail. If one of them fails, go back to the half of this article that covers it. If all three pass, look at the following.

• Spam-shaped content. Form notifications are short, template-generated and contain whatever the visitor typed, which, if the visitor was a bot, is literal spam. A form with no anti-bot protection delivers casino links to your inbox under your own domain's name and teaches filters to distrust the whole stream. Add a modern invisible check (Turnstile, reCAPTCHA or a honeypot field) so the spam-shaped traffic stops.
• A subject line that never varies. Hundreds of identical "New Form Submission" messages look automated because they are. Make the subject informative, for example "Quote request from the visitor's name", which also makes your inbox easier to search.
• A young domain. A brand-new domain has no sending history and filters are cautious with it. This tends to resolve itself over weeks of normal, authenticated sending, so do not over-correct.
• Your own filter rules. Sometimes the culprit is a forgotten rule in your own mailbox or a policy at your mail provider. Check your mailbox's filter list before re-architecting anything.
• A lesson you taught the filter. If anyone ever marked a form notification as spam, perhaps during a bot wave, your provider learned it. Dig those messages out of the spam folder and mark them as not spam; with authentication passing, the correction usually sticks.

If the email does not arrive anywhere, not even in spam, you have a sending failure rather than a filtering one. Check the SMTP plugin's email log first: "authentication failed" points to an expired key or changed password, and no entries at all suggest another plugin or a misconfiguration is intercepting the mail. Then check the recipient address, because notifications sometimes keep going to a previous owner's address or to a mailbox that no longer exists. Finally, if your mail service's dashboard shows the send but marks it as bounced, the bounce reason says why, and it usually circles back to authentication or the From field.

The honest conclusion

Email deliverability has a reputation for being dark magic, and for high-volume newsletter senders fighting for inbox placement, some of that reputation is earned. For a website sending form notifications, it isn't magic at all — it's four concrete tasks: publish SPF, DKIM, and a basic DMARC record; route site email through a real mail service via an SMTP plugin; fix the From/Reply-To pattern; and store submissions as a backstop. An afternoon of setup, a monthly three-minute check, and the most valuable messages your website produces — the ones from people trying to give you money — stop depending on luck.

Photo: RDNE Stock project on Pexels