Dan Wich (MailMechanic)

That did the trick: no more issues in Site Health or query length errors in the logs. Thanks for your help!

It’d be worth checking the Elastic Email SPF/DKIM setup if you haven’t already:
https://help.elasticemail.com/en/articles/2303914-spf-dkim-and-tracking-faq

This is a shot in the dark, but are there any clues that it could be from a different install of the site (a clone/staging/testing version)? That could explain the lower order number, and the apparently-different configuration for who gets the order email.

In addition the articles Stef mentioned, there’s also AutomateWoo for adding custom emails with custom triggers. It was bought out by Automattic, so I expect it’ll be around for the long haul.

Depending on what happens when you try Stef’s suggestion, you might want to look at two more things:
1) Do you see a “Password reset email has been sent” message, or just the same form re-appearing?
2) If you install WP Mail Logging, does it show the mail *trying* to go out?

I have some more details here based on what you find with those two steps.

Any chance you’re on an older WooCommerce and/or have the “??” emoji in the Additional Content area of the email? If so, try removing the emoji or updating WooCommerce (see my info here).

@laiqm, just a heads up that the code from the IconicWP post is likely a red herring for your particular case, the setting was changed again after that was posted.

I’d second the suggestion to run through the email FAQ troubleshooting steps. If you make it past the email logging part (with it showing the emails as sent), my troubleshooting article can help with next steps (regardless of whether the mail actually ends up in a spam folder).

It’s odd, that’s structured like WordPress’ default lost password URL, not the one that WooCommerce provides as a replacement. Usually I’d suggest checking what plugin might’ve overridden the lostpassword_url filter, but it’s hard to tell whether that will help in your case because the login appears to be a special version incorporated in that Magnific Popup, and has customizations from the “WordPress Social Share, Social Login and Social Comments Plugin – Super Socializer” plugin. So if the suggestions from my first link are too complex, you could try disabling any extra plugins to see if it helps. There’s a way of doing that without affecting visitors to the store: https://docs.woocommerce.com/document/troubleshooting-using-health-check/

Is the storeowner’s email on the same domain name as the store? I don’t know about GoDaddy’s specific configuration, but it’s common for the server’s mail system to think that email addresses on the local domain should be delivered locally, making it appear like they’ve disappeared. I haven’t read all the way through this article, but it looks like a good writeup of that problem.

If it’s on a different domain, my troubleshooting article here might be helpful even if the email isn’t in the storeowner’s spam folder: mail is often rejected before even reaching that point.

In addition to @princebhalani143’s suggestion, that sounds like symptoms I’ve seen with security/login-protection plugins, so those would be worth trying to (temporarily) disable too. If neither of those help, I have a general Woo password-reset troubleshooting guide here.

That kind of issue is usually due to aggressive spam filtering even if you don’t see the mail in the spam folder (you might’ve been blocked before even reaching that level).

I’ve got some troubleshooting tips for that, and I might be able to point you to a more-specific part of the article if you’ll share how your mail is delivered (through the host or through a specific mail service provider).

Yeah, the subdomain makes me suspicious too. That’s a really common way of setting up click-tracking through an email provider, is it possible the hosting service uses an external provider for email? The click?upn= part (and having a custom subdomain) matches how SendGrid handles click-tracking, for example.

Either way, it’s not something that WooCommerce *core* would be doing, so I’d be looking at 1) the email service that sends the mail, 2) the abandoned cart plugin, 3) other email-customizing plugins or code-snippets.

I guess as a band-aid, you could change the values in the database (and avoid saving any additional settings that would overwrite them). I think the options are called “woocommerce_email_background_color”, “woocommerce_email_body_background_color”, “woocommerce_email_base_color”, and “woocommerce_email_text_color”.

Hmm, same here on the version numbers.

I’ll try to dig into this further tonight or tomorrow, but in the meantime, any errors/warnings in the browser console?

I don’t specifically know why Gmail/Fastmail aren’t accepting the colors that way, but on my suggestion, I meant typing in the # on the WooCommerce settings page so that it makes it into the HTML output.