If your church's newsletters, giving receipts, or pastoral emails keep landing in members' spam folders, you're not alone — and it's rarely your writing style. Most churches run their email on shared cPanel hosting through providers like GoDaddy, Bluehost, or a local web host, and shared hosting is one of the most common causes of poor email deliverability. You're sharing an IP address with hundreds of other domains, and if even a handful of them are sending spam, your reputation takes the hit along with theirs. The good news: several causes are fixable in under an hour with the right DNS changes. Others — namely, a burned shared IP — can't be fixed from your end at all, no matter how perfect your configuration is. This guide walks through both: what you can repair yourself on cPanel, and how to tell when it's time to move your church's email off shared hosting entirely.
SPF (Sender Policy Framework) tells receiving mail servers which servers are allowed to send email for your domain. If your church's domain doesn't have an SPF record, or has one that doesn't include your cPanel mail server, Gmail and Outlook will treat your outgoing mail with suspicion by default.
In cPanel, go to Email Deliverability under the Email section. cPanel will scan your domain's DNS and tell you exactly what's missing or misconfigured — this is the fastest way to diagnose the problem without guessing. A typical fix looks like adding or correcting a TXT record such as: v=spf1 +a +mx +ip4:YOUR_SERVER_IP ~all
The most common mistake we see on church sites: an old SPF record from a previous host or a bulk-email tool (like Mailchimp or Constant Contact) that was never merged with the hosting provider's SPF include. You can only have one SPF record per domain — if you have two, mail servers will often reject your mail outright, which is worse than a soft spam flag.
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to your outgoing mail that proves it wasn't altered in transit and really came from your domain. Without it, your emails look more forgeable to spam filters — and forgeable email is exactly what phishing looks like.
cPanel's Email Deliverability tool generates and installs a DKIM key automatically if one isn't present. After installing it, send a test email to check-auth@verifier.port25.com or use mail-tester.com — both will tell you within seconds whether DKIM is passing, and mail-tester.com gives you a 1-10 deliverability score with specific fixes.
One church-specific gotcha: if you use a giving platform (Tithe.ly, Pushpay, Planning Center) or an email newsletter tool to send on your domain's behalf, those services need their own DKIM setup through their dashboard, separate from cPanel's. Sending through a third-party tool without its DKIM configured is one of the most common reasons a church's giving receipts or newsletters get flagged even when the main church domain looks clean.
DMARC ties SPF and DKIM together and tells receiving servers what to do if a message fails both checks — reject it, quarantine it, or let it through. Most churches have no DMARC record at all, which is a missed signal: mailbox providers increasingly treat the absence of DMARC as a mild trust penalty, and as of 2024 Gmail and Yahoo require DMARC for any domain sending meaningful volume to their users.
Start conservative. Add a TXT record at _dmarc.yourchurch.org with a policy of none so you can monitor without risking legitimate mail getting blocked: v=DMARC1; p=none; rua=mailto:you@yourchurch.org
This sends you a daily report of who's sending mail as your domain — legitimate services and any spoofing attempts. After a few weeks of clean reports, you can tighten the policy to p=quarantine, which is the setting most mailbox providers respond well to.
This is the one most church volunteers running their own hosting never think to check, and it's entirely on your host to fix — you can't do it yourself in cPanel. A PTR record is the reverse of a normal DNS record: it maps your server's IP address back to a hostname. Many spam filters, particularly at Microsoft/Outlook, will flag or reject mail from an IP with no PTR record or a mismatched one.
To check it, use a tool like mxtoolbox.com/ReverseLookup and enter your server's outgoing mail IP (found in cPanel under Email Deliverability, or ask your host). If it comes back missing or shows a generic hostname unrelated to your domain, open a support ticket with your hosting provider — this has to be set at the server/network level, not in your domain's DNS zone.
This is the issue that no amount of SPF/DKIM/DMARC tuning will solve, and it's extremely common on budget shared cPanel hosting. Because dozens or hundreds of unrelated websites share your server's outgoing mail IP, if any one of them gets compromised and starts sending spam, your entire IP gets added to blacklists — and your church's perfectly-configured emails get caught in the crossfire.
Check your server's IP at mxtoolbox.com/blacklists (free, takes 30 seconds). If you show up on Spamhaus, Barracuda, or SORBS, that's very likely your real problem, not your configuration. You can request delisting from most blacklist operators once the underlying spam source is cleaned up, but on shared hosting that's out of your control — another tenant on the same server can get you re-blacklisted again within weeks.
This is the point where most churches realize the ceiling isn't a setting, it's the hosting model itself. Shared cPanel hosting was built for websites, and email was bolted on as an afterthought — you're inheriting the reputation of everyone else on that server.
Spam filters watch for sudden bursts of outgoing mail — exactly the pattern a church creates when it blasts a Sunday announcement or a stewardship campaign to 400 people at once from a shared server with limited sending reputation. If your host caps hourly sends (cPanel's default is often 500/hour, but shared hosts frequently set it much lower), hitting that ceiling repeatedly is itself a spam signal.
Prune your list before every send. Bounced addresses, addresses that haven't opened anything in a year, and role addresses (info@, office@) that never engage all drag down your sender reputation with every campaign. If you're sending to more than roughly 100-150 people at once, consider spacing sends or switching to a tool designed for bulk church communication rather than routing it all through a general-purpose hosting mailbox.
If you've corrected SPF, DKIM, DMARC, and PTR, and your church is still landing in spam, the honest diagnosis is usually a burned shared IP or a hosting provider that simply doesn't invest in mail infrastructure. This is common enough on budget church hosting that it's worth checking before spending more volunteer hours on DNS records.
Google Workspace sends from Google's own IP ranges, which carry enormous sending reputation because of the volume of legitimate mail across all of Google's customers — a level of trust no shared cPanel host can replicate. Migrating your church's mail to Google Workspace (Gmail, Calendar, Docs) removes the shared-IP problem permanently and typically resolves spam-folder issues within days of the switch, once SPF/DKIM/DMARC are set up correctly on the new platform.
The migration itself is the part most churches put off, understandably — moving mailboxes, historical email, and calendars without losing anything or causing downtime for staff and volunteers takes careful sequencing. That's the exact gap SwitchMyEmail closes: we handle the technical migration end-to-end so your church's inbox moves cleanly to Google Workspace with nothing lost and no Sunday-morning surprises.
Get a free church email deliverability audit →Each mailbox provider weighs SPF, DKIM, DMARC, and IP reputation differently and maintains its own blacklists. It's common to pass at one provider and fail at another. Check mail-tester.com for an overall score, then check mxtoolbox.com/blacklists specifically for Spamhaus and Barracuda, which Outlook/Microsoft weighs heavily.
No — a shared IP is controlled by your hosting provider, not by your cPanel account. You can request delisting through the blacklist operator, but if the underlying cause is another tenant on the same server, it can recur. This is the main reason churches on budget shared hosting eventually move to a platform with a dedicated, high-reputation sending infrastructure like Google Workspace.
Adding SPF or DKIM incorrectly (like having two SPF records) can cause legitimate mail to be rejected, so always use cPanel's Email Deliverability tool to verify the syntax rather than typing records by hand. Start DMARC at p=none, which only monitors and reports — it won't block or quarantine anything until you deliberately tighten the policy.
SPF, DKIM, and DMARC changes typically propagate and take effect within a few hours, and you can verify with mail-tester.com immediately after. If the root cause is a blacklisted shared IP, resolution can take days to weeks and depends entirely on your host's action — which is outside your control.
Deliverability is often the trigger, but Google Workspace also gives your church a professional @yourchurch.org address with Gmail's spam filtering working in your favor instead of against you, shared calendars for staff and ministry teams, and reliable storage via Google Drive — all for a predictable per-user monthly cost instead of unpredictable shared-hosting mail issues.