PowerShell send email SMTP: Send-MailMessage, why it is obsolete, and what changes when an agent writes the script

The obsolete cmdlet and what its status means

Microsoft's reference for Send-MailMessage carries an explicit warning rather than a soft deprecation note. The cmdlet remains present and functional in PowerShell, so existing scripts continue to run, but its documented status is obsolete and its use is not recommended.

The reason given is the security guarantee, not the feature set. Send-MailMessage cannot guarantee an encrypted connection to the server, which is what disqualifies it for anything carrying credentials or personal data across an untrusted network.

The absence of a built-in replacement is why the cmdlet is still encountered. Microsoft's guidance points to the platform compatibility note DE0005 rather than to another cmdlet, so replacing it means adopting an external library or a service API rather than a different built-in command.

Required parameters

Three parameters are mandatory: From, To and Subject. A message missing any of them fails before a connection is attempted.

A server must also be specified, either through the SmtpServer parameter or by setting the $PSEmailServer preference variable, which supplies the default for the session. Without one, the command fails.

The Port parameter selects the submission port, covered in SMTP ports and which one to use, and UseSsl enables TLS. The cmdlet's encryption behavior is what Microsoft's warning concerns, so neither switch makes the cmdlet suitable for sensitive traffic on an untrusted path.

What an agent does differently with a PowerShell mail script

Asked for a script that emails a report, an agent reaches for Send-MailMessage. Most published examples predate Microsoft's warning, so the generated script looks correct and runs.

Four habits follow from that starting point.

• It writes the obsolete cmdlet, usually with UseSsl added, which does not change the warning Microsoft attaches to it.
• It embeds the credential, building a PSCredential from a plaintext password inside the .ps1 file so the script runs without a prompt.
• It schedules the script to run unattended, which means nobody reads the output when a send fails.
• It wraps the send in a retry loop. The cmdlet has no idempotency, so a retry after a partial failure can send a message the server already accepted.

Each habit is reasonable in isolation. Together they produce a job that sends with a stored password through an obsolete cmdlet, on a schedule, with retries that can duplicate mail.

Common parameters

Body carries the message text, and BodyAsHtml marks that text as HTML rather than plain text. Without the switch, HTML markup is delivered literally as characters.

Attachments takes one or more file paths. Cc and Bcc take additional recipient addresses, following the same address rules as To.

Credential accepts a PSCredential object rather than a plaintext password argument. Building one from a hardcoded string in the script defeats the purpose, so the credential belongs in a secret store or an encrypted file read at runtime.

Authentication errors on major providers

An account password fails against Google and Microsoft accounts with multi-factor authentication enabled. The SMTP client cannot complete the second factor, so the provider rejects the credential outright rather than prompting.

The working credential on those providers is an application-specific password generated in the account security settings, or an OAuth token. Send-MailMessage supports the former through the Credential parameter and does not implement OAuth.

Credential scope produces the same symptom from the other direction. A least-privilege API key can be rejected by a check that needs a wider scope, so a rejected credential is not always a wrong credential.

Microsoft has been retiring basic authentication for client SMTP submission, pointing at OAuth instead. A script authenticating with a password against Microsoft 365 is running against a mechanism scheduled for removal rather than a stable interface.

Where an internal relay still fits

An unauthenticated internal relay remains common in IT automation, where a server on a trusted network accepts mail from known internal hosts without credentials. That is a network-boundary control rather than an authentication one.

Its scope is narrow. Alerts to internal recipients through an internal relay never traverse the public internet, and the mail is not subject to another organization's filtering.

A relay that faces anything wider than a trusted network needs the opposite posture. The port is firewall-restricted to known hosts, TLS and SMTP authentication are mandatory, and arbitrary destinations, extra recipients and unsigned or replayed requests are rejected.

A script that sends through an obsolete cmdlet against a mechanism a provider is retiring will eventually stop sending. Nobody notices, because nobody misses a message they never expected to see.

Mail leaving the organization is a different problem. Once a message goes to an external recipient, domain authentication and sender reputation govern whether it arrives, and an internal relay provides neither delivery status nor bounce handling.

Worked example: replace a scheduled PowerShell report email

The prompt, in the user's words: Our nightly PowerShell job emails a report with Send-MailMessage. Move it to something supported.

Before, unguided: the agent keeps Send-MailMessage, adds UseSsl and a stored password, and leaves the scheduled task as it was. The report still goes through an obsolete cmdlet, and nobody looks at the message before the next run.

After, with the agent working through Nitrosend's MCP server, the move is a gated sequence:

1. nitro_get_status gets the account context, sender identity and readiness.
2. nitro_manage_domains adds and verifies the sending domain the report comes from.
3. nitro_manage_template creates a reusable email template for the nightly report.
4. nitro_review_delivery runs a read-only review with validation, spam analysis, preflight and previews. It never sends.
5. A single real send of the template follows through nitro_send_test_message, addressed only to the test recipients from nitro_configure_account.
6. A person checks the test before the scheduled job changes.
7. The job drops Send-MailMessage and sends through the transactional email API with an idempotency key per night, so a retried run does not send the report twice.
8. nitro_get_insights returns email analytics with trends, benchmarks and recommendations once the reports are flowing.

The report copy does not need to be hand-written either. Nitrosend's platform includes an AI agent responsible for most of the email writing, so the template step can start from a description of the report.

The job keeps its schedule. What changes is that the credential is an API key held in the job's environment, and that the email was reviewed and tested once before it ran unattended. The email API documents the request the job makes.

Where it goes wrong when an agent writes the script

• A password in the .ps1 file or the job history. A credential built from a plaintext string ends up in source control, and a transcript or task log can capture it.
• A scheduled job that retries and double-sends. Send-MailMessage has no idempotency, so a loop that re-runs after a timeout can resend a report the server already accepted.
• Basic auth that the provider has turned off. The agent writes a password login against Microsoft 365 or Google, the provider rejects it, and the failure reads like a wrong password.
• The report sent to a recipient list the model guessed. Addresses in the script that come from no config file or directory are a sign the model filled them in, so they need checking before the first scheduled run.
• Plan limits on an unattended job. On Nitrosend pricing, the Free plan allows 100 to 5,000 recipients per rolling 24 hours by sender standing, and a new account starts at the low end.

Why application mail moves off SMTP cmdlets

The cmdlet reports whether the server accepted the message and nothing after that. Bounces, deferrals and spam-folder placement all happen after acceptance, so a script that completes without error has not established that anything was delivered.

There is no retry, queue or idempotency behavior. A transient failure surfaces as a terminating error for the script to handle, and a re-run after a partial failure can duplicate messages already accepted.

An HTTP API replaces both gaps. A request returns a message identifier that can be queried for status and accepts an idempotency key so a retried request does not send twice, neither of which the SMTP conversation provides.

Authentication changes shape with it. An API key held server-side in the script's environment does the authenticating, which is what API keys are for, and no mailbox credential or second factor is involved.

Nitrosend has used the agent path on its own mail. An AI agent built and sent the launch email for a new Nitrosend feature, and George Hartley, co-founder, approved it and did nothing else.

The API replaces the cmdlet for a script that still has a person maintaining it. For an AI agent it goes one step further. Through Nitrosend's MCP server the agent calls the same gated sequence as the worked example above, so nobody hand-maintains a script whose only job is Send-MailMessage with better error handling.

FAQ

Is Send-MailMessage still supported in PowerShell?

Send-MailMessage still runs, so existing scripts keep sending, but Microsoft's reference marks it obsolete and recommends against using it because it does not guarantee secure connections to SMTP servers. Microsoft names no built-in replacement and points to compatibility note DE0005 instead. The cmdlet still requires 3 parameters: From, To and Subject.

What replaces Send-MailMessage for application mail?

An external library or a service API, because PowerShell ships no successor cmdlet. A transactional email API authenticates with an API key held in the job's environment, returns a message identifier that can be queried for status, and accepts an idempotency key. That covers the 2 gaps the cmdlet leaves: delivery status and safe retries.

Can a scheduled PowerShell job retry a send safely?

Not with Send-MailMessage. The cmdlet has no idempotency, so a re-run after a timeout can resend a message the server already accepted. Through a transactional email API, the job sends 1 idempotency key per night, so a retried run does not send the report twice, and the scheduled task itself can stay as it is.

Go deeper