Solved

Not receiving emails from the Management console/domain

  • 14 February 2019
  • 2 replies
  • 535 views

Badge
I'm using a trial of Webroot but I'm having trouble receiving emails but only from the Management console. For instance, when I first signed up for the Webroot trial I received the activation email successfully, but I never received the second email with the temporary password to log into the management console. I had to contact Webroot support to have them send me one directly. Now I'm trying to add more Admins and they aren't receiving the Activation email to sign into their accounts. It's not getting blocked by our spam firewall as it's not even getting that far. I assume it's being blocked by our Firewall but I'm not sure why. I was told by Webroot that the emails come from @webrootanywhere so I did an MX lookup and found that domain is hosted by Rackspace (the @webroot.com domain is not; I am receiving those emails successfully). I've tried white listing any Rackspace IPs I can find on the firewall but I'm still not getting the emails. Has anyone had this issue and if so what was the resolution? I have contacted Webroot support but they've been slow to respond and weren't helpful as far as what to do. They just told me to whitelist URLs and open port 80 and 443 but I'm not having an issue reaching the Web console, I'm having an issue receiving emails from the @webrootanywhere.com.
icon

Best answer by NicCrockett 28 February 2019, 21:15

View original

2 replies

Userlevel 1
Badge +2
I would start by setting up a "test" Admin account and use a Gmail or other external email account.

If you receive the notifications at the Gmail account then you know the issue is with your mail server.

If your email server is blocking then just need to white list the webrootanywhere.com domain on your email server, or spam filter if it's separate.
Userlevel 7
Badge +28
First off, you shouldn't whitelist any IP Address for Rackspace. Nothing against Rackspace, but you have no idea who's being hosted on their servers and using those IP Addresses.

Second, port 80 is used for http websites and port 443 is used for https secure websites. Granted, that's generally what those ports are used for. Email ports depend on the protocol. Generally the IMAP protocol uses port 143 for insecure and port 993 for secure. Generally the POP protocol uses port 110 for insecure and port 995 for secure. Generally the SMTP protocol uses port 25 for insecure and port 465 for secure. More than likely you need to be concerned with SMTP, but I don't know your set-up, so that's a guess.

Third, @webrootanywhere.com and @webroot.com are two different domains and they can be hosted at two different locations and use two different email systems. They can also use the hosting and email system. My guess is, @webroot.com doesn't need as much bandwidth, so it's hosted in one location. It's also their company domain, so they probably have the email segregated from @webrootanywhere.com. The @webrootanywhere.com is used by their software and tons of users are hitting it constantly, so they probably need a more robust hosting provider for it. The emails coming off this system also probably can't go through a system like Office 365, which might be what the company uses. This means they probably have an SMTP server sending these emails. Depending on how this server is set-up, a lot of filters are rejecting more and more email if the sender doesn't have things like SPF, DKIM, and DMARC in place.

Sorry for the long explanation, but I thought it best if you had all the potential information you might want. As for what I would suggest. I would make sure that you whitelist both domains in your email system, spam filter, and if your firewall has an email filter, whitelist them there too. Other than that, you can take the headers of an email. I would suggest doing this from your email program, like Outlook, and Gmail as @mhanseman suggested testing. Take those headers and plug them into MX Toolbox's Header Analyzer to see what fails. This might give you some information as to where the problem is. If the problem is a failing SPF record, you can report this to support and they can look into fixing it on their end.

Good Luck!

Reply