Problem
Your client’s email is going to spam
It is almost never the content of the messages. It is the domain’s authentication failing, and a received message tells you precisely which part.
Open a message that genuinely arrived in Gmail, show the original, and read the Authentication-Results line. It carries three verdicts: spf, dkim, dmarc. The whole diagnosis lives in those three words, and any repair made before reading them is a guess.
Do this right now
Four moves, in this order. Do not touch a single DNS record before the first one.
Read the authentication header of a message that arrived
3 minIn Gmail, open the message, three-dot menu, “Show original”. Find the Authentication-Results line. A received message beats any testing tool: it tells you what the recipient actually observed, from the infrastructure actually in use. Ask the client to forward one as an attachment, not to copy and paste it.
Fix in this order:
20 minSPF, thenDKIM, then alignmentSPFdeclares which servers may send for the domain.DKIMsigns the messages.DMARCalignment checks that the domain shown in the From header matches the domain that passed SPF or DKIM. The third is the one that fails most often and the one people look at last: the first two can both pass while alignment fails.Check reverse DNS and TLS on the sending server
10 minGoogle requires every sender to have valid forward and reverse DNS records — the PTR record — on the sending domain or IP, and to transmit over a TLS connection. Both get overlooked because they do not live in the domain’s zone but with whoever hosts the sending server.
Look at the spam rate in Postmaster Tools
5 minGoogle’s tool shows your domain’s complaint rate. The threshold is explicit: keep it below 0.3%. If authentication is clean and messages still land in spam, that is where the answer is — and the fix is no longer technical, it is editorial.
The header that holds the whole diagnosis
Here is a classic case: two checks out of three are green, and the message still lands in the junk folder. The reason is on the third line.
Authentication-Results: mx.google.com;
spf=pass smtp.mailfrom=example.com;
dkim=fail header.i=@example.net;
dmarc=fail (p=NONE) header.from=example.com
- The line is written by the receiving server — Gmail’s, here. It is an observation, not a prediction, which makes it worth more than any simulator.
SPFpasses: the server that sent the message is listed in the domain’s SPF record. That part is settled.DKIMfails, and the detail explains why: the signature belongs to example.net, not to the message’s own domain. A provider is signing with its own domain instead of the client’s — the classic sign of a sending tool installed without its DNS configuration.- And
DMARCfails as a result: the From domain matches neither authenticated domain. That is alignment, the most common and least understood failure — greenSPFand redDKIMare enough to bring the whole thing down.
What Gmail requires, and from what volume
The requirements changed on 1 February 2024 and a lot of configurations predate that. Two columns, because the five-thousand-messages-a-day threshold changes the rules.
- Authentication of the sending domainAll senders
SPForDKIM.Over 5,000 messages a daySPFandDKIM, both. DMARCAll sendersNot required.Over 5,000 messages a dayRequired on the sending domain. The enforcement policy may stay at none.DMARCalignmentAll sendersNot required.Over 5,000 messages a dayThe From domain must match theSPFdomain or theDKIMdomain.- Forward and reverse DNS (PTR)All sendersValid.Over 5,000 messages a dayValid.
- Transmission over TLSAll sendersRequired.Over 5,000 messages a dayRequired.
- Spam rate (Postmaster Tools)All sendersBelow 0.3%.Over 5,000 messages a dayBelow 0.3%.
- One-click unsubscribeAll sendersNot required.Over 5,000 messages a dayRequired on marketing and subscribed messages, with a visible link in the body.
Source: Google, “Email sender guidelines” (Gmail Help), in force since 1 February 2024. Google also recommends staying below a 0.10% spam rate and avoiding 0.30% altogether. Messages must additionally be formatted according to RFC 5322.
The four causes that come up again and again
Before rebuilding the whole configuration, check whether one of these describes you. They cover the large majority of cases.
The site form that writes in the client’s name
Your contact form sends from the website’s server while putting the visitor’s address, or the client’s, in the From header. To the server receiving it, that is exactly what spoofing looks like. Send from a domain you control and put the visitor’s address in Reply-To.
Two
SPFrecords on the same domainA domain may carry only one. Two do not add up: the check returns a permanent error and the domain ends up worse authenticated than with a single record. If you need to authorize two providers, they belong in one record.
The “~all” people think is strict
The end of an
SPFrecord says what to do with servers that are not listed. “~all” asks for soft handling, “-all” asks for rejection. Writing “~all” while believing the domain is locked down is the most common mistake in the file.The mail migration from two years ago
The client moved providers and the
SPFrecord still authorizes the old one — sometimes only the old one.MXrecords point to the right place and mail arrives, but outgoing messages are no longer authenticated. Always check that MX and SPF agree.
Why it happened
Because the rules tightened while the configurations slept. Since 1 February 2024, Google imposes a floor on every sender that did not exist before: domain authentication, valid reverse DNS, encrypted transmission, complaint rate below 0.3%. A setup that was perfectly fine in 2022 can fail today without anything having changed at the client’s end.
And because a domain’s authentication is made of three parts that nobody owns in full. SPF sits with whoever holds the DNS zone, the DKIM signature with the sending provider, and DMARC alignment depends on both. Each party does its piece, nobody looks at the whole, and the whole is exactly what the recipient evaluates.
The trigger is almost always something mundane: a mail migration, a new invoicing or newsletter tool wired up in fifteen minutes, a provider added without its DNS configuration following.
How to avoid it next time
Publish DMARC in none mode at handover, with a reporting address. You block nothing, and you receive a list of everything sending in the domain’s name — including whatever the client wired up without telling you. It is the only mechanism that warns you before recipients do.
Treat SPF, DKIM and DMARC as DNS records to be monitored, not as a box ticked once. They are three lines of text that a provider, a host or a client can overwrite in two minutes with nothing visible breaking: the site keeps working, the messages keep leaving, they simply arrive somewhere else.
And check coherence at every mail migration. The migration changes the MX records; SPF, DKIM and DMARC are the ones people forget to follow, because they break nothing on the day.
Read the domain’s SPF, DKIM and DMARC
The tool reads all three records and tells you which is missing, which is malformed and what the DMARC policy declares. Enter the domain that sends the mail — not the website’s, if they differ.
Three lines of text, checked every day.
DomainVigil rereads SPF, DKIM and DMARC across every client domain and warns you when one of them changes or disappears. The failure is caught the day it happens, not the day a customer notices. Five domains free.
Five domains free, forever. No card required.