I received an email regarding a change in the Epicor Cloud Email Service. The deadline is just 2 weeks away and that seems like an awfully short notice.
Just wondering if this seems legit:
Description:
This case has been opened with your company as we have determined you are using an Epicor SendGrid account to send email from Epicor Cloud.
Due to a change coming very soon in SendGrid you will be required to do one of things below by December 5th, 2020
Option 1: update your system to use your own SMTP services – please note that these services need to be public-facing so the Epicor Application server can send emails. You will be required to enter your own SMTP, ports, and login credentials in ERP Company Maintenance.
Option 2: continue using Epicor SMTP configuration with SendGrid
If option 2 is selected, Epicor will need to configure sender authentication. Sender authentication refers to the process of showing email providers that SendGrid has your permission to send emails on your behalf. With this process, you will need to add DNS records. These DNS records associate your sending domain with SendGrid — when an inbox provider processes your email, they will see your domain instead of “sendgrid.net”.
If Option 1 is selected, please update the case that you will not be using Epicor SMTP and you can close the case.
If option 2 is selected, below outlines the steps expected from you (Customer) and Epicor.
Customer: reply in the case with your domain URL(s). In some cases, customers may have multiple domains with multiple companies setup in ERP (example: if your email is name@epicor.com, you would reply in the case with “epicor.com” as the domain Epicor needs to add)
Epicor: configure SendGrid for your domain(s) and reply in the case with an email attachment(s). The email attachment(s) will provide a link to the records that will need to be added to your DNS Host.
Customer: complete the steps to add DNS host records (time sensitive - the link will expire in 48 hours)
Customer: update the case to confirm you have added the DNS host records
Epicor: validate SendGrid is showing verified to close the case
Epicor needed to make this change. How they were using SendGrid wasn’t right. They should have been authenticating domains all along.
We are on-prem ERP so we use our own SMTP for that. But we have managed ECC with Epicor. We are using our own SMTP with ECC because of their botched attempt at SMTP with SendGrid. They were not authenticating domains so our emails were being dropped due to our DMARC policies. I tried working with them to fix but they didn’t care to make it right. So we just moved our ECC SMTP to our own system.
I use SendGrid outside of Epicor and got the same email. Gmail has been bouncing some deliveries and it’s due to SendGrid subscribers not using anti-spam setup. So you can continue to use SendGrid but you’ll have to make some changes. Otherwise, people can abuse the service, lower the reputation, and affect mail for all of their users.
we had a big discussion with Epicor many months ago about how we had no outbound tracking on sent emails if they used their master account, and that needing to log an epicare case every time there was a problem was going to cause a huge mess
ironically we’ve not had time to setup our own sendgrid account since getting Epicor to open up access to the SMTP settings, creating our own account and and authing sendgrid to send on behalf of our domains seemed to be enough to allow the Epicor’s master account to send as us without issue.
anyone else bothered that Sendgrid don’t use the traditional SFP record entries(unless you pay for a super premium account) and instead require the text records for Auth… it bothers me a little.
I created a ticket for this and it appears that MultiTennant customers cannot control the SMTP and SendGrid is NOT used.
Here is the ticket explanation:
Hi Dave,
It seems you are a Multi-tenant customer. Multi-tenant does not use SendGrid but instead routed through Epicor e-mail servers. MT customers do not have the option of using either sendgrid or their own SMTP services. Therefore you should not be affected by the changes to occur by next week.
Let us know if you have any additional concerns.
Regards.
Has anyone been successful with Option 1? I am currently trying to test this in our Pilot environment and emails are erroring. Option 1: update your system to use your own SMTP services – please note that these services need to be public-facing so the Epicor Application server can send emails. You will be required to enter your own SMTP, ports, and login credentials in ERP Company Maintenance.
I have never needed to do this, but I suggest you need to have a firewall rule configured with an external facing IP address and a non standard port that translates to you internal smtp server (commonly terrmed as NAT).
You should be able to restrict the source IP Address as well, I’m not sure if there is a specific range of IP addresses that the Cloud app servers use or not. You could use this as a starting point, but you should consult with your network/email admin as invariably each company has their own configuration for email, which may need further configuration, and it will require some testing to get it correct.
I would think that Epicor Support could provide you the IP or IP range your instance sits on. I’d restrict it down to that. Or at least down to some IP range Epicor uses. I know their hosted ECC stuff is in Azure. So I assume that’s where they run ERP from too.
they shouldn’t even offer support it’s so bad.