“SPF, DKIM, and DMARC all say PASS. So why did our customer find the email in spam?” It is a frustrating question after you have finished the authentication setup. Surely a message that passes should reach the inbox.
Passing authentication does not guarantee inbox placement. Authentication checks the domains used in a message. The receiving service also considers sending history, recipient feedback, sending patterns, content, and other signals when deciding where it belongs. A message can pass DMARC and still land in spam. Microsoft’s explanation of filtering factors ↗
We will follow a fictional company, Gaon Trading, which uses separate services for employee email and newsletters. Several customers say its latest newsletter never arrived. One later finds it in Gmail’s spam folder. The records and results below are invented to show how an investigation works.
“Sent successfully” can mean several different things
First, check what the sending service means by success. One service may mark a request successful when it accepts the job; another may report delivery only after the receiving server accepts the message. Similar labels can describe different stages.
- 01Request accepted
The website, CRM, or email service has accepted the sending job. The message may still be waiting to leave.
- 02Receiving server accepts it
The receiving server takes responsibility for the message. Its final classification and the recipient’s actions are still unknown.
- 03Message found in the mailbox
Someone checks the inbox, Promotions tab, spam, or quarantine. Whether the recipient reads it is another question.
Mail servers exchange messages using SMTP. A successful response such as 250 after message transmission means that server has accepted responsibility for processing it. It does not mean the message appeared in the customer’s primary inbox or was read. Also check whether the response came from an intermediate sending server or the final receiving service. What SMTP acceptance establishes ↗
Scroll sideways to read the full table.
| Observed state | What it means | What to check next |
|---|---|---|
| Only the sending request was accepted | The message may be queued or may have failed before transmission | Job ID and subsequent sending events |
| Deferred or bounced | The receiving server has not yet accepted it, or has rejected it | SMTP code and full response text |
| Found in spam or administrator quarantine | The receiving system has the message but classified it separately | Original headers, filtering explanation, and receiving policy |
| Found in another inbox tab | The inbox has sorted it into a category | The actual location and inbox settings |
Gmail’s Promotions tab is part of the inbox, not the spam folder. Finding a newsletter there does not establish a delivery or authentication failure. Gmail inbox categories ↗
Gaon stops treating every “missing” report as the same incident. It records server acceptance from the logs and the location customers actually find separately. If a message bounced, begin with the detailed response in our Gmail and Outlook bounce guide before investigating inbox placement.
Check authentication on the message that went to spam
A green result on a domain checker does not establish how a particular newsletter was authenticated. Published DNS records and a receiving server’s result are different pieces of evidence. A successful test from an employee’s mailbox does not validate an external newsletter service, either.
Gaon obtains the original message found in the customer’s spam folder. In Gmail, the message menu provides access to the original. A screenshot showing only PASS may omit the domains that passed, so the technical reviewer also checks the receiver’s Authentication-Results header. Remove unnecessary body content and personal information before sharing, while preserving the headers needed for the investigation. Checking authentication in Gmail ↗
From: Gaon Trading News <news@example.com>
Return-Path: <bounce@bounce.example.com>
Message-ID: <campaign-0922-01@example.com>
Authentication-Results: mx.receiver.example;
spf=pass smtp.mailfrom=bounce.example.com;
dkim=pass header.d=example.com;
dmarc=pass header.from=example.comSPF passed for the return-path domain bounce.example.com. DKIM passed with a signature from example.com, and DMARC passed for the visible From domain, also example.com. This copy gives us no basis to begin with “the company’s domain authentication failed.”
If SPF and DKIM pass but DMARC fails, the investigation changes: the authenticated domains may not align with the company’s From domain. Start with DMARC alignment troubleshooting. For an introduction to each check, see how email authentication works.
DMARC does not replace the receiver’s other judgments. Evidence that a sender authenticated a domain does not establish that the recipient wanted the message. DMARC and receiver handling ↗
Narrow down which messages and recipients are affected
Make “our email goes to spam” more specific. Does it affect every sending path or just the newsletter? Every recipient or one receiving service? When did it start? Those differences tell you where to look next.
Gaon sends test copies through the real newsletter service to accounts it controls or whose owners have agreed to help. It also tests employee email, but keeps the results separate.
Scroll sideways to read the full table.
| Sending path | Receiving service | Authentication | Observed location |
|---|---|---|---|
| Newsletter service | Personal Gmail | SPF, DKIM, DMARC PASS | Spam in one test account and a customer’s copy |
| Newsletter service | Personal Outlook.com | SPF, DKIM, DMARC PASS | Inbox in the test account |
| Newsletter service | Yahoo Mail | SPF, DKIM, DMARC PASS | Inbox in the test account |
| Employee email | The same personal Gmail test account | SPF, DKIM, DMARC PASS | Primary inbox |
The supported conclusion is limited: in the checked sample, the problem clusters around newsletters sent to Gmail. It does not prove that Gmail has blocked the whole company or that the sending IP is the only difference between the two paths. Signing domains, content, and sending history can differ too.
“Uses the Outlook app” is not enough to identify the receiving service. The app can connect to Outlook.com, Microsoft 365, or another provider. If only a corporate recipient is affected, ask its administrator about local filtering policy and quarantine records.
Record any action the recipient takes after finding the message, such as choosing “Not spam” or creating a filter. If a later message reaches the inbox, that action may have influenced the result. Keep the initial location and subsequent user actions separate when comparing before and after.
Review sending history and the recipient’s experience
With authentication checked, place recent changes beside the sending logs. A reputation score from one tool cannot settle the cause. Providers observe different traffic and do not disclose every reason for their classifications.
An address on a list is not proof that its owner expects a newsletter
Check where each address came from, what the person signed up for, the expected frequency, and whether unsubscribed recipients were added again. Registering for an event may not mean subscribing to a monthly newsletter. If an old list was merged after a staff change, compare its source with the subscription records.
Yahoo advises sending requested mail at the expected frequency and managing invalid addresses, complaints, and bounces. A person who expected monthly news may object to daily promotions. Rotating a DKIM key will not resolve that mismatch. Yahoo’s guidance on subscribers and sending frequency ↗
Did volume and the sending path change together?
Gaon normally sends around 800 messages a month. This time it added event contacts and sent 4,000 at once. Those figures are not a universal threshold for acceptable sending; they are a clue that both the audience and the sending pattern changed. The team compares dates, recipient-provider totals, delays, and bounces with earlier campaigns.
Record any recent provider or IP change too. Microsoft describes sending IP history and complaints among the factors affecting delivery. If you use a shared IP, ask the provider about incidents or blocks during the affected period. Spam placement alone does not prove that another customer caused the problem. Outlook.com guidance on sending IPs and reputation ↗
Does the message make sense to the recipient?
Check whether the sender name identifies your company, the subject matches the message, and the buttons lead where a reader would expect. Follow tracking links through to their final destination. Look for expired pages and unexpected external sites, even when the sending provider generated the link.
Yahoo describes URLs and domains among the signals used in reputation assessment. There is no universal fix such as removing the word “free” or reducing the number of images. Correct broken links and misleading wording, then check what happens. Yahoo’s explanation of reputation signals ↗
Do receipts and promotions use the same sending setup?
A password reset or payment receipt arrives in a different context from a newsletter. Documenting the addresses, signing domains, and sending paths for each type makes problems easier to trace. Yahoo recommends separating mail types by IP or DKIM domain. A new subdomain alone, however, does not guarantee that all reputation effects are isolated or that delivery will improve. Yahoo’s recommendation on separating mail types ↗
RUA reports, reputation tools, and open rates answer different questions
Gaon’s RUA reports show that most legitimate traffic passes authentication. That does not contradict a customer’s spam report. The RUA disposition field concerns DMARC policy handling, not the message’s final folder. Disposition in DMARC aggregate reports ↗
Scroll sideways to read the full table.
| Evidence | What it can show | What it cannot establish by itself |
|---|---|---|
| Sending logs and SMTP responses | When a server accepted, deferred, or rejected a message | Final folder or whether a person read it |
| Original message and observed location | Authentication and location for that copy | Inbox placement across every customer |
| DMARC RUA reports | Reported sending IPs, counts, authentication, and alignment | Spam or Promotions placement for individual messages |
| Google Postmaster Tools | Available reputation, complaint, and error data for personal Gmail | Other providers’ results or the cause for every individual message |
| The sending service’s open rate | An engagement measure using that service’s definition | Actual inbox placement or the exact cause of spam filtering |
Postmaster Tools may omit data on low-volume days to protect privacy. A missing chart does not establish a good reputation. Even a 0% spam complaint rate can coexist with poor placement: mail already routed to spam gives recipients fewer opportunities to report it from the inbox. Missing Postmaster data and interpreting complaint rates ↗
Treat open rates as supporting evidence. Google says it cannot verify third-party open-rate measurements, and that a low rate does not necessarily indicate delivery trouble or spam classification. Do not jump from “opens fell” straight to “DNS is broken.” Google’s guidance on open rates ↗
In this example, Gaon records that Postmaster charts were unavailable for the period. It works from customer copies, sending logs, and list changes instead. Our RUA report guide explains how to read the authentication evidence in more detail.
Gaon starts with the problems it can confirm
The investigation finds event contacts without a newsletter subscription record and a much larger list sent in one batch. Authentication passed in the checked copies, and the links worked as intended. The team does not claim to have proved the exact filtering cause. It corrects the confirmed sending problems first.
- Remove recipients whose subscription cannot be verified
Event attendance alone does not put someone on the newsletter list. Rebuild the audience from subscription records and make sure prior unsubscribes, complaints, and permanent bounces are not reintroduced.
- Test the unsubscribe process
Unsubscribe a test subscriber, then check that the address is excluded from the next send. Verify the actual audience as well as the confirmation screen.
- Resume at a volume and pace the team can monitor
Send legitimate mail to recent subscribers who expect it. Use provider guidance and sending history to set the volume. Investigate rising deferrals, bounces, or complaints before the next batch.
- Document what changed and what stayed the same
Record the revised list criteria and sending pattern, along with the verified From, DKIM, and DMARC settings that were retained. Keep the record with the campaign so another employee can compare the next send.
Google also recommends adjusting volume gradually while monitoring recipient feedback and server responses. No daily count or recovery period fits every company. Use your history and the receiving services’ responses to guide changes. Google’s sending-volume guidance ↗
The purpose is to observe necessary, legitimate sending after correcting known problems. It is not a reason to send more unwanted mail as an experiment. Because Gaon changed both the list and the volume, an improved result would not isolate the effect of either change.
Retest with new messages through the real sending path
A preview from the campaign editor may not reproduce the original path. Use the same service, sender address, and link configuration as the actual newsletter. Record the new message’s authentication and location, and compare the recipient accounts and conditions with the initial test.
Scroll sideways to read the full table.
| Recipient | Initial observation | Later send | Interpretation |
|---|---|---|---|
| Gmail test account A | Spam; authentication PASS | Promotions; authentication PASS | Placement changed for this account. Overall placement is unknown. |
| Outlook.com and Yahoo test accounts | Inbox; authentication PASS | Inbox; authentication PASS | No new deterioration was observed in these checked paths. |
| Customer who first reported the problem | Spam | Spam again | The customer’s problem remains open and needs further investigation. |
Improvement in a test account is not enough to close the incident. Here, the customer is still affected. The team requests the new copy and receipt time, checks recipient rules, blocking settings, and forwarding differences, and asks the sending provider to investigate that message’s delivery log and sending IP.
Use a consistent record for subsequent checks: date and time zone, campaign ID, Message-ID, receiving service, authentication, observed location, and any manual recipient action. Collect observations over normal business sends on different dates; repeated unnecessary test messages add little value.
Agree on completion criteria beyond authentication PASS. Consider whether the affected customer’s problem recurs, whether delays and bounces change by provider, and whether excluded addresses are being added again. Improvement in the checked sample and resolution across the entire audience are different claims.
Give your provider a traceable example
A support request that says only “our email goes to spam” leaves the provider starting from scratch. Describe the affected path and attach the evidence for a particular message.
Symptom: Newsletters reach spam for some personal Gmail recipients.
Sending path: Newsletter service / From: news@example.com
Scope: Checked employee-mail copies do not show the same problem.
Time: 2026-09-22 10:00 KST (UTC+09:00)
Trace data: Campaign ID, Message-ID, recipient-level sending events
Received original: SPF, DKIM, and DMARC PASS; location recorded
Recent changes: Event contacts added; sending volume increased
Actions: Subscription records checked; exclusions applied; sending pattern adjusted
Unresolved: A customer’s follow-up newsletter still reached spam.
Please check: Sending IP, SMTP response, and any relevant incident or block for this copy.Share originals through the provider’s appropriate support channel rather than a public forum. Message-ID and time make the corresponding log easier to locate. If a corporate recipient’s quarantine is involved, its mail administrator may also need to investigate.
A DNS check can reveal missing SPF, DKIM, or DMARC configuration. Explaining a particular spam classification requires sending and receiving evidence too. If you are deciding who should own authentication and the follow-up investigation, our comparison of DIY and managed DMARC helps define that scope.
Genharden DMARC · Updated 2026-09-22. Based on the SPF, DKIM and DMARC standards and the official documentation linked above. Companies, domains, IP addresses and report figures are illustrative unless stated otherwise.