MIVA email security issues

[marshallw]

I hope someone can help out with this. We have had issues with emails from miva merchant and regular email clients going to spam of customers. So, I did some digging on how to fix the issue, and the best way to solve this was to authenticate all emails via 3 methods. SPF, DKIM, and DMARC. These all work together to verify an email originated from the correct server, and has a key that matches on both ends. We use Exchange Online (Microsoft 365) and it wasn't to hard to implement all three of these protocols for email. However, I have run into an issue on the side of miva. Miva sends out order confirmations, shipping notices, customer account info, etc. from it's own localhost email. This fails the test because it is a difference server than our exchange and does not have the secret key to verify it is a legit email. So, I have two issues I can not seem to solve.
1. Getting MIVA to actually connect to exchange online and send emails through our server. or

2. Have the localhost added as an alias with DNS and have the DKIM key.

Has anyone figured out how to do this? I can not seem to find any info in the dev docs that is helpful.

Thanks,

[ILoveHostasaurus]

The Miva Merchant software can have the SMTP server set to your 365 server, and appropriate credentials given to send through it. Keep in mind that Microsoft adds an intentional delay to SMTP authentication because they do not want anyone using the platform for transactional emails, and each store email will incur a 10 second or so delay, so it can make a typical checkout take 10 to 30 seconds longer than normal.

Our recommendation would be to use an entity like SendGrid; few dollars per month for up to 50,000 transactional emails, ramps up slowly from there. They assign you a custom subdomain where they apply all the authentication / validity headers, the From still shows normal, they deliver from very high volume networks so you aren't penalized by your own email volume, no issue with the Microsoft delay, and extensive reports on deliverability.

[oliverands]

Seems like this might be an opportunity for Miva.

Instead of getting out of the business of providing email service on domains that it serves (which is causing headaches like this and others to clients who are paying a premium for what Miva does), it might make sense to double down and improve email services related to the stores it serves.

It's another way of differentiating from the $29.95/month competition.

If I could integrate my email marketing, customer service, and transactional emails with my store and use a single provider for that instead of multiple providers, I would be happy to pay Miva a little more each month.

Oh, and content delivery networks too. Cloudflare, AWS Cloudfront, and other custom solutions? Please. Just take care of this automatically for me and take my cost up a little every month so I can simplify my store's administration. Overall, it's a savings and makes my life easier.

There's been a recent investment made in the company to do things like this, right?....

[Rick Wilson]

Todd,

The recent investment is obviously to help us grow, however not really in the way you describe.

We might partner with SendGrid and offer that as an add-on, same concept with Cloudflare. We're certainly not going to build those services ourselves. To be effective that way (by buying or building) we'd have had to have raised billions of dollars.

The Gmail team and the Microsoft 365 Team (not to mention SendGrid) have collectively between the 3 of them somewhere in the ballpark of 10,000 employees just working on email, security of email, spam, delivery, etc...

Email (to do it right) is HARD and not our specialty, so at best we'll build in easier to configure connectors and offer an easy way to sign up with those types of partners. Same with a CDN like Cloudflare, build in a connector, make it more seamless and easy to sign up for their service, but doing a CDN well is a huge business and we have no intention of getting into being a CDN.

But it's worth noting there is actually no competition at $29.95 a month, if you start at Shopify's price point there you pay an additional 2% of revenue on top of it (either directly or by being forced to use their payments) plus you pay for the add-on modules it would take to add functionality, generally to match Miva functionality around $1k a month in recurring module add-ons for Shopify.

Even a WooCommerce store (which is technically "free" since it''s open source on top of WordPress) is going to quickly get to $500 - $1000 a month once you include hosting, add-ons, etc...

Our goal/vision is to be the best customer focused Ecommerce platform for mid-market and emerging enterprise customers (people doing $1 million - $100 million in online sales), that provides a full featured solution for D2C/B2B/B2B2C merchants that have more complex business needs than a typical Shopify merchant (complex catalogs, customizable products, B2B/D2C in the same site, complex shipping/payment/tax rules, deep back end integrations, etc....)

We definitely want to make your life easier so to speak as we do for all of our customers but it won't be through a Microsoft Works type of product bundle (from our perspective those products never really win in the long run).

[marshallw]

The Miva Merchant software can have the SMTP server set to your 365 server, and appropriate credentials given to send through it. Keep in mind that Microsoft adds an intentional delay to SMTP authentication because they do not want anyone using the platform for transactional emails, and each store email will incur a 10 second or so delay, so it can make a typical checkout take 10 to 30 seconds longer than normal.

Our recommendation would be to use an entity like SendGrid; few dollars per month for up to 50,000 transactional emails, ramps up slowly from there. They assign you a custom subdomain where they apply all the authentication / validity headers, the From still shows normal, they deliver from very high volume networks so you aren't penalized by your own email volume, no issue with the Microsoft delay, and extensive reports on deliverability.

I am yet to even get our office 365 account to connect via MIVA. I am constantly hit with authentication errors. I have added all the settings in "domain settings" in MIVA but it just fails constantly.

I am not really wanting to add yet another service (already have to pay monthly for taxes, shipping, and payment portals) to MIVA, just to send emails. The issue is MIVAs servers are not passing DMARC / DKIM (which is a pretty common email check). I am not sure if this is a DNS fix via Plesk. Gmail is the biggest culprit, they send miva emails to spam because they do not pass these two tests.

I would like to get this figured out, in house.

[ILoveHostasaurus]

Typically the issue sending through 365 is not disabling the two factor requirement on the email account being used for the store to send from, or not enabling SMTP authentication on the same account. Most Office 365 domains are set to 2fa "enforcing", or set for only OAuth-based authentication from supported apps. Either issue then affects all accounts and prevents traditional SMTP authentication. Setting the 2fa requirement to "optional", which will leave it on for all accounts and still default to on for new ones, will let you then explicitly turn it off just for the account the store has been set to use. We don't have docs on this because the method for enabling SMTP authentication changes frequently with Microsoft; the URL with the steps was updated two months ago: https://docs.microsoft.com/en-us/exc...mtp-submission Our support staff may be able to walk you through the right places to click or do a screen share from you to them to try to find the correct settings on the 365 side.


That being said, when a customer's domain uses Office 365 for email, there is no way for us to possess the DKIM key we'd need to resolve this for you in-house. The process of enabling DKIM on the 365 side involves their generation of your signing key with no way to export it. Our mail server must be in possession of that key to sign the outbound emails to match the published DKIM data in your DNS records. The only solution to DKIM on your root domain is to have the store send through 365 and not us.

An in-house solution would be for us to do the same thing SendGrid does, which is send your email from a custom subdomain where we're in possession of the DKIM key. This would mean we create a subdomain for you, generate a DKIM key we possess, publish the various records to DNS for the subdomain and public key data, then sign emails with it. That would have us attempting to do what SendGrid does at a lower price point, in a more reliable manner, and with an easier setup, which is not likely to be the actual outcome. It is more likely we partner with them like Rick mentioned. That would hopefully result in a favorable price we bundle in, allow all of our customers to use their service, and build a streamlined setup to solve the problem that way. However, that is not available today and you need an immediate solution, which would be sending through your 365 account, or a transactional email service like a retail SendGrid account for $14.95.