I’m trying to diagnose an issue with some of my emails. Newsletters sent to existing subscribers work fine, but when a new subscriber clicks to subscribe to the blog the confirmation email goes directly to spam.
I ran that confirmation email through one of Mailgun’s recommended diagnostic tools and there are all sorts of things wrong with it. Lots of the email settings are completely different than the settings of my newsletters which deliver to inboxes with no issue.
Is there some sort of default sender settings that are being used for system emails? If so how do I go about changing them?
Also, how can I customize the copy on a confirmation email?
I’m having the same problem. My post emails arrive in inboxes without any issues, but all transactional/subscription/test emails end up in spam (specifically for gmail). I tested this on five different gmail accounts and 1 outlook account, all gmails ended up in spam but the outlook seemed to be fine.
After banging my head against a wall for several hours across several days, I still haven’t figured out a solution.
To clear things up, the recommendation by @minimaluminium is sadly not relevant to this issue. I have set up the config.production.json file with my SMTP credentials, including specifying a from address (noreply@mail.daobase.org) that is different from the address for sending post emails (jack@daobase.org). Doing this has revealed to me that only system emails (such as test emails) are affected by the json file. The subscription confirmation emails still come from the root domain (@daobase.org) as specified in Labs > Email Settings.
I have run my Digital Ocean IP and domain against several spam checkers (e.g. mail-tester.com) and I’m following all the rules for reputable email configuration. I’m not on any blacklists (except Spamhaus CBL, which is 1 out of ~100 checked), and I have my SPF, DKIM, and DMARC all authenticated.
The only problem which mail-tester identifies, and gmail itself too, is with the content of these emails. Specifically, for example, there is no unsubscribe header (which wouldn’t make sense for a confirmation/test but it has been flagged all the same).
I see the following solutions:
Let us customize all system/transactional emails so that we can ensure they’re DMARC compliant, by ensuring they come from the same subdomain as our Mailgun. Part of this includes letting us configure a Reply-To address, assuming our transactional From address is different from the address we use for personal communication.
Make the content of these emails less spammy. Can’t help but feel that the excessive exclamation marks and “xoxo” are contributing to this.
Let us customize the system notifications that appear when someone submits their email address to the subscribe box, so that we can warn them to check their spam folder.
I would be curious to see how the configuration for Publisher Weekly (Ghost’s newsletter) differs from ours. I just tested out subscribing and their confirmation email arrived in my gmail inbox without issue, but the content of the email is exactly the same.
To clarify on my previous point, the test email comes from noreply@mail.daobase.org, which is what I set up in the mail config (1st screenshot). But the subscription confirmation emails come from noreply@daobase.org, the address configured in the email settings in Labs (2nd screenshot), which gives me no option to change the subdomain to match the Mailgun subdomain.
It seems that there are two types of transactional emails, and Ghost doesn’t give us much flexibility to configure the signup/signin/subscription emails, which are the ones that keep going to spam for me.
Before I did what you suggested, I also discovered that my Digital Ocean droplet’s IP was on the Spamhaus XBL & CBL blacklists, which gmail supposedly uses. I’ve removed myself from those which may be helping with deliverability too.
I don’t remember coming across any recommendations to set up 2 SPF records if using a subdomain for Mailgun, either on the Mailgun or Ghost setup guides. I may have just missed it, but if not this should be amended by the Ghost team. It’s a logical solution in hindsight, but not for a newbie who’s just following instructions and doesn’t know what each record is actually doing.
