Why Do Our Emails Keep Going to Spam? 

You send the newsletter Thursday morning. By Sunday, four people mention they never saw it, and one of them found it in a junk folder sitting under an offer to extend the warranty on a car she sold in 2019.

You have sent that newsletter, from that address, for years. The receiving end is what moved.

Spam filtering starts before your wording

The instinct is to blame the content. Too many links, the word “free” in the subject line, too many images, an exclamation mark. Those things do carry some weight. But authentication is a separate check from content, and Google lists it first among the six things every sender has to get right. A message the receiver cannot verify is starting from behind before your subject line is read at all.

The question that gets asked first is more basic: can I confirm this message came from the domain it claims to come from?

Anyone can type your church’s address into the “from” field of an email. The system on the other end has no way to tell whether that is you or somebody impersonating you, unless your domain publishes a record naming who is allowed to send on its behalf. When no such record exists, your legitimate newsletter and an outright forgery look the same from the outside. Filters treat unverifiable mail with suspicion, and for good reason.

The three records, in plain English

These live in your domain’s DNS settings, the same place that points your web address at your website. Google Workspace’s own guide to email authentication describes each one roughly like this.

SPF lists which mail servers are allowed to send email using your domain. Google’s framing is that it helps prevent senders from impersonating you.

DKIM attaches a signature to each message so the receiver can confirm the contents were not altered in transit.

DMARC lets you choose what happens to mail that fails the other two. In practice you ask receivers to reject those messages or set them aside.

SPF and DKIM both existed for over a decade while forged email stayed common. DMARC.org, the industry group behind the standard, gives several reasons for that. Two of them are that senders had no way to see how much of their own legitimate mail was failing, and that receivers would not block unauthenticated mail while they couldn’t be sure all of it was fraudulent. Google recommends all three records, and notes that DKIM and SPF together send a stronger signal than either does alone.

What actually applies to a small sender

Google’s sender guidelines have two tiers, and the boundary is 5,000 messages a day to Gmail addresses. Most deliverability checklists online do not mark that split, because they are written for senders far above it. A 400-member congregation ends up handed the bulk-sender list, DMARC and one-click unsubscribe and matching “from” domains, and told the whole thing is mandatory.

Every sender, at any volume, has to do six things. Set up SPF or DKIM. Have valid forward and reverse DNS records, which let a receiving server look your mail server up in both directions and get a matching answer. Transmit over an encrypted TLS connection. Keep spam complaints under 0.3% as measured in Google’s Postmaster Tools. Format messages to the technical standard Google cites as RFC 5322, which your mail software handles for you. And avoid putting a Gmail address in your “from” header. These took effect on 1 February 2024.

Senders above the threshold carry more. Both SPF and DKIM, where the first tier accepts either one on its own. DMARC. A “from” domain that matches the SPF or DKIM domain. One-click unsubscribe on marketing and subscription mail.

A weekly newsletter to 400 people sits far below 5,000 a day, so that second tier never applies to you. The first list is the one that governs, and the requirement most often missing from a small sender is its very first item.

The complaint rate is tighter than it looks

Google’s stated requirement is 0.3%. The same page also asks senders to stay below 0.10%, and to avoid ever reaching 0.30% or higher. The 0.10% figure is the one worth planning against.

Do the arithmetic on a small list and it gets uncomfortable. The rate is measured in Postmaster Tools, which sees only the mail you send to Gmail addresses, so your denominator is the Gmail share of your list. On a list of 400 where 250 of the addresses are Gmail, 0.10% is a quarter of a complaint. One person pressing “report spam” has already taken you well past it.

That math changes how you should think about your unsubscribe link. A buried unsubscribe just converts unsubscribes into spam complaints, and on a list this size a complaint costs you far more than a lost subscriber does.

One caveat, stated plainly. Google warns that Postmaster Tools data “might be missing if the total number of messages for a given day is too low,” which it says protects user privacy. Plenty of small senders will never see their own number. That is a real blind spot with no workaround, so plan as though the 0.10% target applied whether or not you can read it. The two things that drive the figure are how easy your unsubscribe link is to find and how old the addresses on your list are.

Five things that actually cause this

1. No authentication was ever set up. The one we find most often. The domain was configured years ago to serve a website, email was an afterthought, and nobody added SPF or DKIM because nothing appeared to be broken at the time.

2. A newsletter service sending as your domain without being authorized. You signed up, set the “from” address to your own domain, and skipped the step where the service asks you to verify it. A server your domain has never vouched for is now sending on its behalf, which is precisely the pattern SPF exists to catch.

3. Bulk mail sent from a free address. A volunteer sets the newsletter’s “from” address to the church’s Gmail account, because that is the address everyone knows. Google’s guidelines name this one directly, and no amount of configuration on your side can fix it, because gmail.com is not yours to authorize.

4. Forwarding. RFC 7960, the IETF’s informational document on DMARC and forwarded mail, describes the mechanism: forwarding often extends the delivery path “outside of the scope covered by the originating ADMD’s SPF record(s).” In plainer terms, the message still claims to come from your domain, but it now arrives from a server your SPF record never listed, so the SPF check fails. DKIM can survive the hop, because it signs the message contents and travels with them. Do not count on that: the same document is blunt that “modification of email content invalidates most DKIM signatures, and many message-forwarding systems modify email content.” Publishing both records buys you a chance here, not a guarantee. It also explains why the staff member who auto-forwards church mail to a work account is often the one person reporting a problem nobody else sees.

5. A list that has gone stale. Addresses nobody has touched in years generate bounces and complaints, and both count against your domain’s standing. A list you inherited and never pruned is working against you every send.

How to check yours in about a minute

Free, and no tool to install.

1. Send an email from your normal address to any Gmail account.
2. Open it in Gmail on a computer. Next to Reply, click More (the three dots), then choose Show original. Those are Google’s own steps for viewing a message’s headers.
3. Gmail lists SPF, DKIM and DMARC near the top of that view, with a result beside each.

Three passes mean authentication is working and your problem lies elsewhere, most likely complaint rate or list quality. A failure, or a line that is absent altogether, names the record you need to add. That is the entire diagnosis.

What to do next

Adding or correcting those records means editing DNS, and that is where this usually stalls. The records themselves take an afternoon. Establishing who can edit them takes a week of phone calls, because the domain often sits at a registrar nobody has logged into.

So start there. Find out who controls the domain, then add SPF, then DKIM through your email provider, which generates the key for you. Add DMARC last, at the monitoring setting p=none, which asks receiving systems to take no DMARC action on failures, though they still apply their own filtering. Point it at an inbox that can collect their reports, so you can see who is sending as you before you ask for a single message to be rejected.

If you are not certain who holds the domain, settle it before you need it in a hurry. We covered how to find out who holds your domain and hosting separately, and it is the same question underneath. Ongoing, this belongs with whoever handles your hosting and support, alongside backups and updates, because it is a set-once-and-verify job that should never be rediscovered through a missing newsletter.

In the cases we have looked at, this usually traced back to a record nobody added, on a domain set up years earlier by someone whose job that day was the website. Mail never came up.

If people keep telling you they never got the newsletter, open Show original. The answer is sitting in those three lines.