# Church email deliverability checklist From Prices and rules read from the pages named at the foot on 29 July 2026. Print this. Work down it once, in order. Steps 1 to 6 are done once and then left alone. Steps 7 to 12 are the ones that decay, so they carry a review month. Every square bracket is a value your church has to fill in. Do not send anything until step 5 is signed off, because steps 1 to 4 are worth nothing if the From address is wrong. --- ## Before anything: the four facts to write down | Fact | Yours | | --- | --- | | The domain the church owns | [ ] | | Who can log in and edit its DNS records | [name, and the second name who also can] | | Where the church mailboxes are hosted | [ ] | | The sending platform | [ ] | If nobody can answer line 2, stop here and answer it. Every step below is a DNS edit, and a church that cannot edit its own DNS cannot fix its own email. This is the single most common reason a church's newsletter stays in spam for years. --- ## 1. Own a domain, and send from it - [ ] The church owns a domain name and the registration is in the church's name, not a former volunteer's personal account. - [ ] The renewal date is on the church calendar. [date] - [ ] Two people can log in to the registrar. An expired domain takes the website, the mailboxes and the newsletter down at the same moment, and the person who registered it in 2014 may not be reachable. ## 2. Point the From address at that domain - [ ] The From address on every bulk send is `something@yourdomain`. - [ ] No bulk send uses a `@gmail.com`, `@yahoo.com`, `@aol.com`, `@outlook.com` or `@hotmail.com` address in the From header. - [ ] The Reply-To address is a mailbox a human reads. A free-mailbox address in the From header of a platform send fails alignment no matter how correct your own records are, because the domain being authenticated belongs to the platform and the domain the reader sees belongs to Google or Yahoo. Yahoo and AOL publish `p=reject`, which means a receiver honoring DMARC is being told to refuse it. ## 3. Publish SPF - [ ] One TXT record on the apex name, starting `v=spf1`. - [ ] It contains an `include:` for the mail host. [value from your mail host] - [ ] It contains an `include:` for the sending platform. [value from the platform's own setup page] - [ ] There is exactly one SPF record on the domain. Two records is a permanent error, not a stronger record. - [ ] It ends in `~all` or `-all`. `?all` tells a receiver nothing. - [ ] Count the `include:`, `a`, `mx`, `exists:` and `redirect=` terms. Ten is the evaluation cap. Six vendors and you are close to it. ## 4. Publish DKIM - [ ] The platform's setup screen has been opened and the selector and key copied out of it. [selector] - [ ] The record is published at `._domainkey.yourdomain`. - [ ] The platform's own verification button says verified. - [ ] The mail host's DKIM is published too, on its own selector, because the office mailboxes and the newsletter are two different senders. DKIM is the one worth getting right. It survives forwarding, which SPF frequently does not, and it is the half of the pair that still works after a member's address auto-forwards to another mailbox. ## 5. Send one message to yourself and read the headers - [ ] Send a real draft to a mailbox on a different provider from the church's. - [ ] Open the raw message and find `Authentication-Results`. - [ ] `spf=pass` [ ] - [ ] `dkim=pass` [ ] - [ ] `dmarc=pass` [ ] - [ ] The `header.from` domain on that line is the church's domain. Three passes and the right domain. Anything less and you have a configuration problem, not a copywriting problem. Do not proceed to step 6 until this passes. ## 6. Publish DMARC, starting at none - [ ] A TXT record at `_dmarc.yourdomain`. - [ ] `v=DMARC1; p=none; rua=mailto:[a real mailbox]` - [ ] The rua mailbox exists and somebody has agreed to look at it. - [ ] Diary date to read the first two weeks of reports. [date] - [ ] After those two weeks, if every legitimate sender is passing, move to `p=quarantine`. [date moved] `p=none` with no `rua` is the most common church DMARC record and it does nothing at all. It neither protects the domain nor reports anything. If you only ever publish one DMARC record, publish one with a reporting address in it. --- ## The recurring half ## 7. Build the list from consent, one address at a time - [ ] Nobody is added without asking. Not from the directory, not from the giving platform, not from a sign-in sheet that said nothing about email. - [ ] The signup wording is written down and stored: "I agree to receive email from [church name]." - [ ] The consent record holds, per address: the address, the date, the method, the exact wording the person saw, and the date of any opt-out. - [ ] That record lives somewhere the church owns as well as inside the vendor. Review: [month] ## 8. Process every opt-out the day it arrives - [ ] One named person owns this. [name] - [ ] An unsubscribe click is handled by the platform. - [ ] A verbal request on Sunday, a reply to a staff mailbox, and a message to the church Facebook page are all opt-outs too, and none of them reaches the platform on its own. - [ ] The person who is told writes it down the same day. Review: [month] ## 9. Carry the footer that the law asks for - [ ] A working opt-out mechanism, clearly displayed. - [ ] The church's street address, in the message. - [ ] A subject line that describes what is in the message. Review: [month] ## 10. Prune, and understand what pruning costs you - [ ] Bounced addresses removed after two failures. - [ ] On a contact-priced platform, unsubscribed and non-subscribed contacts archived rather than left in the audience, because on Mailchimp both of those keep counting toward the paid contact limit until archived. - [ ] Addresses that have not opened anything in a year moved to a separate list and mailed less often, or asked once whether they still want it. Review: [month] ## 11. Watch the complaint rate - [ ] The domain is registered in Google Postmaster Tools. [date] - [ ] The spam rate reported there is under 0.30 percent. - [ ] Nobody has been added to the list since the last review without consent. On a list of 300, one complaint is 0.33 percent, which is already over the line Google publishes. This is why an imported directory is a deliverability problem and not a shortcut. Review: [month] ## 12. Know what you would take with you - [ ] Every contact exports as CSV, by you, without a support ticket. - [ ] The consent record exports with it. - [ ] The archive of what was actually sent exports, or is copied somewhere else, because at least one church platform keeps only three months of it. Review: [month] --- ## What this checklist deliberately does not tell you It does not tell you your DKIM is missing, because nobody outside your domain can check that. A DKIM key lives at a selector name the sending platform chooses and there is no way to enumerate selector names from the outside. Step 5 is the only reliable test, and it takes two minutes. It does not give a threshold for "good" open rates. Open tracking is a loaded image, image loading is blocked and prefetched inconsistently across providers, and a number nobody can define is a number this checklist will not print. ## Sources - Google, Email sender guidelines: - RFC 7208, Sender Policy Framework: - RFC 6376, DomainKeys Identified Mail: - RFC 7489, DMARC: - Mailchimp, About Your Contacts: - 15 U.S.C. 7704: All read 29 July 2026.