Generating a document from a flow is the easy half of the job. Getting it out the door by email runs into a ceiling most people never check, until a flow that worked fine in testing starts failing in production for no obvious reason.
Exchange Online allows a message up to 35 MB by default, and a tenant admin can raise that ceiling to 150 MB, according to Microsoft's Exchange Online service description. The Office 365 Outlook connector inside Power Automate ignores both of those figures. Per Microsoft's connector reference, it caps a single attachment at 4 MB. A file Exchange would deliver without complaint gets rejected before it reaches a mailbox, because the connector's own limit sits under Exchange's default by close to a factor of nine.
The Office 365 Outlook connector's 4 MB attachment limit
That 4 MB figure is per attachment, not per message. Microsoft's connector documentation lists a separate ceiling for the message as a whole, 49 MB of content, which then gets base64-encoded for transport and lands at whatever the practical limit works out to after that encoding. A message with several smaller files can still add up past what the connector will carry, so a flow can fail with an attachment that's too large even when no single file crosses the 4 MB bar on its own.
None of this shows up until send time. A flow that generates and sends a document in one step will produce the file successfully and then fail at the point it hands the attachment to the connector, because generation and the size check are two separate operations with two separate outcomes. The file exists. The email doesn't go.
What Exchange Online allows by default
Set the connector aside for a moment and look at what Exchange Online itself permits. The default maximum message size is 35 MB for sending and 36 MB for receiving, according to Microsoft's Exchange Online service description. A tenant admin can change that. The configurable range runs from 1 MB up to 150 MB, and that setting applies organisation-wide, to inbound, outbound, and internal mail alike, and it counts attachments as part of the total.
Outlook on the web works to a different number. Its maximum message size is 112 MB before the base64 encoding adjustment gets applied, and its maximum attachment size is also 112 MB, against 150 MB for the desktop Outlook client. A single message can carry up to 250 file attachments before Exchange's multipart limit kicks in, entirely separate from the size ceiling.
Those 35 MB, 36 MB, and 1 to 150 MB figures are what a tenant admin actually controls. The connector's 4 MB attachment cap sits outside that setting entirely, so raising the Exchange message size limit to 150 MB changes nothing about what the Office 365 Outlook connector will accept.
What Base64 encoding does to the size
Every one of those numbers assumes the attachment has already been through Base64 encoding, and that step is not free. Base64 turns every three bytes of the original file into four characters of encoded text, an inflation of roughly 33 percent, according to Microsoft's Exchange Online service description. Take a 3 MB PDF as an example. Encode it, and it lands at around 4 MB, which happens to be exactly the connector's per-attachment ceiling. A file that looks comfortably under the limit on disk can arrive at the connector already sitting on the line.
Microsoft's own routing makes the same math visible at larger scale. A message can reach 150 MB when it stays inside Microsoft's datacenters, but once it routes outside them, the same 33 percent encoding increase applies and the practical limit drops to 112 MB. Outlook on the web builds the adjustment in from the start. A mailbox configured for a 100 MB maximum can actually send only 75 MB, because OWA restricts the sendable size to 25 percent less than the configured maximum to leave room for encoding.
That 33 percent figure is a floor. Microsoft's documentation notes the increase can run higher depending on the attachment's file size, type, compression, and which email client handles it.
Dataverse attachment limits and what happens when you exceed them
Dataverse runs its own ceiling on top of all this, and it applies whenever a file gets attached to an email activity, a note, or a web resource. The default maximum attachment size is 5 MB per file, according to Microsoft's documentation on attachment and annotation files, governed by an organisation setting called MaxUploadFileSize. An admin can move that setting anywhere from 1 MB up to 128 MB. Files under 4 MB can be assigned directly to the ActivityMimeAttachment.Body field; anything larger has to go through a chunked upload using InitializeAttachmentBlocksUpload, UploadBlock, and CommitAttachmentBlocksUpload, because Dataverse stores every attachment as a base64-encoded string in that same field.
What happens once you cross one of these lines depends entirely on which line it is, and the difference matters for how you monitor a flow.
Cross MaxUploadFileSize in Dataverse and you get a specific, catchable error. Microsoft documents it as unManagedidsattachmentinvalidfilesize, error code 0x80044a02, with the message Attachment file size is too big. That error stops the operation and shows up in the flow run. Cross the Exchange message size limit and the outcome looks different. The message fails delivery and the sender gets a non-delivery report, which arrives as a bounce rather than a failure inside the flow that sent it. If nothing downstream reads that mailbox for NDRs, the flow run shows success while the recipient never got anything.
Some failures don't even produce a bounce. Approval attachments only get included on the notification email automatically if their combined size is under 5 MB, according to Microsoft's support documentation on approval attachment limitations; anything larger stays available inside the Power Automate portal, but it simply doesn't appear on the email, with no error raised anywhere. Microsoft's troubleshooting guidance also notes that an email can fail silently if the connector's authentication has expired or the connection is broken, and that hitting a mailbox's send rate limits can cause later emails in a batch to drop or fail with no explicit error. A flow built to alert on failed runs will miss every one of these.
Sending documents in volume
Throttling adds a second ceiling on top of size, and it shows up whenever a flow is generating and sending many documents in a loop. The Office 365 Outlook connector allows 300 API calls per connection per 60 seconds, per Microsoft's connector reference. It also caps the total mail content moving through a connection at 500 MB per 5 minutes for Send email actions specifically, and at 2,000 MB per 5 minutes across all actions on that connection combined. A flow with a tight loop over a large recipient list can hit the calls-per-minute number long before it gets close to either content cap. Retries add their own risk in the same loop. Microsoft's connector reference notes that requests returning a 504 Gateway Timeout get retried up to four times by default, which can send the same document out twice if the original request actually succeeded before the timeout was reported.
Exchange layers its own limits on top. A single message can carry up to 1,000 recipients, and per Microsoft's Exchange Online service description, that same figure is both the default and the highest a tenant admin can configure it to, so there's no headroom to raise it further. Per mailbox, the daily figure is 10,000 recipients in a rolling 24-hour window, and once a mailbox crosses that line it can't send anything else until enough of those 24 hours have rolled off. Distribution groups get expanded to their individual members before any of this gets counted, including nested groups. On top of the per-mailbox number, a tenant-wide External Recipient Rate Limit, or TERRL, scales with how many licences the tenant holds, and trial tenants are capped at 5,000 external recipients a day regardless. Mail sent from a default onmicrosoft.com domain runs into a tighter rule again, 100 external recipients per organisation in a rolling 24 hours, and going over it returns a non-delivery report with code 550 5.7.236. Separate from all of that, Exchange limits outbound message rate to 30 messages per minute per mailbox, though exceeding it just spreads the excess into the following minutes rather than blocking the account outright. If you're generating and sending documents to a long list of recipients, these are the numbers that decide whether the run finishes clean or starts dropping mail partway through.
Shared mailboxes and service accounts follow most of the same rules as a regular user mailbox. The recipient and rate limits are identical, 10,000 recipients per 24 hours and 30 messages a minute, and both are exposed to the per-mailbox and tenant-wide external recipient limits. Where they differ is storage and licensing. A shared mailbox with no licence attached is capped at 50 GB of storage; attach an Exchange Online Plan 2 licence to it and that rises to 100 GB. The mailbox itself doesn't need its own licence to send mail, but whichever user or service account is driving the flow through it does need an Exchange Online licence of their own.
None of these numbers move for a document that's already sitting at 8 MB. At that size, the Office 365 Outlook connector rejects it outright, because its 4 MB per-attachment cap stays fixed regardless of what Exchange or Dataverse would allow above it. Routing the same send through Dataverse's SendEmail action avoids the connector's limit entirely. Microsoft's Web API reference for SendEmail documents no separate attachment limit beyond MaxUploadFileSize, so the ceiling becomes whatever that organisation setting allows, up to 128 MB. For a document already too large for the connector, that's the route with the most room to work with.