The SharePoint SendEmail API, known as SP.Utilities.Utility.SendEmail, is an API utilized to send email from within the context of SharePoint. This may include usage within Power Automate, custom code, custom workflows, and web parts within SharePoint.
The SendEmail API is referenced via REST in the following way (“/_api/SP.Utilities.Utility.SendEmail”) while for CSOM, it would be “Utility.SendEmail”.
Important
- Please ensure that you follow the guidance and identify and update any use of the API prior to the end-of-life date of October 31st, 2025. No further emails will be sent after this date.
- Please review the updates that are sent to the Microsoft 365 message center related to the retirement of this API.
- SharePoint workflows will not be affected by this change. Please refer to SharePoint 2013 Workflow retirement.
- Any out-of-the-box feature in SharePoint, which is sending emails, is not affected by this change.
- This change is only impacting SharePoint Online and has not impact on SharePoint on-premises deployments
Steps to follow
- Identify usage of the Utility.SendEmail API within custom code, custom workflows, or through Power Automate including “SharePoint Send HTTP Request flow action in Power Automate“.
- For Power Automate, update the API to utilize the Outlook connector (“Send an email”) within the Actions. (More information is available at Overview of using Outlook and Power Automate – Power Automate | Microsoft Learn)
- For custom code, or custom workflows, utilize Microsoft Graph user:SendMail API (Automate creating, sending, and processing messages using the Outlook mail API – Microsoft Graph | Microsoft Learn).
I have an SPFX solution with 2 different versions 10> and 14>
Will the code below be affected?
Option 1-------
import { sp, Web } from "@pnp/sp/presets/all";
public async _sendEmail(emailFrom: any, toEmails: any[], ccEmails: any[], bccEmails: any[], emailSubject: string, emailBody: string) {
const emailProps: IEmailProperties = {
To: toEmails,
CC: ccEmails,
BCC: bccEmails,
...
Will the code below be affected?
private async sendEmail() {
const emailProps: IEmailProperties = {
To: [“user2@site.com”],
Subject: “Test Subject”,
Body: “
Body of the message
“,
AdditionalHeaders: {
“content-type”: “text/html”
}
};
try {
await this._sp.utility.sendEmail(emailProps);
} catch (error) {
console.log(error)
}
}
This piece of code is using non-documented API access (not directly CSOM or REST) and is specifically hitting .sendEmail – so it will be impacted on this change.
Will this affect the REST calls that use this function on the servers versions of SharePoint(SharePoint 2013,2016,2019, Subscription Edition, etc…) ?
This change is announced for the SharePoint Online.
> The API has existed for more than 20 years
That’s a reason to keep it, not destroy it. What exactly is the problem with it? SharePoint has many OOB features that send mail, so SharePoint can’t be removing all code relating to sending mail. Surely `SendEmail` is already just a thin wrapper around that.
Churn for churn’s sake.
—-
Regardless, if you really must kill it, step 1 “Identify usage of the Utility.SendEmail” is completely un-actionable.
Surely some reporting is in the works?
What will happen after the shut off date? an exception? silent dropping of messages?
Hi James, as you mentioned it is an old API which was introduced ~20 years ago and we cannot keep backwards compatibility for APIs for such an extended period especially when there are more modern APIs available. We also have no way to assess, view, or report how any customizations are implemented as that is ideally what would be needed but is not something we can provide. We are reviewing feedback and options to provide better support in this area and will continue update this post as it becomes available.
At the end-of-life date, an exception would be thrown, and...
Great suggestions and good questions. Let me route those to the feature crew and hopefully we can get some movement here on those.
I believe SP 2013 workflows uses this API for Send Email action. So, the timeline should impact with retirement of SP 2013 workflows. Is there any action plan to support them?
Hi Praveen, as noted above SP2013 workflows will not be affected and they will follow their current end of life process.
Great question – will route this question to the feature owner and hopefully we can get answer on that.
I understand. Is there any other business reason why you need to retire it, except that it can’t be measured / tracked and monetized?
There's no objectives to monetize all of our APIs - as that's not beneficial for anyone. This API has been tracked and measured - like all of our APIs for sure. It's also an API which was introduced ~20 years ago and having a backwards compatibility for APIs for more than two decades has an operational and support cost, especially if more modern APIs are available, like in this case.
Our objective is not just to pile in more features and APIs - but also clean up the platform as needed to make it more consistent for everyone to use...
Will the Grant access to an item or a folder action, that allows to send an email, be affected?
https://learn.microsoft.com/en-us/sharepoint/dev/business-apps/power-automate/guidance/manage-list-item-file-permissions#grant-access-to-an-item-or-a-folder
That’s an out-of-the-box feature and there are no requirements for you to adjust your flows with this announced API level end-of-life.
This is going to cause so many problems. I am sure you guys will be coming out with a way to do this with a premium license. lol.
This API has excited for ~20 years – which is a really long time – and shows the enterprise level commitment we have on these platforms. We though also need to sometimes clean the old stuff and there’s an easy replacement for it within the Graph API side.
easy?
you don’t understand anything.
You should refrain from making irresponsible statements.
Thx James for calling out also the complexity of the current world on using APIs. These are often driven by the increased security for the ecosystem, but do absolutely agree that using Microsoft Graph APIs with the app registration is much more complicated than using the old CSOM or REST APIs, which are still there for sure.
Easy replacement that requires:
1. a service account/mailbox (with license)
2. app registration (different team, +security review)
3. ExO Application Access Policy (different team again, and scary one off power shell with the possibility of accidentally granting access to every mailbox in the tenant)
4. code changes
5. ongoing management of secrets for above
Simple.
Sometimes I think that Microsoft doesn’t know what operating in an enterprise environment is actually like.