Define "from" address for confirmation email when subscribing via api

[dewey]

Hey, I'm using the API to subscribe users to a list, I set up the list to be "double opt in" so I'm expecting the list to send the user a confirmation email to confirm the subscription.

I'm using Postmark as my SMTP service, but that means I'm getting an error like:

ErrorCode: '400', Message: 'The 'From' address you supplied (noreply@listmonk.yoursite.com) is not a Sender Signature on your account. Please add and confirm this address in order to be able to use it in the 'From' field of your messages.'.

The issue is that it will use the default "from" address of my listmonk instance for that, as I run multiple services through that one listmonk instance I can't set a global "from" address. I've been looking through the API but I could not find a way for me to define the "from" address for subscriptions to a specific list. I've stumbled upon this issue #890 but it seems there's not really a solution for this problem.

Did something change since then or am I out of luck and should find a way to send the confirmation email manually, without using listmonk for that?

Happy for any pointers, thanks!

[dewey]

I've shared a quick and dirty PR on how this could look like. I'm thinking it would make most sense to only allow it for single list requests, as otherwise we'd run into the complexity that the user would need to have an override defined for each list. Maybe it's better to be explicit there.

Would this be something you'd be open to in general? Should this be a general "from override" instead of just for confirmation? Then I'd set up a dev setup properly and test this fully.

[knadh]

Hi @dewey. It's not clean API design if we have a custom from address per list, but they're only allowed in subscription management calls under some conditions (single list / multi-lists, but only when there's one list with a from and others don't etc. / multi-lists, but none have from etc.)

Would the From addresses / domains field in SMTP settings address your issue?

From addresses / domains
Optional list of e-mail addresses (user@example.com) or domains (example.com) to route through this SMTP server. If multiple servers specify the same entry, they are used round robin.

[dewey]

Thanks for your reply! I'm not really familiar with the code base so there might be a much better option than what I'm trying to do. It's also very possible that I'm misunderstanding something that might already work.

Would the From addresses / domains field in SMTP settings address your issue?

The main issue I'm having is that I want to have different email lists (For my website example1.com and example2.com) and send the confirmation email for the double opt in for that list from either example1.com, or example2.com depending on what list it is so the user doesn't get confused. I think with the from addresses in the smtp settings I could not control that right?

The only solution that I see right now is to run one listmonk instance for domain as I can't configure a from address for each list, or define a specific smtp setting to be used for the emails of a given list.

I hope I explained that in a way that you know what I mean 😅

[zac343]

I checked current main at 911e0b7, and the SMTP From addresses / domains setting cannot select a different opt-in identity per list in this path.

The opt-in hook fetches the pending double-opt-in lists and calls notifs.Notify(...) once (cmd/subscribers.go:857-905). Notify always sets Message.From from the singleton no.opt.FromEmail (internal/notifs/notifs.go:70-100), initialized from the global app.from_email (cmd/init.go:813-817). The SMTP FromAddresses map only chooses a server pool from that already-selected m.From; it does not rewrite the sender (internal/messenger/email/email.go:113-120,131-141,239-254).

So with example1.com and example2.com, Postmark still sees the global From. This needs a list-level identity change rather than SMTP routing alone.

The smallest deterministic shape I can see:

1. Add an optional list-level opt-in From (or notification identity).
2. Use it when exactly one double-opt-in list determines the confirmation.
3. For multiple lists, allow one distinct normalized override; conflicting identities should fail closed or use an explicit documented global fallback, rather than whichever list happens to be first.
4. Pass that From into the notification message, then let the existing FromAddresses routing choose the matching SMTP server.
5. Cover single-list, multiple lists with the same From, conflicting From values, no override, and the provider-rejection path.

For mapping the domains before implementing, this browser-local sender inventory can keep list/domain, visible From, provider, signing identity, and validation notes together and export a review plan. It does not upload the inventory or replace the listmonk change.