SPF, DKIM, and DMARC answer questions about authorization, signatures, and domain alignment. They do not certify that recipients want a message or promise a folder. A message can pass all three checks and still be observed in Spam. Treat successful authentication as one established technical condition, then investigate reputation, sending behaviour, content, and recipient expectations using evidence appropriate to each question.
Verify what actually passed
Inspect Authentication-Results on a received copy at the receiver's trusted boundary. A DNS checker showing a published SPF record is not proof that this particular message passed SPF. Likewise, an existing DKIM key does not prove that the sender signed the message correctly or that the signature survived the route.
Record the authenticated domains. SPF commonly evaluates the envelope-sender domain against the connecting IP. DKIM validates a signature associated with its signing domain. DMARC connects an aligned passing authentication result to the visible From domain. A provider-owned SPF domain can pass while failing to align with your brand's From domain; a separate aligned DKIM pass may still satisfy DMARC. Avoid summarizing this as one undifferentiated green DNS check.
Understand the boundary of the result
A malicious or unwanted sender can authenticate mail from a domain it legitimately controls. That is why the receiver still needs other filtering signals. RFC 9989 explicitly distinguishes authorization of the author domain from a judgement that delivery to the inbox is desirable. Authentication reduces ambiguity about domain use; it does not replace the receiver's responsibility to evaluate the message.
The same limit applies in reverse. An authentication failure can be highly relevant, but indirect mail flows and message modifications need investigation before attributing it to deliberate impersonation. Compare the original direct route with forwarding or gateway processing, and keep trusted receiver results separate from arbitrary headers supplied by an untrusted sender.
Diagnose an authenticated copy in Spam
First preserve the raw copy, observed folder, sending time, message identifier, and route. Confirm that the alleged successful authentication belongs to that copy. Then inspect the actual sending IP, From domain, signing domain, and link domains. A different outbound pool or tracking domain may explain why two apparently identical brand messages are not equivalent tests.
Review recent changes in audience, frequency, volume, and message purpose. Check for complaints, invalid-address responses, suppression mistakes, and broken unsubscribe handling in the sending system. Where available, consult the receiving provider's own diagnostic tools. A seed placement observation does not identify a specific subscriber complaint or expose all private reputation inputs.
Test a correction without weakening the message
Choose one evidence-backed defect, such as broken signing on a production stream, an unexpected redirect, or an incorrect sender identity. Correct it and send a fresh representative test. Retain the required unsubscribe controls and the real campaign content. Compare the same mailbox set at a similar observation stage, with unresolved and unavailable results still visible.
If authentication was already valid, adding duplicate DNS records or changing policy repeatedly is unlikely to produce an interpretable experiment. Document the verified authentication baseline and move to the next question. Preserve the distinction between a necessary technical correction and a claim about a receiver's undisclosed reason for Spam placement.
Frequently asked questions
Should I make DMARC stricter to force Inbox?
No policy setting guarantees Inbox. Change DMARC policy through an understood domain-protection rollout, checking legitimate senders and alignment rather than using enforcement as a folder switch.
Does DKIM authenticate every link?
No. A signature protects selected message content and identifies a signing domain. It does not certify that each linked destination is trustworthy, functional, or wanted.
Can an authentication pass be reused for the next campaign?
It is evidence for the observed copy and route. Preserve configuration, but verify new routes and changes with actual received messages because operational differences can affect authentication.
Sources and scope
Source check: November 5, 2026. Source checking is separate from publication. Observations apply to the tested copies and conditions.