issue with mailing list delivery when using external SMTP server

[avatar1024]

Hello all,

I've recently set-up an external SMTP relay using forwardemail. It works well, emails are going through etc.

However I have encountered a problem using Cloudron mailing lists:

When sending an email from en external email address (e.g. @posteo.net) to a Cloudron list which contains addresses @mydomain.coop (the domain on Cloudron) and some other adresses, e.g. @gmail.com or @posteo.net I am getting bounces for all recipients with those external addresses. Delivery works fine for the recipients @mydomain.coop and all works fine to ALL recipients (no bounces) if the sender is an address @mydomain.coop.

Bounces look like:

Hi. This is the Mailer program at mydomain.coop.

I'm afraid I wasn't able to deliver your message
    "test email"
to the following addresses.

This is a permanent error; I've given up. Sorry it didn't work out.

Intended Recipients: <some.person@gmail.com>
Failure Reason: Error: 550 From header must end with @mydomain.coop

[avatar1024]

Addition email server logs:

When sending from @mydomain.coop with successful delivery:

{
  "ts": 1751965332978,
  "type": "delivered",
  "direction": "outbound",
  "uuid": "425FB09B-28B2-4DFD-B19D-24763E77D8A5.1.1",
  "messageId": "<bc8821b5-e1c3-422c-bce0-3be7ae6b974b@mydomain.coop>",
  "mailFrom": "<someone@mydomain.coop>",
  "spamStatus": null,
  "mailbox": null,
  "quotaPercent": null,
  "rcptTo": [
    "<some.person@gmail.com>"
  ],
  "server": {
    "host": "149.28.215.223",
    "ip": "149.28.215.223",
    "port": 587
  },
  "response": "OK: message queued"
}

When sending from an external address to the same list and failing on the same recipient:

{
  "ts": 1751964710037,
  "type": "bounce",
  "direction": "outbound",
  "uuid": "4C06313B-F1B3-460A-AC38-59402F3C3ACE.1.1",
  "messageId": "<76622dc4-1d22-4fe3-a863-e5da6a39a0b8@posteo.net>",
  "mailFrom": "<someone@posteo.net>",
  "spamStatus": null,
  "mailbox": null,
  "quotaPercent": null,
  "rcptTo": [
    "<some.person@gmail.com>"
  ],
  "message": "550 From header must end with @mydomain.coop",
  "mx": {
    "exchange": "149.28.215.223",
    "priority": 0,
    "port": 587,
    "auth_user": "*@mydomain.coop",
    "auth_pass": "c3b478557ae86e1b599aba64",
    "auth_type": "plain",
    "bind_helo": "my.domain.coop",
    "from_dns": "smtp.forwardemail.net"
  }
}

[james]

Hello @avatar1024 could you share your real Cloudron domain so I can take a look into the DNS records for MX, DMARC and so on?

[avatar1024]

@james sure it's catalystcollective.org

For clarity, sending/receiving emails works fine, it's only when someone with an external email address (i.e. not from this domain) sends an email through a cloudron list that delivery fails for recipients (list members) who also have external addresses.

[girish]

I think this has been reported previously about mailing list. Cloudron uses SRS but gmail and friends don't support SRS. I don't have an answer but we have to investigate on our side whether we can implement mailing list "reliably". So far, it's a low priority since the main use case for mailing list is internal mail distribution and it's not a real mailing list like the kernel mailing lists with external people . The feature initially came from Groups feature of Cloudron which was just forwarding mail to internal users.

[avatar1024]

@girish Hi Girish, I see the issue you mean (I also reported it a while ago, it was about double forward) but this one is different (although the cause might be same). Before switching to the external SMTP the mailing list was working fine for this use case, it's only after switching that it started happening.

While the other issue was a bit niche, this issue / use case seems more critical as it affects the basic functioning of mailing lists when using an external smtp.

[sponch]

Same here (since sending through Brevo (Sendinblue)).

[avatar1024]

To add to this, I've tested it sending only to internal users, with then a subsequent forward with a sieve filter to the @gmail/@posteo adresses, it also fails.

It feels this makes Cloudron mailing lists unusable with external SMTP.

[avatar1024]

I've also tried to create a mailbox (test@mydomain.coop) and set-up a redirect with roundcube to three "external" email addressed (@gmail / @posteo), delivery fails with all of them. So it is not specifically with Cloudron mailing lists but a bigger issue with redirects in general. @staff any clues?

[avatar1024]

Do we know why this has been marked as solved?

[james]

Hello @avatar1024
Since @joseph marked this topic as solved on 02.03.2026 and the last response was 16.07.2025 it could be that a Cloudron update has resolved this issue since then.
Do you still experience this issue and if so on what Cloudron version?

[girish]

@avatar1024 external relay services will only relay addresses that you added to them explicitly. So if you added foo.com into postmark, postmark will only relay email address which have From as *@foo.com .

The idea of mail forwarding is that the From address has to be that of the original. So, the From address has to set to say someone@posteo.com . Postmark will reject these emails (correctly).

So to summarize: domain-locked relays and keeping the original sender on forwards/lists do not go together. You can relay or you can transparently forward third-party mail, not both. There's nothing Cloudron can do about this from what I know.

[avatar1024]

@girish said:

@avatar1024 external relay services will only relay addresses that you added to them explicitly. So if you added foo.com into postmark, postmark will only relay email address which have From as *@foo.com .

The idea of mail forwarding is that the From address has to be that of the original. So, the From address has to set to say someone@posteo.com . Postmark will reject these emails (correctly).

So to summarize: domain-locked relays and keeping the original sender on forwards/lists do not go together. You can relay or you can transparently forward third-party mail, not both. There's nothing Cloudron can do about this from what I know.

Thanks for the explainer @girish. Does that means one cannot use an external relay to replace the built in SMTP server if we use mailing lists (or the mailbox + forward implementation in Cloudron 10) - given most likely senders and mailing lists members with use random email providers?

[girish]

@avatar1024 said:

Does that means one cannot use an external relay to replace the built in SMTP server if we use mailing lists (or the mailbox + forward implementation in Cloudron 10) - given most likely senders and mailing lists members with use random email providers?

Yes, with a typical smart host / relay you cannot keep the original sender on list/forward delivery to Gmail/Posteo/etc.

I want to mention that this is for the forwarding feature. Forwarding requires From address to be preserved. A mailing list behaves differently. It rewrites From/Reply-To etc and makes itself the originator of the email. This feature was never implemented in Cloudron. The forwarding feature was incorrectly labeled as mailing list and this misnaming is fixed in Cloudron 10.

I guess we have to look into Distribution lists/mailing lists for the next releases, if you are interested in this. But the From address will change, not sure if it will work for your use case. It's usually meant for group@example.com or list@example.com style workflows.

[avatar1024]

@girish said:

@avatar1024 said:

Does that means one cannot use an external relay to replace the built in SMTP server if we use mailing lists (or the mailbox + forward implementation in Cloudron 10) - given most likely senders and mailing lists members with use random email providers?

Yes, with a typical smart host / relay you cannot keep the original sender on list/forward delivery to Gmail/Posteo/etc.

I want to mention that this is for the forwarding feature. Forwarding requires From address to be preserved. A mailing list behaves differently. It rewrites From/Reply-To etc and makes itself the originator of the email. This feature was never implemented in Cloudron. The forwarding feature was incorrectly labeled as mailing list and this misnaming is fixed in Cloudron 10.

I guess we have to look into Distribution lists/mailing lists for the next releases, if you are interested in this. But the From address will change, not sure if it will work for your use case. It's usually meant for group@example.com or list@example.com style workflows.

Thanks Girish, and yes a mailing list feature will be useful for some of my use case.

I guess the point here is that it's a shame there isn't a way to use an external relay as a blanket replacement (i.e. covering all email features including forwarding) to the built-in SMTP server cause those services have added features to ensure reliable delivery (say when the server has a bad IP rep and gets regularly blocked notably by Microsoft stupid IP range blacklist approach).