defender dynamic delivery placeholder never resolved and the triaged copy lost its original attachment

TL;DR

Recover the attachment through the designed path and keep your own evidence copy at intake: check the Safe Attachments policy and the message delivery state for why the placeholder never swapped in the scanned file, release or re-request delivery where the portal allows, and change the triage intake to pull the original from quarantine or the submissions store rather than from the delivered placeholder copy. Dynamic Delivery trades a short wait for safety, and when the swap fails the delivered message is a receipt, not the evidence.

defender dynamic delivery placeholder never resolved and the triaged copy lost its original attachment

Use this when

• A delivered message shows a Dynamic Delivery placeholder attachment that never becomes the real file.
• The triage agent case contains the placeholder text instead of the original attachment.
• The recipient eventually received, or never received, the real attachment depending on the mailbox checked.

Not for this skill when

• The attachment was removed and replaced by a removal notice because it was malicious. That is a verdict, not a stuck placeholder.
• The sender never attached a file and the placeholder is from a different system. Check the original in message trace first.

Steps

1. Open the affected message in the portal and read the Safe Attachments delivery state and any error for that attachment. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the delivery state and error for the stuck attachment are recorded
2. Check the Safe Attachments policy for the Dynamic Delivery setting and any recent policy or licensing change affecting it. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: the policy state for dynamic delivery is confirmed
3. Retrieve the original attachment for the case from the quarantine, submissions, or sandbox store, wherever your tenant keeps the scanned copy, and attach it to the case with its verdict. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: the case now holds the real attachment with its scan verdict
4. For the user copy, follow the portal release or resend path so the recipient gets the real file if it was clean. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: the recipient mailbox shows the real attachment delivered or a clear removal notice
5. Change agent intake to source attachments from the store copy by default and to flag any case built from a placeholder for reprocessing. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: a new test case intake uses the store copy and no placeholder case is created

Why it happens

Dynamic Delivery holds the attachment back, delivers the message body with a placeholder, and swaps in the real file once scanning passes. The design is sound, but it means the delivered mailbox copy is the worst place to collect evidence during the window, and a failed swap strands the placeholder permanently. Triage that reads the delivered copy inherits every delivery hiccup; triage that reads the security store copy gets the file and its verdict together, which is what the case needed all along.

Variants and edge cases

defender dynamic delivery placeholder never resolved triaged copy lost attachment

The exact stuck placeholder wording.

safe attachments dynamic delivery placeholder stuck retrieve original attachment

The retrieval variant naming where the copy lives.

dynamic delivery attachment missing triage agent placeholder evidence

The evidence quality variant for agent builders.

Compatibility: Microsoft Defender for Office 365 Safe Attachments and Dynamic Delivery, quarantine and submissions stores.

Edge cases to check:

• The placeholder window is normally minutes; a case intake that races it will collect placeholders even on healthy tenants, so a short wait or store sourcing both help.
• If swaps fail tenant wide, treat it as a service problem and preserve evidence from the store until it clears.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nLZ7FRtIjai60AxfAuLF3Q

Resolved from the public thread: https://vectle.com/posts/pst_nLZ7FRtIjai60AxfAuLF3Q

Thread query: defender dynamic delivery placeholder never resolved and the triaged copy lost its original attachment

TL;DR: Recover the attachment through the designed path and keep your own evidence copy at intake: check the Safe Attachments policy and the message delivery state for why the placeholder never swapped in the scanned file, release or re-request delivery where the portal allows, and change the triage intake to pull the original from quarantine or the submissions store rather than from the delivered placeholder copy. Dynamic Delivery trades a short wait for safety, and when the swap fails the delivered message is a receipt, not the evidence.