Why Donation Receipt Emails From Tithely or Planning Center Land in Spam
A donor gives online, gets a confirmation screen, and then never sees a receipt land in their inbox. It went to spam — or nowhere at all. If your church runs Tithely or Planning Center Giving, this is one of the most common (and most damaging) email problems you can have, because a missing tax receipt doesn't just annoy a donor, it makes them wonder whether the gift actually went through. The cause is almost always the same: your church's email domain doesn't clearly authorize Tithely or Planning Center to send mail "as" you, so Gmail, Outlook, and Yahoo treat the receipt as suspicious. This is fixable in about 15 minutes with three DNS records, and this guide walks through exactly what to check and what to change.
The real cause: your domain never authorized the giving platform to send for you
When Tithely or Planning Center sends a receipt, it's sending FROM an address that looks like it belongs to your church (e.g. giving@yourchurch.org or noreply@yourchurch.org) but the mail actually originates from Tithely's or Planning Center's servers, not yours. Every major inbox provider checks whether the sending server is authorized to do that on your domain's behalf. If it isn't, the message either lands in spam, gets clipped of images and formatting, or gets silently dropped.
This authorization lives in three DNS records attached to your domain: SPF, DKIM, and DMARC. Most churches never touch these when they sign up for a giving platform — the platform sends you a "add these DNS records" instruction during onboarding, it gets missed or handed to whoever last touched the website, and it never gets done. The giving platform keeps working (donors can still give), but the receipt email quietly fails the authentication check every single time.
This is not a Tithely or Planning Center problem specifically — it's the same failure mode Mailchimp, Constant Contact, and every other "sends on your behalf" tool has. The fix is identical across all of them: publish the records they give you, correctly, on the domain you're actually using in the From address.
Check your current SPF record for a missing include
SPF (Sender Policy Framework) is a DNS TXT record that lists every server allowed to send mail as your domain. If Tithely or Planning Center isn't listed, receiving mail servers see an unauthorized sender and score the message down — often straight into spam.
To check yours: open a terminal or a site like mxtoolbox.com and look up a TXT record for your domain. You're looking for a line starting with v=spf1. A typical church domain that's missing the giving platform might look like this:
v=spf1 include:_spf.google.com ~all
That record authorizes Google Workspace to send, but says nothing about Tithely. Planning Center's current SPF include is include:_spf.planningcenteronline.com and Tithely's setup instructions (in Settings > Email/Communication in your Tithely dashboard) list the exact include for your account type. The fix is to add the missing include inside your EXISTING record — never publish a second v=spf1 line. Two SPF records on one domain is invalid and receiving servers may reject BOTH.
A corrected record looks like:
v=spf1 include:_spf.google.com include:_spf.planningcenteronline.com ~all
SPF also has a hard limit of 10 DNS lookups. Churches that have added Google Workspace, Mailchimp, a giving platform, and a text-messaging tool over the years sometimes blow past this limit, which causes SPF to fail for everyone, not just the newest addition — worth checking with an SPF validator if you've accumulated several includes.
Confirm DKIM is actually turned on, not just available
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to each outgoing message that proves it wasn't altered in transit and really came from a server your domain trusts. Both Tithely and Planning Center support DKIM signing, but in both platforms it requires an extra activation step beyond the basic SPF setup — it's easy to publish the SPF record, consider the job done, and never come back for DKIM.
In Planning Center Giving, DKIM setup is under Organization settings, where it gives you a CNAME record (or pair of CNAME records) to add at your DNS host, then a "verify" button that only turns green once the records are live and DNS has propagated. In Tithely, the equivalent is under the domain/email authentication section of account settings.
To verify DKIM is actually working rather than just configured, send yourself a real test receipt (make a $1 test donation if your platform allows it, or ask your platform's support to trigger a test) and check the message headers in Gmail: open the email, click the three-dot menu, choose "Show original," and look for DKIM=pass next to the signing domain. If it says DKIM=none or DKIM=fail, the CNAME records either aren't published, haven't propagated yet (can take up to 24-48 hours), or don't match exactly what the platform gave you — a single extra character or trailing dot in a copy-pasted record is a common culprit.
Add or fix your DMARC record so SPF and DKIM actually get trusted
DMARC ties SPF and DKIM together and tells receiving mail servers what to do when a message fails either check — and, importantly, it also requires ALIGNMENT: the domain in the visible From address has to match the domain that passed SPF or DKIM, not just any domain somewhere in the sending chain.
Most churches either have no DMARC record at all, or have one set to p=none, which only monitors and doesn't stop anything — meaning DMARC isn't the direct cause of receipts going to spam, but its absence removes a trust signal that inbox providers increasingly expect, especially from Gmail and Yahoo since their 2024 bulk-sender requirements took effect. If you send more than roughly 5,000 messages a month across your church's tools combined, a missing DMARC record can trigger stricter filtering on all of it, receipts included.
A safe starting DMARC record, published as a TXT record on _dmarc.yourchurch.org, is:
v=DMARC1; p=none; rua=mailto:you@yourchurch.org
This monitors without blocking anything, and the rua address gives you a weekly report showing which servers are sending mail as your domain and whether they're passing. Only move to p=quarantine or p=reject once you've reviewed a few weeks of reports and confirmed every legitimate sender (Google Workspace, Planning Center, Tithely, any bulk email tool) is passing — jumping straight to reject before that can cause your OWN legitimate mail to bounce.
Rule out the donor-side reasons before assuming it's your DNS
Not every missing receipt is a sender-authentication problem. Before spending time on DNS records, rule out the simpler explanations: the donor typed their email address wrong at checkout (both platforms let you resend a receipt manually from the transaction record once you spot this), the donor's own inbox has a filter rule sending your domain to a folder they don't check, or their employer's corporate email gateway is blocking nonprofit bulk senders as a blanket policy that has nothing to do with your setup.
A quick way to tell the difference: if ALL your donors are missing receipts, it's almost certainly your DNS/authentication setup. If it's one or two donors out of hundreds, it's more likely donor-side and worth a manual resend plus a note to check their spam folder.
What to do after you fix the records
DNS changes aren't instant. After updating SPF, DKIM, or DMARC, allow up to 24-48 hours for the changes to propagate everywhere, then re-run a test donation and re-check the message headers as described above. Both Tithely and Planning Center also have a support channel that can confirm from their side whether your domain is now passing authentication on outbound receipts — worth a quick message to double-check rather than assuming from one test.
It's also worth checking your domain's overall deliverability health periodically, not just when a donor reports a problem — SPF, DKIM, and DMARC can silently break again if someone adds a new email tool later and overwrites your SPF record instead of editing it. A free domain check (like the one on this site) will flag a broken or missing record in seconds without needing to touch a DNS control panel manually.
Check my church's email — free →Frequently asked questions
Why do only SOME donors report missing receipts, not all of them?
If it's a handful of donors out of many, it's usually donor-side — a mistyped email, a personal filter rule, or their employer's mail gateway blocking bulk senders. If it's most or all donors, it's almost always a sender-authentication problem on your church's domain (missing SPF include, DKIM not activated, or no DMARC record).
Will fixing SPF alone solve the problem?
Sometimes, but not reliably. SPF verifies the sending server; DKIM verifies the message wasn't altered and adds its own trust signal; DMARC ties the two together and enforces that the visible From domain matches. Gmail and Yahoo in particular now expect all three for consistent inbox placement, so fixing only SPF often improves but doesn't fully resolve the issue.
I added the SPF include Tithely gave me, but nothing changed. Why?
The most common cause is a SECOND v=spf1 record on the domain rather than one combined record — check with a DNS lookup tool for duplicate TXT records starting with v=spf1. Having two makes SPF invalid for the whole domain, not just the newest addition. The fix is to merge them into a single record with both includes.
Does this affect anything besides donation receipts?
Yes — the same SPF/DKIM/DMARC setup governs every email your church sends that claims to be from your domain: newsletters, staff email through Google Workspace, event confirmations, and text-to-email notifications. Fixing the records fixes deliverability for all of them at once, not just giving receipts.
How do I know if my church's email is already misconfigured?
Run a free DNS check on your domain — it checks SPF, DKIM, DMARC, and MX records in a few seconds and tells you plainly which ones are missing or broken, without needing DNS or technical knowledge to interpret.