notify.send_message / smtp.send_message have no per-call recipient override, unlike the deprecated notify.email

[ppanish]

Integration name

SMTP

Link to integration documentation on our website

No response

Describe the enhancement

The deprecated notify.email action accepted an optional target: field in its data: payload, letting a single automation send to a different recipient than the platform's configured default on a per-call basis. Its replacement, smtp.send_message, has no equivalent: its fields are limited to title, message, html, and attachments, plus an entity-based target: selector that only accepts notify domain entities belonging to the smtp integration — it does not accept an arbitrary address. notify.send_message has the same limitation when targeting an smtp-backed entity.

The SMTP config entry itself supports multiple recipients (added via the integration's options flow, "Add recipient"), but they're all addressed together on every call — there's no way to select a subset per-call. Creating a second SMTP integration instance to get a second, differently-addressed notify entity is also blocked: Home Assistant treats a second instance with the same host/username as a duplicate and refuses to set it up, even though the intended recipient differs.

I'd like smtp.send_message to accept an optional per-call recipient override — e.g. a recipient: field in data: that, when provided, sends only to that address instead of the entry's configured recipient list. This would restore parity with the deprecated action's target: behavior without requiring a second integration instance.

Use cases

The main use case is routing specific automations to a different address than the account's default recipient, using a single SMTP account/integration. A common concrete example: forwarding certain "critical" alerts to an email-to-SMS gateway address (e.g. <number>@vtext.com for a Verizon number) while all other notifications go to a regular email address. This lets one integration serve as both "normal notifications" and "urgent alert" channels, distinguished per-automation by which recipient the call targets — a pattern that worked cleanly under notify.email and has no supported replacement now.

More generally, any setup that wants to fan different categories of notification out to different recipients (e.g. one person's email for routine updates, a household distribution address for alerts everyone should see) hits the same wall.

Anything else?

Workarounds considered and ruled out:

• Second SMTP integration instance: blocked by HA's duplicate-entry detection for the same host/username.
• Adding the second address as an additional recipient on the existing entry: works, but sends every message to all configured recipients — there's no way to address only one of them per call, so this isn't equivalent (every alert now also goes to the other channel).
• A script-based wrapper using smtplib directly: would work, but requires managing SMTP credentials outside HA's UI-configured integration, which is a step backward for anyone relying on the integration for credential management.

HA Core version at time of writing: 2026.8.0. Confirmed via notify.email's own deprecation warning, which states it stops working in version 2027.3.0.

[github-actions[bot]]

🏷️ I've automatically added the integration: smtp label to help categorize this feature request.

[TheFes]

Fully agree with the FR above.

In my case I'm using it to monitor a specific email address using the IMAP integration. When an email is received, it will send a reply using the now deprecated SMTP action.
I don't know the sender address in advance, so I can't create target entities.

[h8hr1pzdo3rmiqv5]

Same usage and therefore same issue here.
IMAP receives an email, and an automation replies to it through SMTP, to the initial sender.

[Asom-Velz]

I would also like to see this functionality restored before the legacy SMTP notify action is removed.

I am running Home Assistant OS / Core 2026.8.3 and have a production reservation workflow where the recipient address is obtained dynamically from calendar reservation data.

For example, the working legacy SMTP action is:

action: notify.gmail_xxxxx
data:
  target:
    - "{{ guest_email }}"
  title: "{{ email_subject }}"
  message: "{{ email_message }}"

guest_email changes for every reservation and may contain an address such as xxx@something.com.

I have tested this on Core 2026.8.3 and confirmed that the legacy SMTP action successfully sends to the dynamically supplied address.

Pre-registering every possible recipient as a notify entity is not practical for this use case because the recipients are future guests whose addresses are not known in advance.

A supported smtp.send_message action that accepts one or more runtime/template recipients while using the SMTP account configured in the integration would provide a clean migration path.

This would be especially important before removal of the legacy SMTP notify action in 2027.3.0.

[modernman1]

This is very much needed!!!
There are tons of use cases for this - leaving it out is a huge step backwards!

If there is valid reason to prevent this for some users, it should be an option for the integration to allow recipient(s) to be passed to the service.