← All guides

Why Church Website Contact Form Submissions Never Arrive in Your Inbox

A visitor fills out your "Get in Touch" or "Prayer Request" form, sees the green checkmark that says the message was sent, and you never see it. No email, no notification, nothing in spam. If this has happened more than once, the problem almost certainly isn't the visitor and it isn't your form plugin being buggy. It's how the form is sending mail, and it's fixable in about 20 minutes once you know where to look. This happens constantly to churches because most church sites run on WordPress with a free contact form plugin (Contact Form 7, WPForms, Ninja Forms) installed by a volunteer, on shared hosting, with no one ever configuring how outbound mail actually gets delivered. The form works. The delivery doesn't.

The #1 cause: your form is using PHP's mail() function, not real email

By default, most WordPress contact form plugins send notification emails using PHP's built-in mail() function. This function hands your message to whatever mail transfer agent is installed on your web hosting server and asks it to deliver it — with no authentication, no SPF record backing it, and often no DKIM signature at all.

Gmail, Outlook, and Yahoo treat unauthenticated mail from a random hosting server IP as a strong spam signal, because it's exactly what spammers do. On shared hosting, that server IP is also used by hundreds of other websites, some of which are almost certainly sending spam right now, which drags down the reputation of every site on that server — including yours.

The result: the plugin reports "message sent successfully" (because PHP mail() did hand it off), but the receiving mail server silently discards it or routes it straight to spam before it ever reaches your notification address. This is the single most common reason a church's contact form "sends" but nothing ever shows up.

Fix it: route form mail through real SMTP, not PHP mail()

The fix is to stop using your host's PHP mail() and instead have your form plugin authenticate and send through a real mail provider using SMTP. If your church already uses Google Workspace or Microsoft 365 for email, you can send through that same account. If not, a transactional email service (SendGrid, Postmark, Brevo) has a generous free tier that's more than enough for contact form volume.

Install a free plugin like WP Mail SMTP or Post SMTP, connect it to your Google Workspace, Microsoft 365, or SMTP provider account, and send a real test email through the plugin's built-in tester. This one change fixes the majority of "our contact form doesn't work" reports, because the mail is now leaving from an authenticated, reputable source instead of an anonymous hosting server.

Do this before touching anything else on this page — it's the highest-impact single fix, and every other section below assumes you've already moved off PHP mail().

Missing or broken SPF, DKIM, and DMARC records

Even after you switch to SMTP, mail can still get rejected or spam-foldered if your domain's DNS doesn't authorize the sending server. SPF (Sender Policy Framework) is a DNS TXT record listing which mail servers are allowed to send as your domain. DKIM is a cryptographic signature proving the message wasn't altered in transit. DMARC tells receiving servers what to do if SPF or DKIM fails.

If your church's domain has no SPF record at all, or has one that only authorizes your old host and not your current SMTP provider, mail sent "from" your domain gets flagged as likely spoofed — because technically it looks exactly like spoofing. This is especially common after a church switches web hosts, changes form plugins, or migrates email providers and nobody updates the SPF record to match.

You can check your domain's current records for free at mail-tester.com or with the switchmyemail.com free email checker — both will tell you in plain language whether SPF, DKIM, and DMARC are present and correctly configured, and exactly what's missing.

The "From" address doesn't match the sending domain

A subtler version of the same problem: many form plugins default to sending the notification "From" the visitor's own email address (so a reply goes straight to them), or from a generic no-reply@yourchurch.org address that was never set up. When the From address claims to be your domain but the actual sending server has no authorization for that domain (see the SPF issue above), Gmail and Outlook penalize it hard — sometimes rejecting it outright rather than just spam-foldering it.

The safest pattern: set the form's From address to an address on a domain you control and that IS authenticated (your Google Workspace or Microsoft 365 address), and put the visitor's email in the Reply-To field instead. Most modern form plugins have separate From and Reply-To settings specifically for this reason — check your plugin's email settings tab, not just the notification recipient field.

Spam and promotions folder filtering

If mail IS arriving but nobody's finding it, check the spam and promotions folders on the receiving account before assuming delivery failed entirely. Gmail's Promotions tab in particular will sometimes catch automated notification emails that contain a lot of form-field-style formatting, even when delivery technically succeeded.

Ask whoever monitors the contact form inbox to search for the exact subject line your form plugin uses (often something like "New Contact Form Submission") across all folders, not just the inbox. If you find it in spam, mark it "not spam" and add the sending address to contacts — but treat this as a temporary workaround, not a fix. The underlying SPF/DKIM/SMTP issues above are what actually stop it from landing in spam in the first place.

Notifications are going to an inbox no one checks

This sounds almost too simple to mention, but it's a frequent finding: the contact form is configured to notify an address like webmaster@yourchurch.org or the personal Gmail of a volunteer who left two years ago, while the office staff is checking a completely different inbox. Nobody notices because there's no error — the mail is delivering exactly where it was told to.

Open your form plugin's settings and confirm the notification recipient is a current, actively-monitored address — ideally a shared staff or ministry inbox rather than one person's individual account, so submissions don't get missed during vacations or staff turnover. While you're in there, check whether the form has a second "confirmation" email option for the visitor — if that's also misconfigured, visitors get no acknowledgment either, which erodes trust in the form.

How to actually test that your fix worked

Don't just submit the form once and check your inbox — that tells you it worked once, under ideal conditions. Submit a real test through the live form (not the plugin's internal preview), then check: did it arrive within 2 minutes, in the primary inbox, not spam? Second, send yourself an email using mail-tester.com's unique test address and confirm you score at least 8/10, which validates SPF, DKIM, and DMARC together rather than one at a time.

If you have technical help available, ask them to check the server's mail log (often /var/log/maillog or accessible through your host's control panel) for the timestamp of your test submission — it will show whether the message was accepted for delivery, deferred, or rejected outright, which tells you exactly where in the chain it's failing.

Repeat this test after any hosting change, plugin update, or email provider switch. Mail delivery isn't a "set it once" thing — a hosting migration or plugin update can silently revert your SMTP settings back to PHP mail() defaults.

Check my church's email — free →

Frequently asked questions

Why does my church's contact form say "message sent" but I never receive it?

The plugin is almost certainly using PHP's mail() function, which hands your message to your web host's mail server with no authentication. The plugin honestly reports success because the handoff worked — but the receiving email provider silently drops or spam-filters it because it looks unauthenticated. Switching the plugin to send via real SMTP (your Google Workspace, Microsoft 365, or a transactional email provider) usually fixes this immediately.

How do I check if my church domain's SPF and DKIM records are set up correctly?

Use a free tool like mail-tester.com or the switchmyemail.com email checker. Both scan your domain's DNS in seconds and tell you plainly whether SPF, DKIM, and DMARC exist and are correctly authorizing your actual sending server — no technical background required to read the results.

Should our contact form email the volunteer who set it up, or a shared church inbox?

A shared, actively-monitored staff or ministry inbox is much safer than an individual's personal address. Individual addresses get missed during vacations, job changes, or when a volunteer's role changes, and there's no error message when a notification quietly goes nowhere anyone is checking.

We switched web hosts recently — could that be why form emails stopped arriving?

Yes, this is one of the most common triggers. A new host often means a different outgoing mail server, and if your domain's SPF record still only authorizes the old host, mail sent from the new one fails authentication and gets rejected or spam-filtered. Update your SPF record to include the new sending source any time you change hosting or email/SMTP providers.

Is it enough to just mark the form emails as "not spam" in Gmail?

That's a short-term workaround for one recipient, not a fix. It doesn't help the next visitor whose form submission also gets filtered, and it doesn't address the underlying cause — usually missing SPF/DKIM authentication or PHP mail() being used instead of SMTP. Fix the sending configuration so mail is properly authenticated for everyone, not just re-trained for one inbox.