At my wits end. email subdomains / transactional email / mailgun

Sorry in advance for the long post. So I migrated my Wordpress site from Bluehost hosting over to Cloudways for a speed increase which was nice. I’m still using Bluehost as my Domain Registrar/DNS provided. Now I am in the process of setting up email (It used to be setup on Bluehost). So I have successfully set up Zoho mail for my general inbox on my root domain which was relatively painless. What I am having a problem with is getting my transactional mail set up. I have chosen Mailgun to use and they recommend setting up transactional email on a subdomain which I completely understand to keep general email and transactional email reputations separate. So my first question is 1. Do I physically have to add a subdomain on Cloudways (such as or through Apps>Domain Management>Add Domain) for this to work? 2. Do I have to add a subdomain through my Domain Regristar DNS (Such as creating an A record)? 3. Or do I not have to create a subdomain at all but just specify a subdomain on my mailgun account and add the generated SPF, DKIM, and MX records that they specify. Another huge issue I’ve come across is basically every transactional email provider Sendgrid, Mailgun, Sendinblue etc. all have articles that say how bad it is to use NoReply addresses for your transactional emails which I understand. But the Ironic part of it all is that they don’t give a simple workaround for routing/forwarding your email (or specifying a reply-to address) for an actual monitored email address inbox such as to zoho. I understand that very very few people will ever respond to a transactional email but certainly some will. 4. How the heck are people supposed to reply and how can I receive those replies? Mailgun has a routing feature but you have to pay for the $35 a month plan which is a waste of money if you are sending very limited amounts of email. 5. Are transactional emails just not meant to be replied to at all? Seems odd. For the average online shopper or non techy person, they may not understand that the transactional email (purchase confirmation, billing details, etc.) isn’t meant to be replied to and is different than the general support email. They may try to respond to those emails and either get rejected error or it gets sent and lost and I never receive it to assist them. This seems like it could generate unnecessary customer service calls. Sorry for rambling on. Any ideas, advice, or workarounds?

2 Likes

You are not alone.
I enabled Elastic Mail on the server and changed the From address in the application settings for each site to a generic “info@mydoimain.com”, etc.
Site notification emails from WordPress are arriving from the mailer@managedcloudhostingemail.com address and not the address I entered.
I can enter a from address on any form and it has the correct “from” address.

I was told by support that I need to add:

Records TXT
Host/Name: @
Value: v=spf1 a mx include:_spf.elasticemail.com ~all

Records TXT
Host/Name: api._domainkey
Value: k=rsa;t=s;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCbmGbQMzYeMvxwtNQoXN0waGYaciuKx8mtMh5czguT4EZlJXuCt6V+l56mmt3t68FEX5JJ0q4ijG71BGoFRkl87uJi7LrQt1ZZmZCvrEII0YO4mp8sDLXC8g1aUAoi8TJgxq2MJqCaMyj5kAm3Fdy2tzftPCV/lbdiJqmBnWKjtwIDAQAB

Records TXT
Host/Name: _dmarc
Value: v=DMARC1;p=none;pct=100;aspf=r;adkim=r;

Record CNAME
Host/Name: tracking
Value:api.elasticemail.com

However, general WordPress emails are still arriving from mailer@managedcloudhostingemail.com

I think transactional emails, like order notifications to the customer, should have at least a real looking from address vs. mailer@managedcloudhostingemail.com.

If I am unable to resolve this, I will need to insert SendInBlue for transactionals emails.
It’s more work but will look better than: mailer@managedcloudhostingemail.com