A configured domain answers who sent the message. The next investigation asks whether mailbox providers see wanted mail.
The inbox drop that DNS cannot explain
The familiar diagnosis starts cleanly: you verify SPF, DKIM, DMARC, and DNS, then assume the inbox will recover. That logic is reasonable until every authentication check passes and placement still weakens. What do you inspect next? The symptom may appear as more messages going to spam, fewer recipients reading or replying, or delivery errors concentrated at one mailbox provider. Those observations belong to different data families. A configuration result tells you whether a provider can authenticate the sender. Recipient behavior and provider reputation data tell you how the mail is being received. Combining them into one vague deliverability score hides the branch that needs attention. Google's Gmail sender guidelines, checked in August 2026, make the split explicit. They require authentication and valid DNS while separately directing senders to avoid spam and respect recipient choice. Google's sender-issue guide, checked in the same month, also separates authentication from user choice, Postmaster monitoring, and spam-rate investigation. This is the article's single reversal: authentication is a necessary identity check, not proof that recipients want your message. A passed result closes one diagnostic branch. It doesn't close your case.
Separate identity data from recipient-response data
Keep the two data families visible in your incident record. In the identity column, you record the actual authentication and DNS results. In the recipient-response column, you record the complaint, reputation, engagement, unsubscribe, and delivery-error observations that the provider makes available. Don't turn an absent value into a healthy value. If a signal is unavailable, mark it unavailable and continue with the evidence you can inspect. This prevents a green authentication result from erasing a red recipient-response signal, and it prevents a weak engagement signal from being misreported as a DNS defect.
Rule out a real configuration failure first
Email deliverability is your ability to reach the intended mailbox destination; authentication is one input to that outcome, not a synonym for it. Begin with the cheap checks because a real failure there is actionable. You confirm that the provider reports authentication as passing and that your sending domain has valid DNS. Then ask whether your problem is broad or isolated to a provider. Google's diagnostic order, checked in August 2026, supports this sequencing: authentication is investigated, but user choice, Postmaster data, and spam-rate investigation remain separate steps.
A passing check changes the next question
Interpret your result literally. A failed check sends you back to configuration. A passing check means the sender identity branch is no longer your leading explanation; it doesn't mean your deliverability is healthy. Freeze unnecessary DNS edits while you inspect the next branch. Why? Repeated configuration changes create noise in your incident timeline. Your useful question is now whether the provider's recipient and reputation signals deteriorated before, during, or after the inbox change. The answer tells you whether to repair infrastructure or reduce unwanted-mail pressure.
Rank the non-DNS causes by what you can observe
Once authentication passes, rank your causes by observable evidence rather than by how easy they are to edit. You start with complaint and recipient-response signals, because they directly test your wanted-mail hypothesis. Next you inspect list accuracy and delivery errors, which can reveal addresses or destinations that shouldn't be receiving the current send. Then you inspect content and audience fit. Microsoft's Outlook.com sender support, checked in August 2026, treats list accuracy, junk-email complaint rate, recipients who never read or reply, content, and authentication as distinct diagnostic dimensions. That separation gives your workflow its order without pretending that one provider's signals are identical to another's.
- Compare complaint and recipient-response signals with the timing of the inbox decline.
- Check list accuracy and delivery errors for evidence that the current audience should be narrowed.
- Review whether recipients read or reply, then inspect content and targeting as a combined relevance problem.
- Return to authentication only if a fresh provider result or sending change reopens that branch.
Reconstruct the incident from the stopped action
Open the incident record at the moment a second DNS edit is about to be approved. Inbox placement has weakened, yet the provider still reports authentication as passing. That contradiction is the useful starting point. You stop the edit and reconstruct what changed around the affected send. The complaint observations and read-or-reply observations moved with one audience segment; the available authentication result did not. List-quality records and delivery errors now serve as rival explanations rather than boxes to complete. If they point to the same segment, the case against another domain change becomes stronger. If they point elsewhere, you keep the cause open. The team's next move follows from that branch: hold back the affected audience and message while leaving the passing configuration alone. This is a reconstructed troubleshooting example, not a measured customer result. It shows how a passing identity check can rule out the convenient action before the full cause is known. Google's and Microsoft's guidance, checked in August 2026, supports separating authentication from spam-rate, recipient-response, list-accuracy, and delivery-error investigation. It does not promise what the next placement observation will be.
Let the contradiction choose the next test
The record remains useful even when it cannot name one complete cause. A complaint movement supports the unwanted-mail branch; a read-or-reply change tests the relevance branch; delivery errors can pull the review toward list quality or one provider. Ask which observation contradicts the action you were about to take. When authentication stays passing, it contradicts more DNS work. When recipient and list signals do not move with the incident, they weaken the case for narrowing that audience. You are using each observation to eliminate a branch, not to manufacture a verdict. If none of the signals follows the incident window, preserve that uncertainty and escalate the record instead of claiming a diagnosis.
Match the correction to the confirmed branch
If authentication fails, you repair authentication or DNS and verify the provider result again. If list accuracy or delivery errors are your visible problem, you suppress invalid or unsuitable records and review how they entered the audience. If complaints or persistent non-engagement are your visible problem, you reduce pressure on that segment, narrow targeting, and revise the message around evidence the recipient can recognize. Microsoft's sender guidance, checked in August 2026, is useful here because it keeps authentication, list accuracy, complaints, recipient response, and content as separate dimensions. Your remedy should preserve that separation. The observable result isn't an instant promise of inbox recovery. It's a cleaner test. A narrower audience and lower pressure should make your next set of complaint, recipient-response, and delivery-error observations easier to interpret. Keep one change associated with one incident record so you can tell which branch it addressed. In an OKKI Go prospecting workflow, you preserve the list source, audience rationale, message evidence, owner, and provider observations together rather than handing a sender only a domain-level diagnosis.
- Authentication or DNS failure: repair the failed configuration check, then verify the provider result.
- List accuracy or delivery-error problem: remove unsuitable records, trace the list source, and prevent the same records from re-entering the send.
- Complaint or recipient-response problem: narrow the segment, reduce message pressure, and require a clearer account-specific reason for contact.
- Content problem without a clean segment signal: change the message separately from the infrastructure so the next observation remains interpretable.
Keep the next test smaller than the incident
Do not restart the original sending pattern merely because one configuration screen is green. Resume cautiously with the branch you corrected and compare the same class of observations. If the signal does not improve, return to the cause tree rather than piling another unrelated change onto the test. This boundary protects the diagnosis from becoming a sequence of guesses. It also makes the operating record useful to whoever has to review the incident later.
Escalate when the evidence cannot isolate a branch
Escalate when provider signals conflict, the affected segment cannot be reconstructed, or authentication and recipient-response observations change together. Bring the incident timeline, authentication results, list source, audience definition, message version, sending changes, and available complaint, engagement, and delivery-error observations. A useful tool is one that preserves those fields and their timestamps; a dashboard that compresses them into one health score cannot explain which branch changed. Microsoft's documentation, checked in August 2026, supports keeping the dimensions distinct even though it does not prescribe a universal escalation threshold.
The escalation packet should make one decision possible: continue configuration work, correct audience and message pressure, or collect missing evidence before sending again. OKKI Go can sit in the prospecting side of that record, where account selection and outreach context are kept visible, while mailbox-provider tools remain the authority for their own reported signals. Do not ask either system to invent the other's evidence. The diagnosis is complete when the next action follows from a visible branch, not when every screen has been edited.
What the escalation packet must preserve
Preserve the fields that let a specialist distinguish sender identity from recipient response. The packet should show the provider result, the audience and list source, the message version, the available recipient observations, and the delivery errors without merging them into one unlabeled score. Microsoft treats these as distinct dimensions, so the escalation record should do the same. That structure lets the reviewer identify missing evidence before recommending another change.
- Identity branch: provider authentication result and DNS status.
- Recipient branch: complaints, read-or-reply observations, and unsubscribe context available from the provider.
- Audience branch: list source, accuracy, suppression history, and the reason each account was selected.
- Delivery branch: provider-specific delivery errors and the sending changes that preceded them.
- Decision record: the branch being corrected, the owner, the next observation, and what would reopen the diagnosis.
A passing authentication result should reduce the investigation, not end it. Follow the visible branch: repair configuration when identity fails, or correct audience and message pressure when recipient signals do.
Frequently asked questions
Why can inbox placement fall after SPF, DKIM, and DMARC pass?
Authentication identifies the sender; it does not establish that recipients want the message. Provider guidance separates authentication from complaints, reputation, recipient response, list accuracy, unsubscribe, and delivery-error signals, so the next investigation should move to those branches.
Which signal should be checked before editing DNS again?
Confirm that authentication and DNS actually pass, then compare available complaint, recipient-response, reputation, list-accuracy, unsubscribe, and delivery-error observations with the timing and segment of the inbox decline.
When should a deliverability team return to configuration work?
Return when a provider reports an authentication or DNS failure, or when a fresh sending change reopens that branch. A passing check should move the investigation to recipient and provider signals instead of triggering another speculative edit.
What should be preserved when the cause remains uncertain?
Preserve the incident timeline, provider results, list source, audience definition, message version, sending changes, and all available complaint, engagement, and delivery-error observations. Mark unavailable data as unavailable rather than converting it into a healthy result.