How to Send Outlook Newsletters with Email Communication Services

Use ECS to Send Outlook Newsletters to Thousands of External Recipients

After writing about the new Outlook Newsletters app last week, I was asked if any workaround existed to allow newsletters to be sent to external recipients. If you only need to send a newsletter to a few external recipients, the easy answer is to create an Exchange Online mail contact for each recipient. Assuming that a distribution list is used to distribute a newsletter, the mail contacts can be added to the distribution list membership and so receive their copy when the Exchange transport service expands the membership to dispatch the newsletter to its final destinations.

This approach works for any external SMTP address, defined as an SMTP address that doesn’t belong to one of the accepted domains registered for the tenant. I often use the technique to capture copies of messages sent to distribution lists as posts in a Teams channel. Figure 1 shows an example of such a mail contact. Note that the contact is hidden from address books to prevent its discovery by users who browse the GAL.

Scaling Up to Cope with External Recipients

However, adding individual mail contacts for external recipients is not a method that’s easy to scale up. You can automate the process with PowerShell by using the New-MailContact cmdlet to create mail contacts and the Add-DistributionGroupMember cmdlet to add mail contacts to a distribution list, but that’s probably too much trouble for the delivered value.

Besides, using distribution lists to send messages to large numbers of external recipients will run foul of the new tenant external recipient rate limit (delayed for implementation until 1 May 2025), not to mention the individual mailbox external recipient rate limit that’s due for implementation in October 2025. A better solution is required.

Sending an Outlook Newsletter with Azure Email Communication Services

Azure Email Communication Services (ECS) is a pay-as-you-go service based on Exchange Online that’s expressly intended to process external email sent at high volumes, like newsletters directed at customers. The problem is that Outlook Newsletters use “regular” Exchange Online and have no connection to ECS, so we need a way to bridge the gap.

My solution, imperfect and manual as it is, goes like this:

Create and send an Outlook newsletter as normal.
Open the copy of the newsletter in the Sent Items folder of the author’s mailbox (or the copy received by any recipient).
Copy the HTML body and paste it into a Word document. Make sure to select the keep source formatting option to remain the layout. The result should look something like the document shown in Figure 2.

Save the Word document as a web page (HTML file). The output HTML file should contain all the formatting instructions and pictures for the newsletter.

If you look at the script referenced in the article about ECS, you’ll see that the setup necessary to send a message through ECS using PowerShell is very similar to sending a message with the Microsoft Graph PowerShell SDK. Essentially, you create and populate a message structure before submitting it to ECS to be sent. Part of the message structure is the message body, which can be formatted as HTML.

When I worked with ECS last year, I discovered that ECS was very sensitive to the HTML in a message structure and refused to process HTML generated from Word. That issue seems to have gone away because I was able to load the HTML for the Outlook newsletter into a string variable like this:

[string]$HtmlContent = Get-Content Newsletter.htm

Next, I amended the script code to change the message subject and use the HTML content loaded in from the newsletter and used the code to send newsletters to several hundred email addresses as a test. Here’s the code that does the work.

[int]$i = 0
Write-Host "Processing messages... "
ForEach ($Recipient in $RecipientList.Email) {
    # Construct the TO addresses for the message
    [array]$ToRecipientAddress = Get-MessageRecipients -ListOfAddresses $Recipient
    $i++
    Write-Host ("Sending email to {0} ({1}/{2})" -f $Recipient, $i, $RecipientList.count)

    # Build a hash table containing the settings for the message
    $Email = @{
         # The sender's email address
        senderAddress = $senderAddress
        # Create a unique identifier for this message
        headers = @{
            id = ("{0}-{1}" -f (Get-Date -format s), $ToRecipientAddress.address)
        }
       
        # The content of the email, including the subject and HTML body
        content = @{
            subject   = "Office 365 for IT February 2025 Articles"
            html      = $HtmlContent
        }
        # The recipients of the email
        recipients = @{
            to = $ToRecipientAddress
            bcc = @(
               @{
                   address     = "o365itprosrenewals@office365itpros.com"
                   displayname = "Office 365 for IT Pros Support"
                }
            )
        }
        # The reply-to addresses for the email - doesn't have to be the same as the sender address
        ReplyTo = @(
            @{
                address     = "o365itprosrenewals@office365itpros.com"
                displayName = "Office 365 for IT Pros Support"
            }
        )
        userEngagementTrackingDisabled = $false
    }

    # Convert the email settings structure to JSON
    $EmailSettings = $Email | ConvertTo-Json -Depth 10
    $MailStatus = $null
    # Define the URI to post to when sending a message with ECS. 
    # The same URI is used for all messages. The body of the message dictates who receives the email
    $Uri = ("https://{0}/emails:send?api-version=2023-03-31" -f $CommunicationEndpoint)
    # Submit the message to the Email Communication service
    try {
        $MailStatus = Invoke-RestMethod -Uri $uri -Method Post -Headers $headers -Body $EmailSettings -UseBasicParsing
    }
      catch {
        Write-Host ("Failed to send email to {0}" -f $Recipient)
     }
   }
   Start-Sleep -Seconds 2
   $Recipient = $null
}

Combine Different Components to Solve a Problem

The results aren’t perfect. Some email clients complain that the messages contain trackers (used by Outlook Newsletters to track the number of recipients that open newsletters. Some clients can’t display the inline graphics (Outlook classic does the best job). Tweaking of the HTML before it is processed by ECS might fix these problems. It’s worth noting that we’re dealing with preview software sending messages through an unsupported route, so some difficulties are to be expected.

Even though this is a use that Microsoft doesn’t support, it seems possible to use Outlook Newsletters for what it’s good at (creating nice-looking newsletters) and send the output to as many external recipients as you want through ECS. Given the imminent limitation for external recipient traffic being imposed by Exchange Online, using ECS might just be a solution for those who depend on being able to send high volumes of email to customers. ECS is harder to set up than simply sending messages from Outlook, and its traffic costs money, but ECS does get the job done.

After Microsoft ships Outlook Newsletters, they might support the use of ECS. It seems like a sensible next step!

Need some assistance to write and manage PowerShell scripts for Microsoft 365? Get a copy of the Automating Microsoft 365 with PowerShell eBook, available standalone or as part of the Office 365 for IT Pros eBook bundle.

Cart

Cart