Issue Summary
Issue Summary
- Mixing (sub)domains for transactional emails.
- Some transactional emails (subscription and subscriber sign in) are throught he support email (usually human-run for sending and receiving and at the root domain) and forced to use the visible support email
- Other transactional emails (staff invitations and staff sign-ins with 2FA and welcome emails) are through the bulk email address (usually a subdomain)
Steps to Reproduce
- Subscribe, sign in as subscriber, or sign in as staff, or get invited to be staff
- Check email inbox.
Setup information
Ghost Version
6.36.0
How did you install Ghost?
Hosted/managed on Magic Pages
Provide details of your host & operating system
Linux OS (amd64, Debian Linux 13), Mozilla Firefox 140.10.2-esr
Database type
MySQL8
Why Important?
This is a bug, not just a feature request. Transactional emails, human emails, and bulk emails are all different; transactional and bulk deserve separate subdomains respectively. Once a certain domain or subdomain is known to be a bulk emailer, it is forever labeled as a bulk emailer. If a list grows and includes a thousand subscribers, it is very possible that one or more will accidentally or intentionally report/flag a bulk email as spam. This will then kill acceptance rates for human emails from the main domain if shared (!!!!!) and for transactions.
The lack of a dedicated space to indicate both types of transactional emails means that some transactional emails use the human-visible visible support address on the subscription portal (usually at the root domain, @site.com), while others use the bulk emailer address (which can be set to a subdomain such as @mail.site.com).
Yes, welcome emails are transactional, not bulk. For some reason, the initial sign-up confirmation email uses the support email address, and the follow-up email (Welcome!) uses the bulk email address.
You may think that the same reputation emails should apply to the bulk email newsletter and transaction emails for the newsletter Ghost sites because Ghost is all about newsletters / bulk emails. Sure, fine—and I agree, by the way.
However, the human-visible support email address on the subscription portal page should not be for transactional emails.
The hierarchy of risk is such:
- human-authored, infrequent, random emails (if these get poisoned by a bad reputation = game over)
- transactional, semi-infrequent, human-intitiated but robot-sent emails
- bulk/newsletter emails that are frequent, regular, and go out to thousands of people all at the same time
Right now, the only workaround is to list as support the bulk email address (@mail.site.com) and have the hosting service bounce such emails to a “real” email address (@site.com). I can risk the transactional emails being treated along with the bulk address (for reasons listed above), but I absolutely cannot risk the human emails at the root domain getting tarnished with the “bulk” email address’s reputation.
Steps to Reproduce
Issue Summary
- Mixing (sub)domains for transactional emails.
- Some transactional emails (subscription and subscriber sign in) are throught he support email (usually human-run for sending and receiving and at the root domain) and forced to use the visible support email
- Other transactional emails (staff invitations and staff sign-ins with 2FA and welcome emails) are through the bulk email address (usually a subdomain)
Steps to Reproduce
- Subscribe, sign in as subscriber, or sign in as staff, or get invited to be staff
- Check email inbox.
This is a bug, not just a feature request. Transactional emails, human emails, and bulk emails are all different; transactional and bulk deserve separate subdomains respectively. Once a certain domain or subdomain is known to be a bulk emailer, it is forever labeled as a bulk emailer. If a list grows and includes a thousand subscribers, it is very possible that one or more will accidentally or intentionally report/flag a bulk email as spam. This will then kill acceptance rates for human emails from the main domain if shared (!!!!!) and for transactions.
The lack of a dedicated space to indicate both types of transactional emails means that some transactional emails use the human-visible visible support address on the subscription portal (usually at the root domain, @site.com), while others use the bulk emailer address (which can be set to a subdomain such as @mail.site.com).
Yes, welcome emails are transactional, not bulk. For some reason, the initial sign-up confirmation email uses the support email address, and the follow-up email (Welcome!) uses the bulk email address.
You may think that the same reputation emails should apply to the bulk email newsletter and transaction emails for the newsletter Ghost sites because Ghost is all about newsletters / bulk emails. Sure, fine—and I agree, by the way.
However, the human-visible support email address on the subscription portal page should not be for transactional emails.
The hierarchy of risk is such:
- human-authored, infrequent, random emails (if these get poisoned by a bad reputation = game over)
- transactional, semi-infrequent, human-intitiated but robot-sent emails
- bulk/newsletter emails that are frequent, regular, and go out to thousands of people all at the same time
Right now, the only workaround is to list as support the bulk email address (@mail.site.com) and have the hosting service bounce such emails to a “real” email address (@site.com). I can risk the transactional emails being treated along with the bulk address (for reasons listed above), but I absolutely cannot risk the human emails at the root domain getting tarnished with the “bulk” email address’s reputation.
Ghost Version
6.36.0
Node.js Version
Latest (?)
How did you install Ghost?
Managed on Magic Pages
Database type
MySQL 8
Browser & OS version
No response
Relevant log / error output
Code of Conduct
Issue Summary
Issue Summary
Steps to Reproduce
Setup information
Ghost Version
6.36.0
How did you install Ghost?
Hosted/managed on Magic Pages
Provide details of your host & operating system
Linux OS (amd64, Debian Linux 13), Mozilla Firefox 140.10.2-esr
Database type
MySQL8
Why Important?
This is a bug, not just a feature request. Transactional emails, human emails, and bulk emails are all different; transactional and bulk deserve separate subdomains respectively. Once a certain domain or subdomain is known to be a bulk emailer, it is forever labeled as a bulk emailer. If a list grows and includes a thousand subscribers, it is very possible that one or more will accidentally or intentionally report/flag a bulk email as spam. This will then kill acceptance rates for human emails from the main domain if shared (!!!!!) and for transactions.
The lack of a dedicated space to indicate both types of transactional emails means that some transactional emails use the human-visible visible support address on the subscription portal (usually at the root domain,
@site.com), while others use the bulk emailer address (which can be set to a subdomain such as@mail.site.com).Yes, welcome emails are transactional, not bulk. For some reason, the initial sign-up confirmation email uses the support email address, and the follow-up email (
Welcome!) uses the bulk email address.You may think that the same reputation emails should apply to the bulk email newsletter and transaction emails for the newsletter Ghost sites because Ghost is all about newsletters / bulk emails. Sure, fine—and I agree, by the way.
However, the human-visible support email address on the subscription portal page should not be for transactional emails.
The hierarchy of risk is such:
Right now, the only workaround is to list as support the bulk email address (
@mail.site.com) and have the hosting service bounce such emails to a “real” email address (@site.com). I can risk the transactional emails being treated along with the bulk address (for reasons listed above), but I absolutely cannot risk the human emails at the root domain getting tarnished with the “bulk” email address’s reputation.Steps to Reproduce
Issue Summary
Steps to Reproduce
This is a bug, not just a feature request. Transactional emails, human emails, and bulk emails are all different; transactional and bulk deserve separate subdomains respectively. Once a certain domain or subdomain is known to be a bulk emailer, it is forever labeled as a bulk emailer. If a list grows and includes a thousand subscribers, it is very possible that one or more will accidentally or intentionally report/flag a bulk email as spam. This will then kill acceptance rates for human emails from the main domain if shared (!!!!!) and for transactions.
The lack of a dedicated space to indicate both types of transactional emails means that some transactional emails use the human-visible visible support address on the subscription portal (usually at the root domain,
@site.com), while others use the bulk emailer address (which can be set to a subdomain such as@mail.site.com).Yes, welcome emails are transactional, not bulk. For some reason, the initial sign-up confirmation email uses the support email address, and the follow-up email (
Welcome!) uses the bulk email address.You may think that the same reputation emails should apply to the bulk email newsletter and transaction emails for the newsletter Ghost sites because Ghost is all about newsletters / bulk emails. Sure, fine—and I agree, by the way.
However, the human-visible support email address on the subscription portal page should not be for transactional emails.
The hierarchy of risk is such:
Right now, the only workaround is to list as support the bulk email address (
@mail.site.com) and have the hosting service bounce such emails to a “real” email address (@site.com). I can risk the transactional emails being treated along with the bulk address (for reasons listed above), but I absolutely cannot risk the human emails at the root domain getting tarnished with the “bulk” email address’s reputation.Ghost Version
6.36.0
Node.js Version
Latest (?)
How did you install Ghost?
Managed on Magic Pages
Database type
MySQL 8
Browser & OS version
No response
Relevant log / error output
Code of Conduct