How to Automatically Download Email Attachments from Microsoft 365

If your business regularly receives reports, invoices, spreadsheets, CSV files, PDFs, or other documents through email, there is a good chance someone is manually doing the same thing every day:

Open Outlook.
Find the right email.
Download the attachment.
Rename or organize the file.
Move it somewhere another process or person can use it.
Do it again tomorrow.

For a file you receive once, that’s no big deal.

For a report that arrives every morning, or dozens of files arriving throughout the day, it becomes a repetitive business process—and a good candidate for automation.

There are several ways to automatically find and download attachments from Microsoft 365. In this article, we’ll look at how email searching works, some of the technologies available, and when it makes sense to use a purpose-built automation tool instead.

What Are We Trying to Automate?

Let’s start with a real-world example.

Suppose a company receives a daily sales report with emails that look like this:

From: reports@vendor.com
Subject: Daily Sales Report - August 31, 2026
Attachment: DailySales_20260831.xlsx

Every morning, an employee finds the message, downloads the spreadsheet, and places it in:

C:\CompanyData\SalesReports\

Maybe another application imports that spreadsheet. Maybe someone uses it to update a report. Maybe it eventually gets loaded into a database.

The important point is that the email isn’t really the final destination.

Email is acting as a data source.

Once you start thinking about it that way, the workflow looks more like:

Mailbox → Find Message → Find Attachment → Download → Destination

And that can be automated.

Option 1: Searching Email with IMAP

IMAP—the Internet Message Access Protocol—is a standardized protocol for accessing email stored on a mail server.

Microsoft 365/Outlook supports IMAP access, although Microsoft requires modern OAuth authentication rather than relying on traditional username/password authentication. Microsoft’s published Outlook settings use outlook.office365.com, port 993, with SSL/TLS for IMAP.

Authentication is a subject of its own, so we’re going to skip that part here and concentrate on something more interesting:

How do you actually find the email you want?

Basic IMAP Searches

IMAP defines a SEARCH command with criteria including sender, recipient, subject, body content, dates, message flags and arbitrary headers. When multiple search criteria are supplied, they are implicitly combined with AND.

For example, suppose we want every email sent by our reporting vendor:

SEARCH FROM "reports@vendor.com"

Or perhaps we know the subject contains “Daily Sales Report”:

SEARCH SUBJECT "Daily Sales Report"

We can combine the two:

SEARCH FROM "reports@vendor.com" SUBJECT "Daily Sales Report"

That means:

Find messages where the sender contains reports@vendor.com AND the subject contains Daily Sales Report.

This is already much safer than simply downloading every Excel attachment that arrives in a mailbox.

Searching by Date

In an automated process, we probably don’t want to search ten years of email every morning.

IMAP provides date criteria such as SINCE, BEFORE, ON, SENTSINCE, SENTBEFORE, and SENTON. One subtle distinction is that SINCE operates on the message’s internal date, while SENTSINCE operates on its Date: header.

For example:

SEARCH SINCE 30-Aug-2026

Or combine it with our previous criteria:

SEARCH FROM "reports@vendor.com" SUBJECT "Daily Sales Report" SINCE 30-Aug-2026

Now we have a fairly specific query:

Find messages received since August 30, 2026, from our vendor, with “Daily Sales Report” in the subject.

Searching the Email Body

Sometimes the identifying information isn’t in the subject.

Suppose the vendor’s emails contain:

Attached is your daily production report.

IMAP provides a BODY search:

SEARCH BODY "daily production report"

We could combine that with sender:

SEARCH FROM "reports@vendor.com" BODY "daily production report"

There is also a TEXT search:

SEARCH TEXT "daily production report"

The distinction matters.

BODY searches the message body, while TEXT searches both headers and body content.

Searching Headers

IMAP also lets us search specific message headers.

For example:

SEARCH HEADER Message-ID "example.com"

Or a custom header used by another system:

SEARCH HEADER X-Report-Type "DailySales"

This can be extremely useful when integrating systems that add predictable metadata to their emails.

OR and NOT Searches

Things get more interesting when your criteria aren’t simple AND conditions.

Suppose a report could come from either of two addresses:

SEARCH OR FROM "reports@vendor.com" FROM "automated@vendor.com"

Or perhaps we want daily reports but want to exclude test messages:

SEARCH SUBJECT "Daily Sales Report" NOT SUBJECT "TEST"

IMAP supports both OR and NOT search keys for these kinds of expressions.

You can therefore build surprisingly useful mailbox filters using standard IMAP.

What About Attachment Names?

This is where things get a little more complicated.

You might want to say:

Find an email from reports@vendor.com where the attachment filename contains DailySales.

It would be convenient if standard IMAP had something like:

SEARCH ATTACHMENTNAME "DailySales"

It doesn’t.

The standard IMAP SEARCH criteria cover things such as FROM, SUBJECT, BODY, TEXT, dates and headers, but don’t define a general ATTACHMENTNAME search key.

An application can instead use IMAP to narrow down the candidate messages and then inspect their MIME structure and attachment metadata.

Conceptually:

SEARCH FROM "reports@vendor.com" SUBJECT "Daily Sales Report"

returns candidate messages.

The application then examines those messages:

			
Message
├── Body
├── Attachment: DailySales_20260831.xlsx
└── Attachment: ReadMe.pdf

Your automation can then apply another rule:

Attachment filename contains "DailySales"

and download only:

DailySales_20260831.xlsx

This distinction becomes important when building a reliable email automation system.

You’re no longer just searching email.

You’re searching messages, retrieving them, inspecting their structure, identifying attachments, applying additional rules, downloading files, and deciding what happens next.

A More Realistic Business Rule

Let’s put everything together.

Imagine the actual requirement is:

Every weekday, find emails received from reports@vendor.com containing “Daily Sales” in the subject. Only process attachments containing SalesReport in the filename and save Excel files into our reporting directory.

The first part can be expressed as an email search:

SEARCH FROM "reports@vendor.com" SUBJECT "Daily Sales" SINCE 30-Aug-2026

Then application logic handles the attachment criteria:

			
Filename contains: SalesReport
Extension: .xlsx
Destination: C:\CompanyData\SalesReports\

And suddenly our seemingly simple requirement has several components:

			
Schedule
    ↓
Connect to Mailbox
    ↓
Search Messages
    ↓
Retrieve Matching Messages
    ↓
Inspect Attachments
    ↓
Filter Attachment Names
    ↓
Download Matching Files
    ↓
Save to Destination
    ↓
Record Success / Failure

		

That’s the difference between an email search and an actual email automation workflow.

Option 2: Microsoft Graph

For Microsoft 365 specifically, another option is the Microsoft Graph API.

Graph provides APIs for working with Microsoft 365 resources, including mailboxes, messages and attachments.

For developers, Graph can be an excellent solution. You can build an application that authenticates with Microsoft, queries messages, retrieves attachments and integrates the results directly into another system.

It also gives you considerably more flexibility than a simple mailbox rule.

The tradeoff is that you’re now building software.

You need to deal with application registration and authentication, permissions, querying, pagination, attachment retrieval, error handling, scheduling, logging, deployment and ongoing maintenance.

For a highly customized integration, that may be completely reasonable.

For a company that simply wants:

“Every morning, find these emails and put these attachments here.”

building and maintaining a custom application may be more infrastructure than the problem warrants.

Option 3: Microsoft Power Automate

Power Automate is another natural option in the Microsoft ecosystem.

If your organization already uses Microsoft 365 automation heavily, a Power Automate flow may be an excellent solution.

A flow can react to incoming email, evaluate conditions, work with attachments and send data to other Microsoft services.

This is particularly attractive when the rest of the workflow already lives inside Microsoft’s ecosystem.

But not every organization wants another cloud workflow or wants its process tied to a larger automation platform.

Sometimes the requirement really is just:

Find these emails. Download these files. Put them here.

The Part That’s Easy to Underestimate

Finding an email isn’t particularly difficult.

Neither is downloading a file.

The work appears when you want the process to run unattended every day.

Now you have questions like:

What happens when there are no matching messages?
What happens when there are five?
How do you prevent accidentally processing the wrong attachment?
What happens if a file already exists?
How frequently should the mailbox be searched?
How do you change the search without changing code?
Where are files stored?
How do you know whether yesterday’s job succeeded?
What happens after a server restarts?
Who maintains the integration six months from now?

This is a pattern we’ve encountered repeatedly in business software.

The individual technical steps are often easy. Making the entire process reliable, configurable, and maintainable is the real problem.

A Simpler Option: ZenParse Email Extractor

This exact problem is why we built ZenParse Email Extractor.

Instead of developing and maintaining the mailbox automation yourself, you configure the criteria that identify the emails and attachments you actually want.

For example:

			
Sender:
reports@vendor.com
Subject contains:
Daily Sales
Attachment name contains:
SalesReport
Schedule:
Every weekday
Destination:
C:\CompanyData\SalesReports\

		

ZenParse handles the recurring process of finding the matching messages and extracting the files.

The important difference in our approach is that the extracted data doesn’t need to be sent to or stored on a ZenParse cloud service.

The application runs on your infrastructure, and you decide where the extracted files go.

That destination might be a local directory, network location, another data-processing workflow, or a location used by your reporting systems.

The goal isn’t to create another place for your data to live.

It’s to get your data out of the inbox and where it actually belongs.

Which Approach Should You Use?

There isn’t one correct answer.

Use IMAP or Microsoft Graph if you’re a developer building a highly customized integration and you’re comfortable owning the code and infrastructure.

Use Power Automate if your organization already uses the Microsoft automation ecosystem and the workflow fits naturally within it.

Use ZenParse Email Extractor if you want a purpose-built, configurable tool for recurring Microsoft 365 email and attachment extraction without building and maintaining the integration yourself—and you want the process running on infrastructure you control.

The important thing is recognizing that manually downloading the same files every day isn’t really an email task.

It’s a data pipeline that happens to start in an inbox.

And once you recognize it as a data pipeline, automating it becomes the obvious next step.

Like this:

Leave a ReplyCancel reply