The essentials
Start with the result you can prove
“Our emails are going to spam” is too broad to investigate. Replace it with a statement such as: “Two recipients confirmed that these message IDs were in Junk on Tuesday.” That tells you the observation, its scope and what you still need to find out. A low reply rate alone cannot provide that statement.
Microsoft documents several possible filtering factors and distinguishes rejection, Junk placement and throttling. Use the observed result to select an investigation; do not turn a list of possible causes into a finding about your campaign.
Record the earliest supported result and any later change. A message can be deferred before it is accepted. A recipient might move it after arrival. Keep those events in order so a later observation does not silently replace the original question.
References [1]
Put it into practice
Choose the evidence you actually have
Start with the result you can support, then use the evidence desk to choose your next check. If more than one result applies, put the events for one message in order before drawing a wider conclusion.
THE EVIDENCE DESK
What happened to the message?
Choose the closest supported observation. If several apply, follow the history of one message before grouping messages together.
Rejected
Read the complete failure
A terminal rejection gives you an explicit failure to investigate. The full response matters more than a shortened dashboard label.
- Save the full error or non-delivery report, including its text, code, timestamp and receiving system.
- Match it to the recipient and message ID; record whether the failure happened before acceptance or arrived later.
- Check which other messages show the same response and whether a recent change overlaps that group.
Next moveFollow the documented instructions for that response. Resolve the demonstrated issue before sending a corrected message; do not repeatedly resend the same failure.
Deferred
Find out whether it is still pending
A temporary response needs a timeline. A snapshot of an earlier attempt may no longer describe the message’s current state.
- Capture the full temporary response and the first and latest attempt times for the same message.
- Check the sending system’s documented queue state and retry handling; separate attempts from new messages.
- Look for a later acceptance or terminal failure and record the cutoff time if neither is established.
Next moveInvestigate the stated reason and monitor the existing queue according to its documented handling. Keep the outcome pending until the evidence changes.
Confirmed Junk
Inspect the recipient’s observation
A recipient-confirmed location is stronger placement evidence than an acceptance label. It still needs context before you infer a cause.
- Ask a cooperating recipient for the original message’s location, observation time and whether it was moved.
- Obtain the original headers or recipient administrator’s trace where available, linked to that exact message.
- Compare the affected messages with a relevant reference group and list the evidence that differs.
Next moveInvestigate a supported difference. If recipient policy or a suspected false positive needs review, prepare the evidence for the recipient administrator.
No reply
Keep placement unknown
Silence may justify a campaign review, but it does not tell you which folder held the message.
- Check for explicit failure, pending state or documented final acceptance for the same message.
- Seek a small, voluntary recipient check if appropriate; label the result as evidence about those messages only.
- Review audience fit and the request separately, recording what is observed and what remains a hypothesis.
Next moveLeave placement unknown unless you obtain destination evidence. Do not change authentication, domains or copy merely to make an unsupported spam diagnosis feel actionable.
This is a reading aid, not a live diagnosis. It does not connect to a mailbox, inspect a campaign or save your selection.
Put it into practice
Build one evidence bundle for the same message
Create one incident folder or record with a reference for each artifact. The useful connection is between the original message, its sending event, the receiving response and any recipient observation. Similar subject lines or nearby timestamps are insufficient when several messages could match.
Protocol acceptance means the receiving SMTP server issued a positive completion response after DATA. A 4yz response is temporary; a 5yz response is permanent for that transaction. Identify which receiving hop produced the response: submission to an intermediary is not evidence of acceptance at the intended recipient’s boundary.
Prefer an original message export or headers over a normal forward when asking for message-level evidence. Share only what the person investigating needs; redact unrelated recipient information while preserving the identifiers needed to join the records.
References [2]
The essentials
Find the smallest affected group
Start with a narrow comparison: the same sending identity, receiving ecosystem and period. Then ask whether the issue appears in one recipient organisation, one list source, one message version or a wider set. These are investigation boundaries, not claims that each factor caused the result.
Use Google and Microsoft as receiving groups when that distinction is supported, but keep organisation-level differences visible within them. A problem at one company does not establish a problem at every mailbox using that ecosystem.
Choose a reference group that answers a specific question. For example, compare the same message version before and after a configuration change. Note other differences that could explain the result. If no useful comparison exists, say so rather than constructing a clean baseline from unrelated successful messages.
A closer look
Let the evidence choose the investigation
Write a hypothesis as a question that the next artifact could answer. “Did this message use the intended authenticated identity?” is testable. “Our domain is burned” does not specify a finding or a repair. Use the specialist guide only when your evidence points toward its subject.
| Evidence in hand | Next question | Useful next action |
|---|---|---|
| A response names an authentication problem | Which identity or check failed for this message? | Compare the original result with the intended configuration; use the authentication guide. |
| Deferrals overlap a sending change | What changed, and does the response support that connection? | Inspect the timeline and queue; use the volume guide to review the plan. |
| Recipient evidence points to a local action | What action did the receiving organisation apply? | Ask its administrator to inspect the specific message. |
| A message change overlaps confirmed Junk observations | Which difference is worth testing? | Review that message using the spam-words guide without assuming a forbidden-word rule. |
| Only response rates changed | Is placement actually observed? | Keep the placement question open and review campaign fit separately. |
The essentials
Make one correction and define the retest
Correct a demonstrated error before designing an experiment. When the explanation is still uncertain, choose one change that could discriminate between plausible hypotheses. Record what stays comparable: audience criteria, receiving group, message purpose and observation method. Changing everything at once removes most of the value of the comparison.
Keep the retest bounded and appropriate to the campaign. Use relevant recipients, respect suppression and opt-out decisions, and avoid sending extra messages solely to generate reassuring numbers. Decide the observation window and stopping condition before you begin.
A useful result might be that the stated rejection no longer appears for the checked messages. That supports a claim about that rejection. It does not establish Inbox placement. A test account reaching Inbox supports a claim about that account and configuration. If the evidence is mixed or missing, retain that uncertainty and select the next evidence request.
- 01
State the hypothesis and the single correction.
- 02
Define the checked group, evidence source, cutoff and stop condition.
- 03
Compare observed results and decide whether to close, continue or escalate.
Put it into practice
Copy a diagnosis handover
A useful handover saves the next person from rebuilding the timeline. Keep observations separate from interpretations and attach references to the original artifacts. Give the investigator one concrete question rather than a demand to “fix deliverability.”
INCIDENT EVIDENCE HANDOVER
Copy this worksheet into your own document, then fill it in with your details.
Incident / owner: Observed result: Affected messages and recipients: Receiving ecosystem / organisation: Time window, timezone and current cutoff: Message identifiers and artifact locations: Sending identity and receiving hop: Full response or recipient observation: Attempt history and later events: Original headers / trace available: Scope checked and relevant reference group: Recent changes with timestamps: Confirmed facts: Hypotheses still unproven: Evidence missing and who can obtain it: Correction already made: Retest group, observation method and stop condition: Observed retest result: Question for the next investigator: Next owner and review time:
Keep this record with the original evidence in your team workspace. Include only the recipient information needed by the investigator, and leave credentials out.
The essentials
Close the incident at the level the evidence supports
Microsoft’s message trace can label a message Delivered even when it reaches Junk or quarantine. Ask for the action and destination when a trace is available; a headline status alone does not settle a placement question.
Close with a sentence that names both the improvement and its boundary: “The corrected messages no longer returned the named rejection in the checked group; recipient placement was not observed.” For confirmed Junk cases, preserve the message-level observation and the scope of any successful retest.
Escalate when the next useful evidence sits with a recipient administrator or when the documented response cannot be resolved with the information available. Include the handover and the precise question. Keep the incident open as unresolved if the evidence never establishes the outcome; an unknown result is more useful than a confident story that the next campaign cannot test.
References [3]
THE USEFUL RESULT
Turn a vague spam concern into a specific incident: an observed result, linked evidence, a bounded investigation and one clear next action. Preserve unknowns until the evidence resolves them.
A LITTLE MORE CLARITY
Your questions, answered.
Does passing authentication prove a cold email will reach Inbox?+
No. Passing an authentication check answers that check’s question. Use the actual message evidence to investigate a placement incident. Do not keep changing a correct configuration when the available evidence points elsewhere, and do not promise placement after a repair.
Should I rewrite the email as soon as someone reports spam placement?+
First preserve the original message and observation. A rewrite creates a different message to compare. Use content review when there is a reason to investigate it, and keep other relevant conditions comparable so the result can inform a decision.
Can I troubleshoot without recipient administrative access?+
Yes, you can collect your sending records, full responses, timeline and scope. Recipient-assisted evidence may still be needed to explain a local filtering action. State that access limit in the handover and request the smallest useful artifact.
When is a successful retest enough?+
When it answers the question you defined, within the group and window you checked. Record exactly what improved and what was not observed. A successful check is evidence for that scope, not a guarantee for later campaigns or other recipients.