Transactional mail : get rid of sender = “test@example.com”

Using Ghost
1

Hi there,

I’ve just installed Ghost configured with Mailgun to send mail and everything seems to work: Bulk mail and Transactionnal mail… except for one little thing.

Problem identified: with SMTP, transactional mails for Ghost admin (such as password reset requests, staff user invitations, member newsletter signup confirmations… for example) are always sent from the “test@example.com” address, and I don’t know where to change this setting.
In the Ghost interface? In the Mailgun interface?

Expected behavior: transactional mails should be sent from the address “noreply@MYDOMAIN.com”.

My JSON config file contains this:

"mail": {
 "transport": "SMTP",
"from": "noreply@MYDOMAIN.com",
"options": {
 "service": "Mailgun",
 "host": "smtp.eu.mailgun.org",
 "port": 587,
 "secure": false,
 "auth": {
 "user": "noreply@MYDOMAIN.com",
 "pass": "1234..."
    }

Any idea ? Thanks for help.

2

I have the exact same issue. I’ve spent hours trying to figure this out, but I’ve yet to find a solution.

This issue also creates some additional hurdles when trying a new local developer installation. See the last paragraph below too see what I mean.

Once you’ve created the first admin account you’re automatically signed in to Ghost Admin. But, on the next login, Ghost will fail to send the email with the verification code.

bild
bild534×528 18.1 KB

The console log is more verbose and helpful.

bild
bild1050×149 5.61 KB

This happens despite that the setting for requiring 2FA codes is disabled by default in Ghost Admin on the local installation.

bild

There’s also no mention in the docs of any requirement to configure email for a local installation.

To tie this all together with the issue in this thread. Even if you edit the mail section in the config file to send mail through Mailgun for example, the email with the 2FA verification is sent from test@example.com, which obviously fails to deliver as it doesn’t pass DMARC.

3

A good fix for local installs is to run maildev. It traps all outbound email, making it very easy to test and develop functionality involving user accounts.

Another option specifically for staff accounts is to disable staff device verification. Configuration - Adapt your publication to suit your needs

4

Thanks @Cathy_Sarisky! I was no aware of that config setting. I do think that setting also should be available in Ghost Admin, making it two options - require only for new devices or require for all staff logins.

That setting could also be disabled by default on local installs, considering the purpose of those installs.

The documentation for a local install should include information about these settings, kind of like the checklist structure for the production install.

As for my original issue with the 2FA emails being sent from test@example.com, I’ve taken another look at it now and found the issue. I’d placed the "from" string in the "options" object. It should be placed in the "mail" object. After correcting this, all of my emails, including the 2FA codes are sent from the correct email address. I don’t know how I managed to spend hours on this without seeing that, but taking a break is obviously good… :+1:

As for @Cy-real’s case, at least "from" is in the correct place in the JSON. A difference from my config is that I use "port": 465 and have secure set to true. It might be worth to try that if you haven’t already, as those settings work for me,