Dragging an image into New Outlook for Windows does not do what dragging an image into Classic Outlook did. That is the entire problem, and it is not a bug — it is a deliberate behavioural change that Microsoft made through the second half of 2025 and that catches people out every working day.

The short version: where you drag the image from, and where you drop it to, both change the result. Sometimes you get an inline image. Sometimes you get a traditional attachment. Sometimes — and this is the change that’s generating the most support tickets — you get a OneDrive cloud link masquerading as an attachment, which your external recipients then can’t open without an access request. None of this is obvious from the interface.

This is the complete behaviour map for the May 2026 build of New Outlook for Windows, with the workarounds where each behaviour is wrong for what you actually want.

The two axes that decide everything

Before the matrix, the two variables.

Axis one — the source. New Outlook treats each drag source differently because it sees different clipboard payload types from each one. A drag from File Explorer carries a file path. A drag from a browser image element carries an image URL (and sometimes a bitmap). A drag from the Snipping Tool overlay carries bitmap data with no underlying file. The editor inside New Outlook is a web component, and it makes different decisions based on what arrives at the drop event.

Axis two — the destination zone. New Outlook has two drop zones in a compose window: the message body and the attachment area (the strip above the body where existing attachments appear). The drop zone determines intent. Drop in the body and New Outlook assumes you want the image visible to the reader. Drop in the attachment area and New Outlook assumes you want a file attached, period.

Classic Outlook had this same two-zone model in theory, but in practice the message body was much more forgiving and would accept most drags as inline. New Outlook enforces the distinction strictly.

The behaviour matrix

SourceDrop in message bodyDrop in attachment area
File Explorer (single file)Inline image (image rendered in body)OneDrive cloud link (default) or traditional attachment (after intervention — see below)
File Explorer (multiple files)Each file inserted inline if they’re images, else attachedOneDrive cloud links by default
Browser image (from a webpage)Inline image, usually as a reference to the source URL — fragile, can break for recipientsBehaviour inconsistent; sometimes attaches, sometimes silently fails
Browser image (saved via right-click then dragged)Inline image, locally embeddedOneDrive cloud link or traditional attachment
Snipping Tool overlay (Win+Shift+S, then drag the toast)Not draggable from the toast — you must paste with Ctrl+V insteadSame — not a drag source
Snipping Tool window (after capture, drag from canvas)Inline image, embeddedSaves the snip first, then attaches — extra friction
Word, PowerPoint, or Excel selectionInline image (rasterised, not the original source object)Not a typical destination; behaviour inconsistent
Teams chat imageInline image, embeddedOneDrive cloud link to the Teams content
OneDrive web (drag from browser tab)Cloud link in bodyCloud link in attachment area
Drag from a different mailbox in OutlookAttached as message item — only works if ItemsToOtherAccountsEnabled is True in your OWA mailbox policySame

A few notes from the matrix that are worth pulling out.

When you drag a file from File Explorer into the attachment area of a New Outlook compose window, the default behaviour as of the October 2025 update is to upload that file to your OneDrive and insert a sharing link. Not a copy of the file. A link.

Microsoft frames this as cloud-first and a productivity win. In practice it generates a specific kind of failure: your recipient gets the email, clicks the attachment, and lands on a Microsoft sign-in page asking them to request access. If they’re outside your tenant — a client, a supplier, anyone external — they can’t get the file without you intervening.

The fix is to change the default. In a compose window, after attaching the file, the attachment chip has a small chevron next to it. Click the chevron, and one of the options is Attach as copy. Choose that, and the file is sent as a traditional attachment, the way Classic Outlook would have done it.

You can change the default for all attachments by going to Settings → Mail → Compose and reply → Default attachment behavior and selecting Attach as a copy. Most professional users should do this immediately. Microsoft’s cloud-first framing makes sense for files you genuinely want to share collaboratively. It makes no sense for the typical scenario of attaching a quote, a contract, or a report to an external email.

The screenshot tool problem

Capturing with Win+Shift+S and trying to drag the resulting toast notification into Outlook does not work in New Outlook. The toast is not a drag source. You have two viable paths.

The first is paste — capture with Win+Shift+S, click in the body of your message, press Ctrl+V. The image arrives inline. This is the workflow Microsoft Q&A consistently recommends, and it works reliably.

The second is to open the Snipping Tool window itself (not the overlay), capture, then drag the resulting image from inside the Snipping Tool window into the message body. This works but adds friction: it forces Snipping Tool to save the snip to a temporary file first, which is what makes the drag possible.

The reason this matters is that screenshot pasting is one of the highest-volume image insertion workflows in professional email, and the toast behaviour is a regression from Classic Outlook, where dragging the toast often worked.

Cross-account drag-and-drop

Microsoft rolled out cross-account drag-and-drop for emails and files in waves through July to October 2025. If you can’t make it work, the cause is usually one of three things.

Your organisation’s OWA mailbox policy may have ItemsToOtherAccountsEnabled set to False. This is a tenant-level setting. Your IT team controls it. There is no workaround for the user.

The accounts must both be configured in New Outlook. Drag-and-drop between New Outlook and a separate webmail browser tab does not work — they’re not the same app.

You will see a confirmation prompt the first time you drag content into a different mailbox. This is by design and is not a bug. The prompt does not appear for shared mailbox attachments.

Known regressions worth knowing about

The December 2025 cumulative update KB5070311 (OS Builds 26200.7309 and 26100.7309) introduced a regression where drag-and-drop from New Outlook to the desktop or File Explorer stopped working for many users. Microsoft has acknowledged this and shipped progressive fixes through Q1 2026, but reports continue. If you’ve updated recently and drag-out has broken, the workaround is to right-click the attachment and use Save as instead. We track this in the Microsoft Office Image Regression Timeline and update when the fix is verified.

Drag-and-drop is also affected by some virtualisation environments. AVD, Citrix, and other RDP-based sessions can intercept drag events at the protocol layer. If your users are on virtual desktops and drag-and-drop is broken, the cause is almost never New Outlook itself.

What we’d recommend

A practical workflow for a professional New Outlook user, given the behaviour above.

For external attachments (anything going outside your organisation), set the default attachment behaviour to Attach as a copy in settings. Don’t think about it again. Your external recipients will stop having access problems.

For screenshots, use Ctrl+V to paste. Don’t fight the toast.

For multiple files going to a colleague inside the org, the OneDrive link default is genuinely useful — you avoid sending a 40MB attachment that bounces off mailbox size limits.

For images you want inline in the body, drag from File Explorer directly into the body. Not the attachment area. The body.

The pattern is consistent once you see it: destination zone = intent signal. New Outlook respects that signal more strictly than Classic Outlook ever did. Once you stop expecting Classic’s forgiving behaviour, the matrix above stops being surprising.

For the broader behavioural divergence between the two clients — far more than just drag-and-drop — see our New Outlook vs Classic Outlook image handling guide. For the related case of pasted images landing as attachments instead of inline, see Inline images appearing as attachments. And for the closely-related question of why useful context-menu options have vanished, see Why right-click image options are missing.