SPF and DKIM Pass, but Emails Still Land in Spam? Diagnose Placement Before Changing DNS

If SPF and DKIM show “pass” but campaign messages land in spam, do not keep editing DNS records or rewrite every subject line. Authentication answers whether a receiving system can verify parts of a message and its sending domain. It does not promise inbox placement. Gmail and Yahoo also publish expectations around DMARC alignment for bulk senders, complaint rates, unsubscribe handling, message format, and sender reputation. Diagnose the full path before changing the configuration.

Gmail’s sender guidance distinguishes all senders from those sending more than 5,000 messages a day to personal Gmail accounts. Bulk senders must configure SPF, DKIM, and DMARC, align the From domain with SPF or DKIM, and support one-click unsubscribe for marketing and subscribed messages. Google recommends keeping the reported spam rate below 0.1% and avoiding 0.3% or higher. Yahoo likewise calls for SPF or DKIM for all senders; its bulk-sender guidance includes SPF, DKIM, a passing DMARC policy, one-click unsubscribe, and a spam complaint rate below 0.3%. These are provider requirements and recommendations, not a universal inbox guarantee. Check current provider instructions for your actual sending pattern. Google: Email sender guidelines · Google: sender guidelines FAQ · Yahoo: Sender Best Practices

First distinguish acceptance, delivery, and inbox placement

An email platform’s “sent” label may mean that it submitted the message. A receiving server can accept it and still place it in spam. A provider can defer or reject it. A mailbox can sort it into a promotional tab. These outcomes need different evidence and different fixes.

Start with a small incident record:

Sending domain, visible From address, sending service, and any dedicated IP.
Message type: marketing, subscribed update, or transactional notice.
Recipient provider and mailbox type; compare Gmail and Yahoo separately.
Time window, approximate volume, list segment, and recent changes.
Provider response codes, bounce categories, and recipient-reported folder placement where available.
Whether only a test inbox, one campaign, one sending stream, or several providers are affected.

Do not infer inbox placement from an ESP’s accepted count, open rate, or one employee’s mailbox. Gmail says it does not track open rates and cannot verify third-party open-rate accuracy. Use delivery and complaint diagnostics where available, controlled seed accounts as a limited check, and real recipient feedback with privacy-respecting methods. A seed test is a clue, not a representative measurement of every inbox.

Check authentication on the message the recipient received

Inspect the original message headers from an affected mailbox, not just the DNS dashboard or ESP’s setup badge. Look at SPF, DKIM, DMARC, and alignment results for that delivered message.

SPF: Identify the envelope sender domain and the result at the recipient. A forwarder can affect SPF evaluation because the forwarder’s IP may not be authorized by the original sender’s SPF record. Do not respond by repeatedly adding unrelated senders to a record.
DKIM: Confirm that a signature is present, verifies, and uses the expected signing domain. Check whether the sending service signs the message stream you are troubleshooting.
DMARC: Confirm the published policy and whether the visible From domain aligns with a passing SPF or DKIM identifier under the domain’s alignment mode. A green SPF result for a different domain does not by itself prove DMARC alignment.
Message path: Compare direct delivery with forwarded mail, and test marketing and transactional streams separately. The same domain can have different results across services or message types.

Save a redacted header and the timestamp before changing records. If the message has SPF and DKIM passes but DMARC fails, investigate alignment and the actual From domain. If all three pass, do not assume that more DNS edits are the answer; continue the diagnosis.

Review reputation, complaints, and recipient expectations

Authentication helps establish that a sender is authorized; it does not make an unwanted or poorly targeted campaign wanted. Review how each recipient joined the list, what they were told to expect, whether the segment is still relevant, and how unsubscribes and complaints are handled. Investigate recent imports, consent changes, frequency changes, and old or inactive segments.

Use provider-specific tools when available. Gmail Postmaster Tools can show authentication and reputation-related signals for eligible traffic; Google notes that low volume or privacy protections can limit what appears. Yahoo Sender Hub provides best practices, and its Complaint Feedback Loop can help eligible senders monitor complaints. Do not compare rates unless the denominator and provider’s definition match. A dashboard with sparse data is not evidence that the problem has disappeared. Google: Postmaster Tools dashboards · Yahoo Sender Hub

Check the actual unsubscribe path. Promotional messages need the applicable list-unsubscribe mechanism and a visible body link under the provider requirements; an address change or suppression job should prevent another campaign send. A “manage preferences” page is not a substitute for a functioning one-click unsubscribe where required. Confirm the behavior from a test subscription through suppression, not only from a template preview.

Inspect content and infrastructure after the evidence

Review links, redirects, tracking domains, image-to-text balance, attachment types, broken destinations, abrupt volume changes, and whether the From name matches the expected brand. These are investigative leads, not a magic list of words that automatically puts an email in spam. No single “spam word” checker can diagnose the full sender and recipient context.

Check the sending provider’s event logs, DNS changes, routing, TLS setup, domain age, and shared-versus-dedicated infrastructure with the responsible administrator. Review applicable block or deferral codes directly with the mailbox provider. Do not paste a random SPF string from a blog, add every service to SPF, rotate domains to escape reputation, or move the same unconsenting audience to a new sender. Those changes can obscure the cause and create new delivery or compliance issues.

Run a controlled recovery, not a blast

Write one hypothesis, one change, the affected segment, the expected evidence, and a stop condition before acting. For example: “Marketing messages to Gmail show DMARC alignment failure after a From-domain change. We will verify the signing and envelope domains with the sending administrator, send a small consented test, and compare DMARC results before resuming the affected stream.”

Keep transactional notices separate from marketing tests. Use recipients who explicitly agreed to receive the message and a low-risk test volume. Avoid repeatedly sending the same campaign to force engagement or suppress a negative metric. If complaint levels rise, pause the affected campaign and investigate the list source, expectation, and unsubscribe processing before increasing volume. Record the starting configuration so a change can be reversed safely.

Do not promise a fixed recovery time. Provider reputation and filtering are not controlled by a single DNS record, and dashboards may lag or hide low-volume data. Resume gradually only after the technical issue is corrected and the audience and sending behavior are sound. A delivery improvement is a measured observation for that provider and period, not proof of a universal fix.

Short-video script: SPF and DKIM pass—why is the message still spam?

Hook: “Authentication passed. Inbox placement did not. Those are different checks.”

Voice-over: “First separate submitted, accepted, rejected, and spam-foldered messages. Then inspect the recipient’s headers for SPF, DKIM, and DMARC alignment—not just the DNS dashboard. Compare providers, list segments, and marketing versus transactional mail. Check complaints, consent, unsubscribe processing, and recent volume changes. Change one evidenced cause at a time; don’t keep editing DNS or blast the same list.”

Visual: A path diagram: sender → receiving server → accepted/rejected → inbox/spam, with authentication and reputation shown as separate checkpoints. CTA: “Save the diagnostic sequence before changing your next DNS record.”

Educational carousel: Authentication is not inbox placement

Cover: SPF and DKIM pass, but the campaign is in spam. What does “pass” actually prove?
Separate the states: submitted, accepted, rejected, inboxed, spam-foldered, and tabbed are different outcomes.
Inspect the received header: verify SPF, DKIM, DMARC, and domain alignment for the affected message.
Segment the incident: provider, message type, list source, volume, and date.
Check recipient signals: consent, expectations, complaints, unsubscribes, and list changes.
Use provider evidence: Gmail Postmaster Tools and Yahoo Sender Hub/Complaint Feedback Loop where available.
Change one cause: record the hypothesis, test, outcome, and rollback condition.
No guarantee: passing authentication is necessary in some cases; it does not guarantee inbox placement.

Field experiment thread: isolate one placement problem

A proposed diagnostic test; it does not claim a recovery result.

1/ Define the incident window, affected message stream, recipient provider, list segment, and the exact observed outcome. Keep “not seen” separate from “confirmed spam-foldered.”

2/ Capture provider response codes, redacted headers, DNS state, message volume, consent source, complaints, and recent changes before editing anything.

3/ Form one testable hypothesis—for example, DMARC alignment fails only on one campaign service. State what result would support or reject it.

4/ Test with a small, consented group and the same message type. Keep transactional email out of a marketing experiment.

5/ Make one approved change, then compare provider results and complaint signals over a defined period. Stop if complaints or rejection rates worsen.

6/ Record limitations: seed inboxes are not representative, dashboards can be sparse, and one provider’s result does not establish placement everywhere. Do not claim causation from simultaneous changes.

Tool-neutral prompt pack: turn delivery evidence into a safe diagnosis

Prompt 1 — Incident classification

Classify these redacted email events into submitted, accepted, deferred, rejected, inbox-confirmed, spam-confirmed, or unknown. Do not infer inbox placement from “sent,” opens, or clicks. Group by mailbox provider, message type, sending domain, and time. Identify missing evidence. Data: [redacted logs and observations].

Prompt 2 — Header review

Explain the SPF, DKIM, and DMARC results in this redacted message header. Check which domains were evaluated and whether the visible From domain aligns with a passing SPF or DKIM identity. Separate confirmed results from possibilities. Do not recommend changing DNS until you identify the exact mismatch. Header: [redacted].

Prompt 3 — One-change test plan

Given this incident record, propose one low-risk test for the leading hypothesis. Specify the consented test group, one variable, provider evidence, success and stop conditions, rollback, and limitations. Do not recommend blasting, domain rotation, or adding all senders to SPF. Record: [redacted evidence].

Stop-doing swipe file: replace deliverability myths with evidence

Stop: “SPF passed, so Gmail must put it in the inbox.” Use: “SPF passed for [domain]; we still need placement evidence and the DKIM/DMARC alignment and reputation checks.”
Stop: “Add every vendor to SPF.” Use: “Identify the actual envelope domain and authorized sending services, then have the DNS owner review the single valid SPF record.”
Stop: “It was a spam word.” Use: “We’ll check the recipient provider’s response, list expectations, complaints, links, and sender history before naming a cause.”
Stop: “Rotate domains and resend to everyone.” Use: “Pause the affected stream, verify consent and root cause, and test only with an appropriate opted-in group.”
Stop: “Open rates prove inbox placement.” Use: “Opens are an imperfect signal; we’ll use provider diagnostics, recipient reports, and clearly defined delivery events.”

Hook–Value–Template: report an email placement incident

Hook: “SPF and DKIM passed—but that does not tell us where every recipient saw the message.”

Value: Separate technical acceptance, authentication, domain alignment, provider reputation, complaints, and audience expectations so the team changes a cause supported by evidence.

Template: “From [date range], [message stream] sent through [service/domain] showed [confirmed response or placement] among [provider and segment]. The message header shows [SPF result/domain], [DKIM result/domain], and [DMARC/alignment result]. The evidence does not yet establish [unknown]. We will test [one cause] with [consented group], monitor [provider signals] until [date], and stop or roll back if [condition]. We will not resume full volume until [owner] confirms [technical and audience checks].”

Sources: provider sender requirements and diagnostics

Provider requirements differ by volume and message type and can change. Confirm the current rules for the recipient providers you actually send to. Authentication status alone is not proof of inbox placement or a guaranteed fix.