Email authentication help

[HCHTech]

Once upon a time, there was a little company owned by Larry. Nope, no way I can carry that all the way through - forget it, let's start over.

I have a client that sells things from their website. They have a Wordpress site with the various Woocommerce plugins. I'm not in charge of that (I have a web guy referral partner, it's one of his sites), but I get pulled into the sphere when there are problems.

The original domain is also the domain used for the client's email addresses with M365.

There is a public facing part of the website, and a "wholesale" side which is accessed by their wholesale customers to place orders. The wholesale stuff was originally on a subdomain.

A couple of months ago, something happened and they got an infection in one of the scripts on the wholesale site. It took a few days to nail down, but it was found and removed. I think they used a WP plugin called "Wordfence" that initially identified the bad guy. In those few days when the problem was active, their wholesale site was put on the bad list by Norton. Any customer that had Norton's antivirus and tried to access the site got a block message. This continued, unfortunately, even after removing the infection and having several customers report the site to Norton as good. Repeated scans of the site with various products have all since come back clean.

Because 80% of their business comes through the website, this became an emergency fairly quickly. Trying to talk to Norton was an exercise in futility. Reporting the site as a false positive went nowhere. Ultimately, the web guy remade the entire wholesale side of the site on a different domain than the public site. As before, when a wholesale customer places an order, Woocommerce generates (and a plugin called "Mailgun" sends) an email to "orders@originaldomain.com", with a copy also going to the customer. The "from" address in this email was also "orders@originaldomain.com"

Before the separation of the wholesale side of the site, this process all worked well with pretty standard SPF, DKIM & DMARC records.

Now that the site has been separated, I'm having trouble getting those order emails delivered. The wholesaledomain.com does not currently have an MX record, which may be the problem, but I'm going in circles trying to figure it out.

If we code Woocommerce and Mailgun to use the "from" email we want (orders@originaldomain.com), then SPF fails because originaldomain.com =! wholesaledomain.com.

If we code Woocommerce and Mailgun to use the from email of "orders@wholesaledomain.com", then SPF fails with a PERMERROR, probably because wholesaledomain.com doesn't have an MX record.

I have tried adding wholesaledomain.com to the SPF record of originaldomain.com's DNS, and vice versa - neither of which solved the problem.

What do I need to put where in order to get SPF & DMARC alignment on emails sent from wholesaledomain.com's site using a from address of email@originaldomain.com? We do have mailgun.org in the SPF record of originaldomain.com, and they are the ones actually sending the email.

When there is only one domain involved, this stuff is fairly easy to setup & troubleshoot. Because there are two domains in the mix on this problem, I'm in the weeds.

 

[phaZed]

Assuming the @wholesaledomain.com is a M365 account (and not a webmail) - You will need to add the wholesaledomain.com domain to the M365 Tenant. When adding, MS will present you with the various DNS records to add. Hope I understood the problem correctly.

Another option that could help you would be signing up for a free valimail.com account to assess the situation and get you some feedback/reports on what is actually failing.

 

[trevm999]

Why is the new domain involved at all? If it's sending from mailgun IPs and your using the original domain name, what would make sending issues have anything to do with the new domain?

 

[HCHTech]

Why is the new domain involved at all? If it's sending from mailgun IPs and your using the original domain name, what would make sending issues have anything to do with the new domain?

This is my question as well. Because I can't see the Mailgun setup (yet) I'm flying a bit blind. My original thought was like yours, the new domain isn't really involved, but as i understand it, the original setup was the same as before, using mailgun to send with an email@originaldomain.com from address, and mailgun is already included in the original domain's SPF record.

Our troubleshooting included changing the sender to the wholesaledomain.com, but I'm not confident that will work since there are no email accounts associated with that domain.

Assuming the @wholesaledomain.com is a M365 account (and not a webmail) - You will need to add the wholesaledomain.com domain to the M365 Tenant. When adding, MS will present you with the various DNS records to add. Hope I understood the problem correctly.

This is where I landed as next steps. That, and getting the web guy to show me the actual mailgun configuration, maybe just seeing the options there will give me a clue. The only other thought I had was that the IP of the new domain might need to be added to the original domain's SPF record, but it's Cloudflare, so the A record is proxied...

 

[Sky-Knight]

So let me get this straight.

You had a working configuration, but due to reputation issues stemming from an infiltration the owner wisely decided to split things up.

But now you have a new domain, with no reputation at all, brand new to the world, with an incomplete mail configuration that violates standards AND therefore lacking the full set of reputation establishing records (SPF, DKIM, DMARC)...

And you're wondering why those mails land in junk boxes? You are very correct, authentication indeed.

You've done what spammers do, now you reap the whirlwind. Because now you have a negative reputation on that domain to correct.

I suggest you review the starting lessons for Technibble's marketing instructions again, this reality is covered rather extensively. New domains, are junk. New domains that are poorly configured, double junk. New domains that screw this up, junk for ages.

Mail must be sent from a domain that has an abuse@, postmaster@, or some other published means ON ITSELF to accept requests to knock it off.
Mail must be from an authorized sender as per SPF. (SPF doesn't have to authorize MX by the way, but it does have to authorize everyone sending)
Mail must be signed, as per DKIM.
DMARC must exist, with appropriate records to inform the world how complete SPF and DKIM are, and at this point if it's less than 100%, you guessed it... junk.

Mailgun is a service, you do not have a service issue, you have a reputation issue. You've also got a design issue, but that's the easy thing to fix honestly. Yes, you need a mail server, but again that's the easy part!

 

[HCHTech]

But now you have a new domain, with no reputation at all, brand new to the world, with an incomplete mail configuration that violates standards AND therefore lacking the full set of reputation establishing records (SPF, DKIM, DMARC)...

And you're wondering why those mails land in junk boxes? You are very correct, authentication indeed.

Look, I got involved after all of this was done, I'm just trying to figure out the problem and way forward for the client. I thought (and still think) that the new domain is not sending the emails at all, they are being sent by the mailgun service and the emails are configured with from addresses and return paths using the original domain. I only started grasping at straws because there isn't enough information provided to know what the actual problem is. Just conceptually, I'm not sure if my supposition is true that the new domain isn't involved at all. I don't know how the mailgun service works - does the IP of the website using mailgun get checked against SPF? Maybe it does and maybe it doesn't. We are currently waiting on the web guy who as a support ticket with them to try and answer that question.

 

[phaZed]

@HCHTech See this page, a little bit down past the videos - and you can get a better idea of the Domain and DKIM settings in mailgun:

Mailgun - WP Mail SMTP

Want to fix your WordPress site's email delivery issues? Here's our tutorial on setting up WP Mail SMTP with the Mailgun SMTP server.

wpmailsmtp.com

 

[Sky-Knight]

@HCHTech

Implementing SPF, DKIM, and DMARC for Reliable Email Delivery | Mailgun

Developers, learn how to set up SPF, DKIM, and DMARC to authenticate emails, prevent spoofing, and improve deliverability for your applications.

www.mailgun.com

What is DKIM? Stop email spoofing once and for all | Mailgun | Mailgun

DKIM improves your email deliverability and sender reputation. Learn what DKIM is and how to use to secure your identity it in Mailgun’s ultimate guide.

www.mailgun.com

Mailgun sends the mail itself, and it must be integrated with SPF and DKIM as a sender. These instructions must be merged with M365 / GMail or whatever instructions are used to support the domain's mail transmission.

I can promise you, the "web guy" screwed this up. In my career I've run into ONE that didn't. I've got better odds of a CPU failing than the web guy doing this correctly.

@phaZed provided a link that has specific instructions on how to fully integrate a domain to the service, and from what they provide Wordpress has a from email address, email alias name, and an API key. Which is exactly what I'd expect for such a service.

So if this isn't sending, it's because someone mangled it somewhere. It's possible the email address / API key in Mailgun are for a service linked to the older domain too. It's all got to be gone through, and yes they will need a real mail server on top of things too. Once you get all these things sorted, and SPF / DKIM failures are zero, it will still take a few weeks before things stop landing in junk, and that assumes there's some non-bulk mail type delivery going on.

The good news is that's an orders@ email, which I didn't spot on my first read, which means you can configure the anti-spam service for your customer's mail provider to not block mail from the website's address and IP combination. If you need specific instructions on how to do that with M365, I'll be happy to plop something in here on that. Given the actual domains, I could do some checking too.