If your church sends its Sunday email blast and half your congregation never sees it, the problem usually isn't your content — it's your domain's authentication. SPF, DKIM, and DMARC are three DNS records that tell Gmail, Outlook, and Yahoo "yes, this email really came from our church, trust it." Without them, your newsletters, giving receipts, and volunteer schedules quietly land in spam folders, or worse, get rejected outright. The good news: this is a one-time, 30-45 minute setup, and you don't need to be technical. This guide walks through exactly what records to add, where to add them, and how to verify they're working — using your church's real domain (like gracechurch.org) on Google Workspace.
Church staff often send from a shared Gmail or an unauthenticated domain, and email providers have gotten aggressive about filtering unverified senders — especially since Google and Yahoo tightened bulk sender requirements in 2024. If you send to more than about 20-30 people at once (a congregation list, a donor list, a volunteer roster), you are a "bulk sender" in their eyes, and missing SPF/DKIM/DMARC can mean Gmail rejects your messages entirely, not just spam-folders them.
For a church, that's not an abstract IT problem. It's the Christmas Eve service announcement that never arrives, the online giving receipt a donor never gets (and then doesn't trust you with their next gift), or the volunteer schedule that gets missed because it never left your outbox. Fixing authentication is usually the single highest-leverage 30 minutes you can spend on your church's communication this year.
You'll need access to two things: your domain's DNS settings (wherever you bought your domain — GoDaddy, Namecheap, Google Domains/Squarespace, or your web host) and admin access to your Google Workspace account (admin.google.com).
If you're not sure who manages your domain, check your church's website registration email, or look up your domain at whois.com — it will list the registrar. If a volunteer or former staff member set this up years ago, it's worth tracking down those login details now, since you'll need DNS access for all three records below.
A quick note on timing: DNS changes can take anywhere from a few minutes to 48 hours to fully propagate, though for most registrars it's under an hour. Don't panic if a record doesn't verify immediately — wait 30 minutes and check again before troubleshooting.
SPF tells receiving mail servers which servers are allowed to send email "as" your domain. For a church on Google Workspace, this is usually one TXT record.
Go to your DNS host and add a new TXT record with:
- Host/Name: @ (or leave blank, or your root domain — varies by registrar)
- Value: v=spf1 include:_spf.google.com ~all
If your church also sends email from another tool — say, Mailchimp for the newsletter, Planning Center for check-in receipts, or a giving platform like Tithe.ly — you need to add each of those to the same SPF record, not create separate ones. A domain can only have ONE SPF record. For example, if you use Google Workspace and Mailchimp: v=spf1 include:_spf.google.com include:servers.mcsv.net ~all. Check each service's help docs for their specific "include" value.
Save the record, then verify it at mxtoolbox.com/spf.aspx by entering your domain. It should show a valid SPF record within an hour.
DKIM adds a digital signature to every outgoing email, so receiving servers can confirm the message wasn't altered in transit and really came from your authorized mail server. Unlike SPF, this one is generated inside Google Workspace, not typed from scratch.
In Google Admin Console, go to Apps → Google Workspace → Gmail → Authenticate email. Select your domain and click "Generate new record." Choose the default 2048-bit key length (more secure, and Google's current default). Google will give you a TXT record that looks like: Host: google._domainkey, Value: v=DKIM1; k=rsa; p=MIGfMA0GCS... (a long string).
Copy that exact host and value into your DNS host as a new TXT record. Back in Google Admin, click "Start authentication" — Google checks the DNS record itself and turns it on once it finds it (this can take up to 48 hours, but is usually much faster). You can confirm it's live by sending a test email to a Gmail address, opening it, clicking the three-dot menu, and selecting "Show original" — you should see dkim=pass.
DMARC is the record that ties SPF and DKIM together and tells receiving servers what to do if an email fails both checks — and, critically, sends you reports so you can see who is (or isn't) sending email as your domain, including potential phishing attempts impersonating your church.
Add a TXT record with:
- Host/Name: _dmarc
- Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourchurchdomain.org; pct=100
Start with p=none. This is monitor-only mode — it won't block or spam-folder anything yet, it just collects data so you can see what's happening. Set the rua address to an inbox someone actually checks (or a dedicated one you create just for this).
After running in monitor mode for 1-2 weeks and confirming all your legitimate senders (Google Workspace, your newsletter tool, your giving platform) are passing, tighten the policy to p=quarantine (failed mail goes to spam) and eventually p=reject (failed mail is blocked outright) for the strongest protection against someone spoofing your church's domain in a phishing scam.
Once all three records are in place and propagated (give it a few hours), run a full check at mxtoolbox.com/domain — search your domain and confirm SPF, DKIM, and DMARC all show green.
Then do a real-world test: send an email from your church Google Workspace account to a personal Gmail address, open it, click the three-dot menu → "Show original," and look for three lines near the top: spf=pass, dkim=pass, dmarc=pass. If all three pass, your setup is complete and your church's email is now fully authenticated.
If something fails, the most common culprits are a typo in the SPF include, forgetting to add a second sending tool to the SPF record, or the DKIM record not having finished propagating yet. Re-check the exact values against what Google Admin or your email tool provided — a single missing character will break the record.
Get a free church email deliverability audit →Yes. SPF and DKIM each catch different things, and DMARC is what actually enforces the policy and gives you visibility. Having only SPF (the most common half-measure) leaves DKIM and DMARC gaps that spammers and phishers can exploit by spoofing your church's domain, and increasingly, having only SPF isn't enough to avoid Gmail's bulk sender spam filtering.
No, as long as you start DMARC at p=none (monitor mode). SPF and DKIM don't block anything on their own either — they just add verification. The only way to accidentally break email is to jump straight to a DMARC p=reject policy before confirming all your legitimate senders pass, which is why we recommend the gradual none → quarantine → reject path.
Yes — each additional service that sends email on your church's behalf needs to be added to your single SPF record (as an additional include:) and ideally should support its own DKIM signing too. Check each platform's help docs for "SPF" or "domain authentication" setup instructions specific to that tool.
After DMARC has been running for a week or two, your rua reports (sent to the email you specified) will show pass/fail rates from every mail server that received email claiming to be from your domain. You can also just track it practically: fewer "I never got your email" replies from your congregation is the clearest real-world signal.
Yes — this is exactly the kind of setup we handle for churches migrating to or cleaning up Google Workspace. If DNS access, generating DKIM keys, or reading verification reports isn't something your staff has time for, we can set up and verify all three records for you as part of a migration or standalone deliverability fix.