Gmail and Yahoo's Bulk Sender Rules: What They Mean for Your Church's Email
If your church emails more than about 500 people a day — a Sunday recap, a prayer list, a giving reminder — Gmail and Yahoo now treat you the same way they treat a marketing company. Since these rules took effect, mailbox providers have been quietly filtering or rejecting mail from senders who don't meet a specific technical bar, and "we're a nonprofit" doesn't get you an exemption. Most churches find out the hard way: attendance emails stop landing, a giving campaign gets almost no opens, and nobody can explain why. It's almost never the content. It's SPF, DKIM, and DMARC — three DNS records that tell Gmail and Yahoo your church's domain is really who it says it is. Here's exactly what's required, why it trips up churches specifically, and how to fix it.
What Gmail and Yahoo actually require now
Both providers enforce the same core checklist for anyone sending a meaningful volume of mail to their users, and the threshold that matters for most churches is 5,000 messages to Gmail addresses in a single day — but in practice, the failure mode (temporary blocks, mail routed to spam) shows up well below that if your authentication is weak, because volume and reputation interact.
The requirements: a published SPF record that lists everything authorized to send as your domain, a valid DKIM signature on every message, and a DMARC record at your domain's root (even a permissive p=none policy counts, but it must exist and align with SPF or DKIM). On top of that, any message with an unsubscribe link — which includes most bulk congregational email — needs one-click unsubscribe (RFC 8058) support, and your complaint rate has to stay under 0.3%, checked through Google Postmaster Tools.
What changed practically for churches: before this, a lot of church management systems (Planning Center, Breeze, Mailchimp for nonprofits) sent on your behalf using their own infrastructure with only partial authentication passed through. Since enforcement began, mail that fails alignment doesn't get a warning — it gets silently routed to spam or rejected outright, and there's no appeal form that fixes a missing DNS record.
Why churches hit this harder than most senders
Three things make churches disproportionately likely to fail these checks, and none of them are about being small.
First, many churches use two or three tools that all send "from" the church's domain — the ChMS for weekly updates, a separate giving platform for donation receipts, and a volunteer's Gmail account for the small-group list. Each one needs to be explicitly authorized in your SPF record and properly DKIM-signed. Miss one, and Gmail sees mail claiming to be from your domain that your domain didn't actually vouch for — which is exactly the pattern DMARC exists to catch and reject.
Second, church domains are frequently on cheap or bundled hosting where nobody has touched the DNS zone since the website went up five years ago. There's often no DMARC record at all, because nothing forced anyone to add one — until now.
Third, congregational email lists decay in a specific way: members change jobs, retire an old email address, or just stop opening messages they still technically didn't unsubscribe from. That produces the bounce and low-engagement pattern that inflates your spam complaint rate even when nobody is actively hitting "report spam" — Gmail treats a message nobody opens for months as a soft signal too.
Step 1: Set up SPF correctly for every tool that sends on your behalf
Your SPF record is a single DNS TXT record listing every service authorized to send email as your domain. Log into wherever your domain's DNS is managed (often your website host or registrar — GoDaddy, Google Domains, Cloudflare) and look for an existing TXT record starting with "v=spf1".
List every sender: v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimpapp.net ~all — adjusting for whichever specific services you actually use (Google Workspace, your ChMS, your giving platform, your email marketing tool). A common church mistake is having two separate SPF records instead of one merged one; DNS only allows a single SPF TXT record per domain, so a second one silently breaks both.
If you don't know everything that sends as your domain, ask each vendor for their exact "include" string — they publish it in their sending documentation — rather than guessing.
Step 2: Turn on DKIM in every platform you send from
DKIM attaches a cryptographic signature to each outgoing message, proving it wasn't altered in transit and really came from an authorized source. Unlike SPF, DKIM is set up per-sending-platform, not once for the whole domain.
In Google Workspace: Admin console → Apps → Google Workspace → Gmail → Authenticate email, generate the key, and add the resulting CNAME record to your DNS. In your ChMS or email platform, the setting is usually called "domain authentication" or "custom sending domain" — it will give you one or two CNAME records to add.
The record propagation is the part churches skip: after adding the DNS records, most platforms need you to click back in and confirm "verify" — the record existing in DNS isn't the same as the platform confirming it sees it, and mail sent before verification often goes out unsigned.
Step 3: Publish a DMARC record and read the reports
DMARC tells Gmail and Yahoo what to do when a message fails SPF or DKIM alignment, and it's the record most church domains are completely missing. Start conservative — you want visibility before you start rejecting mail:
Add a TXT record at _dmarc.yourchurch.org with: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourchurch.org — this doesn't block anything yet, it just tells providers to send you a daily report of what passed and failed.
Watch those reports (or use a free parsing tool — raw DMARC XML reports are unreadable by hand) for two to four weeks. Once you've confirmed every legitimate sender is passing, move to p=quarantine, then eventually p=reject. Jumping straight to p=reject without checking reports first is how a church accidentally blocks its own donation receipts or newsletter mid-campaign.
Step 4: Add one-click unsubscribe and clean your list
If your weekly email has any kind of "unsubscribe" link (and under these rules, congregational bulk mail should), it needs to support one-click unsubscribe via the List-Unsubscribe and List-Unsubscribe-Post headers — this is a checkbox setting in virtually every ChMS and email platform (Mailchimp, Planning Center, Constant Contact, Breeze all support it natively), not something you build yourself.
Separately, prune your list. Remove hard-bounced addresses immediately and consider re-engagement campaigns for anyone who hasn't opened a message in six-plus months — a smaller, more engaged list keeps your complaint rate and spam rate low, which matters more to Gmail's filtering than list size ever did.
How to check whether your church is compliant right now
You don't need to guess. Google Postmaster Tools (free, requires domain verification) shows your actual spam rate, authentication results, and delivery errors as Gmail sees them — set this up even if you think you're fine, because it's the only place the 0.3% complaint threshold is visible before it becomes a problem.
For a faster first pass, run your domain through a free DNS-based email checker that reads your live SPF, DKIM, and DMARC records and tells you in plain language what's missing or misconfigured — most churches find at least one gap (usually a missing or weak DMARC record) in under a minute, without needing to touch Postmaster Tools or wait for report data to accumulate.
Check my church's email — free →Frequently asked questions
Does our church actually send enough email to be affected by these rules?
If you use a ChMS or email platform to message your whole congregation — even a list of a few hundred people, sent weekly — you're sending bulk mail in Gmail and Yahoo's eyes. The 5,000/day figure is the hard enforcement line, but authentication weaknesses cause delivery problems at any volume; smaller senders just see it as "low open rates" rather than outright blocking.
We use Mailchimp or Planning Center — don't they handle this for us?
They handle the sending infrastructure and usually support DKIM signing and one-click unsubscribe out of the box, but SPF and DMARC live in YOUR domain's DNS, and only you (or whoever manages your domain) can add those records. The platform can walk you through what to add, but it can't add it for you.
What happens if we don't fix this?
Nothing breaks all at once. Mail starts landing in spam for a growing share of recipients, delivery gets slower, and eventually Gmail or Yahoo may reject messages outright rather than filtering them. It reads as "people aren't opening our emails anymore" long before anyone suspects DNS.
Is DMARC going to block our donation receipt or giving platform emails?
Only if you set it to p=reject before confirming every legitimate sender passes alignment. Starting at p=none and reading the reports for a few weeks is exactly how you avoid that — it shows you what would have been blocked without actually blocking anything.
Can we just ask our web host or IT volunteer to handle this?
Yes, if they're comfortable editing DNS TXT/CNAME records and reading DMARC aggregate reports — it's usually a 30-60 minute job once you know exactly what to add. The hard part is usually knowing what's missing in the first place, which a DNS check makes visible immediately rather than after weeks of guessing why open rates dropped.