My records all say pass, so why is my mail still going to spam?

Because authentication is only one of the three inputs. Once SPF, DKIM and DMARC pass and align, the receiver knows the mail is really yours, which is not the same as wanting to deliver it to the inbox. What decides the rest is reputation and recipient behaviour: complaint rates, how old and how accurate the list is, sudden changes in volume, and whether the sending host carries other people's traffic. Those move slowly and no DNS edit touches them.

Postmaster Tools shows no data for my domain. Have I been penalised?

Almost certainly not. Google states that most dashboards only display data when there is a sizable daily volume, up to the order of hundreds of messages, from your authentication domains, and that data can be withheld on low-volume days to protect user privacy. Some dashboards also need your mail to be DKIM-signed first. A company sending a few hundred messages a day across several providers will normally see an empty dashboard, and that is not a verdict.

Should I set DMARC to p=reject right away to fix this?

No. Start at p=none with a reporting address and read the aggregate reports for at least two weeks. Those reports are the only complete list of the systems sending as your domain, and in a small company it is usually longer than anyone expects: a CRM, an invoicing platform, a help desk, a store, a scanner. Move to quarantine and then reject once every one of them is aligned, otherwise enforcement silently discards mail you needed to send.

Why is my email going to spam? A 10-minute self-check

Say a 14-person insurance brokerage sends about 300 messages a day: renewal notices, policy documents, the occasional quote. Nothing changes on their side. Then a client says the renewal never arrived, and a week later another one finds it in the junk folder. Someone in the office starts copying their own Gmail on every message to test it, which proves nothing, because mail you send to yourself almost always lands.

That call reaches us most weeks, and it opens with the same sentence: our emails are going to spam. That one sentence covers at least three unrelated problems, and the repair for one does nothing for the other two. Before you pay anyone, us included, you can tell them apart in about ten minutes using free tools and one message that actually got filtered. This is the order we work in on a first call.

Three different problems that look identical from the outside

Filtering is a verdict, not a cause. The verdict comes from three independent inputs, and knowing which one is failing decides everything you do next.

Authentication. The receiving server cannot prove the message really came from your domain. This is a DNS problem. It is the cheapest to fix and the most common by a wide margin in small companies.
Reputation. Your records are correct, but the domain or the machine sending for you has a history: complaints, a spike in volume, a shared hosting IP carrying somebody else's traffic. No DNS edit clears this. Only time and better sending behaviour do.
Content and list hygiene. People are marking the mail as spam, the list has addresses that stopped existing years ago, or bulk mail has no working unsubscribe. This one hides behind the other two and outlives both.

Google's sender guidelines set the floor for all of them. Every sender is expected to set up SPF or DKIM, to have valid forward and reverse DNS records for the sending domain or IP, to transmit over TLS, and to keep the spam rate reported in Postmaster Tools below 0.30%. Senders who push more than 5,000 messages a day to Gmail accounts have to do all three, SPF and DKIM and DMARC, and support one-click unsubscribe on marketing and subscribed mail. Guidelines checked 24 September 2026.

Under 5,000 a day you are not exempt, you are just judged on fewer rules. The 0.30% spam-rate ceiling and the authentication requirement apply to everyone.

Minutes 1 to 3: look at what your domain publishes

Start in DNS, because it is the only part of this where a wrong answer is unambiguous. You are looking for three records. A healthy small-business set looks roughly like this:

example.com.                    TXT   "v=spf1 include:_spf.google.com ~all"
google._domainkey.example.com.  TXT   "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc.example.com.             TXT   "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Four faults account for most of what we find at this stage.

Two SPF records. One was added for the website host, one for the mail platform, years apart. Two v=spf1 records on the same name is a permanent error and the receiver stops evaluating. There must be exactly one, with every sender inside it.
SPF over the lookup budget. RFC 7208 section 4.6.4 caps a single evaluation at ten DNS-querying mechanisms. Each include you added for a CRM, an invoicing tool and a newsletter platform spends part of that budget, and several expand into more includes internally. Past ten the record returns PermError and effectively stops protecting you.
No DKIM at all. In Google Workspace, DKIM is generated in the Admin console and then published as a record in DNS. Plenty of tenants complete the first half and never do the second, so nothing is ever signed.
No DMARC. Without it you have no reporting, which means no list of who sends as your domain, which is the list every later decision depends on.

Run your domain through the check below before reading any further. It takes a few seconds and it tells you whether the next six minutes are about authentication or about something else.

Minutes 4 to 6: read one message that was actually filtered

Records that look correct in DNS can still fail on a real message, and only the message tells you. Find one that landed in a recipient's spam folder, ideally at Gmail. Ask the recipient to open it, use the three-dot menu and choose Show original, then send you the whole thing as text. Google documents this path on its page about tracing a message with its full header.

In what comes back, find the line beginning Authentication-Results. It carries the receiver's own verdict:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounce@mail.crmvendor.com ...) smtp.mailfrom=mail.crmvendor.com;
       dkim=pass header.i=@crmvendor.com;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=example.com

That example is the single most common finding in our audits, and it explains why so many people conclude that their records are fine. SPF passes. DKIM passes. DMARC still fails, because DMARC does not ask whether SPF or DKIM passed for somebody. It asks whether the domain in the visible From: header lines up with the domain that SPF or DKIM authenticated. Google's own DMARC setup documentation calls this alignment, and it is the step almost every third-party sending platform gets wrong until you configure it deliberately.

So read those lines in this order: dmarc= first, then header.from=, then whether smtp.mailfrom or the DKIM d= domain matches it. If you would rather not squint at raw headers, paste them into our header analyzer and it will name the failing part. If dmarc=pass and the mail still got filtered, authentication is not your problem and you can stop working on DNS entirely.

Minutes 7 to 9: Postmaster Tools, and what an empty dashboard means

Google Postmaster Tools is the only view Google gives you of how Gmail treats your domain. It is free and costs one verification record. Its dashboards report on outgoing mail to personal Gmail accounts, covering spam rate, authentication, delivery errors, compliance status and the feedback loop.

Two limits matter before you read anything into it. Mail delivered to a client's Google Workspace mailbox is not what these graphs measure, and nothing outside Google appears at all, so Outlook and corporate filters stay invisible here.

Then there is the result that confuses people most: no data. Google is explicit that most dashboards display data only when there is a sizable daily volume, up to the order of hundreds of messages, from your authentication domains, and that data may be withheld on low-volume days to protect user privacy. Some dashboards need your mail to be DKIM-signed before they show anything at all.

For the 14-person brokerage at 300 messages a day, split across Gmail, Outlook and corporate recipients, an empty dashboard is the expected result. It is not a verdict on your domain and it is not evidence of a penalty. If you are large enough to see numbers, the spam rate is the one to watch, held under the 0.30% ceiling and ideally far under it. Our guide to setting up Postmaster Tools walks through each dashboard.

If you already have DMARC reporting turned on, this is also the moment to open the last two weeks of aggregate reports in our DMARC report analyzer. Those XML files list every system sending as your domain, including the ones nobody remembered.

Minute 10: decide what this actually is

You now have three answers. Match them to one of these.

DNS shows a gap, and the header shows dmarc=fail. Authentication. This is a DNS job with a clear end state, and a competent admin can finish it in an afternoon. Publish one SPF record covering every sender, sign with DKIM, publish DMARC at p=none with a reporting address, then read reports for two weeks before tightening anything.
Everything passes, mail still lands in spam, and it has been getting worse for weeks. Reputation or content. Look at volume changes, at what you sent just before it started, and at how old the list is. Nothing in DNS will move this.
Messages are being rejected outright rather than filtered. Different problem, and the bounce text names it. Our post on telling Gmail 550 5.7.1 from 5.7.26 splits that one in a minute.

Two signs it is worth bringing in help rather than continuing alone. First, more than a handful of separate systems send as your domain: a CRM, an invoicing or e-invoicing platform, a help desk, a newsletter tool, an online store, the office scanner. Each one needs its own alignment work, the order matters, and SPF runs out of lookups long before you run out of senders. Second, DMARC is already at p=quarantine or p=reject and mail has started disappearing. That combination has a deadline attached, because every day at enforcement is a day of legitimate mail being discarded silently.

Three things not to do, all of which we have been called in to undo. Do not register a fresh domain to escape the problem, because a new domain has no reputation at all and the old one stays broken. Do not raise volume to prove the mail works. Do not buy a subscription to a dashboard that reports a deliverability score without telling you which record to change, because a score is not a diagnosis.

How Guanacos Tech helps

Most of what we do on a deliverability project is the unglamorous part of the list above: name every system that sends as the domain, fix alignment one sender at a time, keep SPF inside its lookup budget, and stay on the DMARC reports long enough to know the fix held before moving the policy up. If the ten minutes above told you this is authentication, you may well finish it yourself, and that is a fine outcome. If it told you there are nine senders and an SPF record that already errors out, our email deliverability consulting for small business is built for exactly that. Bring what you found, a bounced message and your domain, to a 30-minute call, and you will leave knowing which of the three problems you have and what clearing it will take.

Why is my email going to spam? A 10-minute self-diagnosis before you pay anyone