A copier's “sent” message is a clue, not a complete account of delivery. Before changing credentials or sending the document again, connect the device event to the email service's evidence and the recipient's experience. This reduces repeated scans, accidental duplicates, and tickets that cannot be investigated.
Use this procedure alongside the Microsoft 365 scan-to-email guide. It is intended for authorized support staff; it does not authorize access to another person's mailbox or removal of security controls.
Preserve the first useful facts
Ask the user for the device identifier, approximate time with time zone, intended recipient, and the visible result or error. Record whether they scanned once or tried several times. Use a short neutral incident identifier, such as “SCAN-TEST-04,” for any controlled reproduction.
Avoid attaching the actual business document to a support ticket unless it is necessary and permitted. A synthetic document with a similar page count and file type is usually a better first test. Preserve full error text when it can be collected safely; redact credentials and unrelated recipient data from screenshots.
Build a three-part evidence record
| Observation point | Useful evidence | What it does not prove |
|---|---|---|
| Device | Job time, destination, result, job identifier | The person opened the attachment |
| Email service | Matching transport events and status | Every later user action |
| Recipient | Message location and attachment usability | Which upstream step caused an earlier failure |
Do not merge these into one ambiguous “email worked” checkbox. If one layer is unavailable, mark it unavailable and identify the owner who can obtain it.
Search the email service with a bounded question
Microsoft's message trace documentation explains how authorized administrators can see whether Exchange Online received, rejected, deferred, or delivered a message. In the Exchange admin center, message trace is under Mail flow. Search using the sender, recipient, and an appropriate time range, accounting for the time zone. Retain the matching message identifier when available.
Start broad enough to tolerate an inaccurate device clock, then narrow using the evidence. If a query returns no match, verify the sender actually used by the device and whether the message traveled through the service you searched. A missing result from an incorrectly scoped query is not proof that the copier never submitted anything.
Interpret the boundary of the result
If the device records a connection failure, investigate that stage with the device and network owners. If the service shows rejection, preserve the actual diagnostic details for the email administrator. Do not replace the error with an assumed diagnosis such as “Microsoft blocked the printer.”
For pending or incomplete evidence, record the current state and revisit it according to the service's reporting behavior. Avoid immediate repeated submissions that could later arrive as duplicates. If transport indicates delivery, move to authorized recipient-side checks: the relevant mailbox, expected folder, filtering outcomes, rules, and the attachment itself. Delivery evidence does not establish that a person read the message.
Reproduce one variable at a time
Use the dummy-document test plan to compare a small PDF with the failing file's general characteristics. Keep the sender, recipient, and route constant while changing one factor. Record each attempt separately, including successful controls.
For example, if a one-page synthetic PDF arrives and a longer synthetic PDF does not, that is a useful comparison, not a confirmed size-limit diagnosis. Preserve measured file sizes and the actual error before choosing a remedy. Do not send progressively larger real customer documents to explore a limit.
Hand off a concise support packet
A useful escalation contains the device and firmware reference, approved sending route, timestamps, sender and recipient, test identifier, exact sanitized error, and the last stage with confirmed evidence. Include what changed recently and what was tested without changing settings.
End with a precise request: “Please check why this test was rejected at the connector,” or “Please confirm which destination the device submitted.” Avoid asking every team to investigate everything.
Close the incident after a controlled retest succeeds and the workflow owner confirms the expected outcome. Record the verified cause if established; otherwise distinguish the observed recovery from an unproven explanation. That distinction makes the next incident easier to solve.
Editorial review: October 14, 2026. Workflow examples are illustrative. Verify current service guidance and device-specific documentation before configuration changes.