Sending Email with PowerShell and Exchange Online

A State of Constant Refresh

Part of what we do to keep the Office 365 for IT Pros eBook updated is to revisit text over time. Microsoft makes subtle changes in Office 365 all the time, and the possibility always exists that a change affects what we’ve written. And there’s always the opportunity to rewrite text to make it clearer or more concise, or simply to include new facts and insights that we have learned since, or to correct errors that crept into the text for one reason or another.

Refreshing Chapter 6

This week, I reviewed the section about sending email with PowerShell in Chapter 6. Apart from anything else, I want to upgrade the script to find obsolete Office 365 Groups and Teams to send email to prompt owners to do something if their group has fallen into disuse.

The Send-MailMessage cmdlet sends an email message using an SMTP connection to submit the message to a server. There are a ton of different posts available to read about sending email with PowerShell, but Microsoft has been rolling out some changes in SMTP client authenticated submission protocol recently, so it’s good to revisit the situation. One of those changes is very welcome in that Exchange Online now keeps copies of messages in the Sent Items folder of the sending mailbox, which removes the need to include the sender in the recipient list.

In an interesting article called “How to set up a multifunction device or application to send email using Office 365“, Microsoft describes three methods for sending email in Office 365:

• Client submission. This method is the traditional approach and uses an Exchange Online mailbox. Messages sent can be traced in the normal manner.
• Direct send via the tenant’s MX endpoint. This choice is best when you need appliances to send messages via Office 365, when you only need to send email (like notifications) within the tenant, and for bulk delivery. Messages sent this way cannot be traced because their progress is not logged.
• Connector relay. This method is best used when messages always originate from a fixed IP address.

For details about each method, see the article.

Client Submission Best for My Purposes

I tried the client submission and direct send before settling on client submission. Sending email via the MX endpoint is faster because you don’t need to authenticate and don’t use a mailbox. However, the lack of tracing is a big issue when dealing with email, and I also ran into some odd situations that I still quite don’t understand. For instance, messages seemed to be sent successfully, but they never turned up in the recipient’s mailbox. This happened intermittently and unpredictably, which is always bad.

Being Listed as a Spammer

Another issue to consider when sending email to the MX endpoint, especially you’re testing a script repeatedly, the danger exists that your activities seem awfully like what a spammer might do when viewing through the lens of the Office 365 anti-malware checks. I duly ran into this problem and was rewarded with:

Send-MailMessage : Mailbox unavailable. The server response was: 5.7.606 Access denied, banned sending IP [51.171.212.192]. To request removal from this list please visit https://sender.office.com/ and follow the directions. For more information please go to http://go.microsoft.com/fwlink/?LinkID=526655

The link brings you to a page containing instructions about how to delist a blocked address using the Office 365 Anti-spam IP delist portal. Basically, Office 365 saw the stream of messages generated over a short period from my IP address and concluded that I was up to no good.

The delisting process is straightforward. Head to the IP delist portal (see below) and:

• Insert the email address used as the SMTP from address to send messages with the Send-MailMessage cmdlet.
• Insert the IP address reported by PowerShell.
• Solve the Catcha puzzle and submit.

About 30 minutes later, you should be able to send email again from the IP address.

Submission Limits

If you choose to use the client submission method, another issue you might run into is that Exchange Online limits a user to sending 30 messages per minute. This limit is easily exceeded when you generate and send messages with PowerShell, so it is wise to build in a short 2 second delay after sending each message. Another limit that is less easily reached is that a mailbox can send messages to a maximum of 10,000 recipients per day.

In any case, I’ll return to this topic when I’m finished updating the scripts – and the section in Chapter 6.

---

We like PowerShell, so it’s liberally sprinkled throughout the chapters of Office 365 for IT Pros. Sometimes we make mistakes in our code, but that’s the joy of PowerShell – it’s easy (normally) to fix.