Subdomains for: Transactional, bulk/marketing and system emails

Ideas
1

In order to protect the reputation of mail email domain mydomain.com (i.e. reducing chances of it going to the SPAM folder), add possibility to use 3 different subdomains to handle:

  • Transactional emails:
    Use case:
    Users/Members singing up to mydomain.com receiving confirmation emails, payment confirmation, etc. → optimally this could be set up as in a custom subdomain (e.g. alerts.mydomain.com)
    Where is this set up:
    I’ve had a look at the codebase and did some tests and at this stage the domain used here is the same as the one set up in Labs → Members → Email Settings. One cannot set up a subdomain.

  • Marketing/Bulk emails:
    Use case:
    The posts sent out as a result from the write choosing “Send by email” when publishing a post → optimally this could be set up as a second custom subdomain (e.g. news.mydomain.com)
    Where is this set up:
    I’ve had a look at the codebase and did some tests and at this stage the domain used here is the same as the one set up in Labs → Members → Email Settings. One cannot set up a subdomain.

  • System emails:
    Use case:
    Password resets for Ghost admin, Notification of new paid-member, notification of new member having joined, etc. → optimally this could be set up as a third custom subdomain (e.g. system.mydomain.com)
    Where is this set up:
    I’ve had a look at the codebase and did some tests and at this stage the domain used here can be adjusted: Configuration - Adapt your publication to suit your needs, but not to a subdomain

  • Human to human emails:
    Use case:
    Humans writing to humans → only case in which the main nameofhuman@mydomain.com should be used

To conclude, I’d appreciate to be able to reserve the root mydomain.com for human-to-human interaction (but most importantly to protect the reputation and email deliverability of the root mydomain.com) and set up subdomains for all other top three use cases.

Thanks for the good work Ghost team!

2

Following up on this. Sending marketing/transactional emails from the same domain leads to issues like this:

Then, when you, for instance, send a proposal from your own email address to another human (sending a work proposal for instance), the email ends up going to the Promotions tab (or even worse: Spam).

Protecting email domain reputation is important. Would love to see this tackled by the Ghost team ! :raised_hands:t3:

3

I concur with the need for separation. I found these problems because the system mixes functions and has some transactional emails go through a visible support email (when the support email, that humans reply to, should be on the simple root domain), while other transactional emails use the bulk email. Staff 2FA transactional emails use the bulk email address whereas subscribers’ transactional emails use the support address.

***

Welcomes and Staff Invitations

Welcome emails and invitation emails for staff roles come from the email address set for Welcome emails. Settings > Welcome emails > Customize > General > Sender email noreply@mail.site.com``>.

BAD: Transactional emails that use the bulk email address.

Staff Log-Ins

Staff log-ins (2FA emails) come from the email address set for the newsletter.

BAD: Transactional emails that use the bulk email address.

Sign-Up Confirmations and Subscriber Log-Ins

Emails to confirm sign-ups (🙌 Complete your sign up to . . .) and log-in emails (to write comments or manage own subscriptions) are automated but come from the support email address that you set in Settings > Signup Portal > Customize > Account page > Support email address > contact@site.com.

These emails are transactional, but I would rather keep the support email address at the root domain (contact@site.com) only for human-written sends and human-written replies.

BAD: Transactional emails that use the visible support email address.