Emails being blocked since we went to "dedicated environment"

[Jim Cockerham]

Our servers do not currently perform DKIM signing of messages.

David , I see that this quote was from several years ago. Is it possible yet to get DKIM signing for Miva transactional emails?

[wajake41]

We are going to pursue one of the options mentioned here.

[alphabet]

Thank you, I'll wait a few months and check in again on Plesk 17.

It's not an urgent problem, just the "unverified sender" mouseover message that doesn't look credible in the inbox.

[ILoveHostasaurus]

The SPF record has no relation to DKIM signing, so tweaking it for DKIM reasons is not necessary.

Our servers do not currently perform DKIM signing of messages. There are three options to get it; one would be use a transactional email provider for the store emails, but you'd need the relevant DNS records from them put in place before it would matter since the header without the matching records doesn't do anything. Two would be a manual reconfiguration of the mail server software on your server with us; we have not done this before but there is a document on how to perform it, we'd just charge a fee related to the labor time required. Three would be the control panel software we use, Plesk, version 17, which was just released. There are still a lot of bugs so I would not recommend that at this point in time, but perhaps in a few months when it is more stable, we could update you and it has all the currently-manual reconfiguration steps built in.

That being said, my experience has been that most of the providers who we tend to have these blocking issues with don't utilize DKIM anyway, so it may not solve the problem. Most of the providers with the issue are still relying on anti-spam techniques from 15 years ago, hence the blocking of IP address ranges that have never been used for mail before.

[alphabet]

Hi David,

I'm having problems with my transactional emails being authenticated using DKIM.

I'm using google as my mail exchanger and Cloudflare for my DNS. The MX records correctly point to google.

Other company emails that I send through google are authenticated, it's just the transactional emails that are affected.

Our general SPF format for customer domains is:

v=spf1 a a:server.mivamerchant.net ~all

which covers mail coming from the address of the site itself, and mail coming from the server's primary address.

If such a change were made, your domains' SPF records should be altered to have an additional directive of include:_spf.google.com

For DKIM authentification purpose would the spf record then need to use both the a and include mechanisms?

v=spf1 a a:server.mivamerchant.net include:_spf.google.com ~all

Does server.mivamerchant.net or google, as the MX exchange, create the signing algorithm for the authentification mechanism?

[Ron Frigon]

This is awesome. Thank you for the explanation. And I'll update my SPF record.

Cheers!

[ILoveHostasaurus]

The issues are threefold; AT&T does reputation-based filtering, AT&T is too big for the left and right hands to know what the other is doing, and the world is almost out of IP addresses (IPv4).

We have plenty of addresses in reserve, however, new servers require new addresses to deploy to the network, regardless of whether a given website's own address can or can't be moved with the site to a new server. If a customer is going from shared hosting to enterprise hosting, we're internally going from one shared server to one shared server plus one enterprise server, and therefore a new IP address must be used for the server itself.

The addresses we have available for new servers have never been used and date back to the early 2000's, so they effectively have no reputation of having sent mail before. Some entities like AT&T stupidly reject email from addresses like these while they wait for them to 'warm up', instead of simply accepting email and only penalizing if complaints result. The only solution to this issue for a given address is to keep sending and sending so it builds reputation. On our side, we can and will repeatedly bug the anonymous AT&T mail block removal address and online forms, but they never let you talk to a real person or know who helped you, so we have no way to route these requests to someone we know will fix the issue, so sometimes things get fixed and then return.

Hi Ron:
I think it's the same issue. However support has had to request at&t to unblock us several time already since going dedicated environment. And we've had the same issue with others, the latest being the example I show above.
The latest from support is a suggestion about getting a personal gmail account. The boss responded to me about their suggestion:
"Miva wants me to have all emails go through a personal gmail
account instead. I'm not sure that will look very professional though.
They said I can make it my domain name still but I have concerns. It sounds
like that may be the only way they know of fixing this issue."

Thanks for the reply.
Larry

The idea of this workaround is to route email through a provider that is 'too big to block'. AT&T and others will never block IP addresses of Google and friends, often even if the addresses are being legitimately abusive, because it would cause them too much collateral damage and inbound support requests from their customers who aren't able to receive emails they want.

The account does not have to be a 'personal' gmail account, but it can be, and that is an easy free solution. Google does not include the account which was authenticated against in the message headers, so a recipient of the message in question from your store would see everything being just like normal, with the only difference being that if they viewed the headers, it would show as having an additional "Received:" header, where first would be from store to server, then from server to Google, then Google to recipient server.

A personal gmail role account could be created solely for this purpose, or if you use paid Google Apps or Enterprise for email, that works too. On the personal gmail side, you just have to go into settings, add the email address your store will be sending from as a "Send mail as" account, which will require some authentication credentials and validation, and then it's able to be used to send through the Gmail account.

If such a change were made, your domains' SPF records should be altered to have an additional directive of include:_spf.google.com

Other similar solutions would be routing the store-generated transactional emails through mail providers like SendGrid, etc.

>> support has had to request at&t to unblock us several time already

Ya, I did that a couple times too. Fortunately I didn't have issues from any other domains, that I know of... It seems to me that if you switched over to Gmail as your Mail host then the problems of a new IP address would just start all over again?

The problems would not return because the mail delivery for the store would go from an IP with no reputation to one from a provider AT&T is scared to block.

Seems like Miva should have a solution for this.
If I remember correctly the issue started when we got the dedicated environment and our IP address changed. After having emails blocked because of that, they suggested we change to host deda271.mivamerchant.net.
The issue continues and I wonder if changing the host wasn't a mistake. Might have been better to wait out the IP address change?

If the store uses 'localhost' or its primary server name as the relay host, the resulting mail should come from the same IP either way, so I'm not sure why that suggestion was made, but I don't know the details of the ticket. Mail coming into the server via localhost, or its primary IP, will usually always send outbound from the server's first IP address.

>> Might have been better to wait out the IP address change?

Probably

If you were previously hosted with Miva, then moved your site to a dedicated server, the best solution would have been to NOT change your IP address. Even though you changed physical servers you should have been able to keep the IP address, if you were hosted with Miva. We've had to move our sites to new servers in the past and were able to keep the same IP addresses. IP address changes can be a real nightmare in a lot of cases. Especially credit card processing.

Keep in mind that such a change, even if your site IP's remain the same, will generally not prevent the IP seen in outbound emails or credit card auth requests from changing. When the operating system of the server needs to make an outbound connection, unless the software making explicitly states which alias network interface to use, the operating system is going to use the 'first' interface, which is the one with the server's IP and not any of the site IP's. So although the inbound traffic to a given site would still come to the same IP it had before, the outbound 'initiated' connections would come from the server's first IP, and if it's a new server, that would be a new IP.

There is one way around that. Our servers are set to send mail on the same IP mail came in on if it's something that is not to be delivered locally. So, if domain.com with IP address 192.0.2.1 moves to a new server, and the store is set to send mail via authenticated SMTP to mail server mail.domain.com on IP 192.0.2.1, then those messages are going to leave the server from that IP instead of the server's primary IP.

A side note from our Operations Manager:

>> On this I would check PTR and SPF records. It might also be DMARC or DKIM but I am not very familiar with those.

After moving my website to Miva I did add my new IP address to my SPF record, not sure if it helped, but it can't hurt.

In your DNS settings add a new TXT record:

v=spf1 a ip4:xxx.xxx.xxx.xxx/32 ~all

Replacing xxx.xxx... with your IP address.

If you already have an SPF record, make sure it contains your new/current IP address.

On servers with us you should generally not use the ip4 mechanism for an address here if it can be avoided. The reason is that most of our servers are 'dual stack' enabled, meaning they have both an IPv4 and IPv6 address, and mail leaving the server will prefer IPv6 if the remote mail recipient is IPv6-enabled, such as all Google accounts.

Our general SPF format for customer domains is:

v=spf1 a a:server.mivamerchant.net ~all

which covers mail coming from the address of the site itself, and mail coming from the server's primary address. The catch is that the 'a' mechanism automatically covers a matching AAAA (ipv6) record as well. So if a site has an IPv6 address, or if the mail goes out via the server's primary IPv6, the a:server.mivamerhant.net will cover it whether it's delivered via IPv4 or IPv6.

[alphabet]

DKIM uses a TXT record for a RSA 2048 public key to validate the sender of the email.

You can create a separate TXT record for any third party that send email on behalf of your domain.

DMARC sets a policy on how the recipient should handle unverified email and can send a daily report to the domain's postmaster.

[Ron Frigon]

A side note from our Operations Manager:

>> On this I would check PTR and SPF records. It might also be DMARC or DKIM but I am not very familiar with those.

After moving my website to Miva I did add my new IP address to my SPF record, not sure if it helped, but it can't hurt.

In your DNS settings add a new TXT record:

v=spf1 a ip4:xxx.xxx.xxx.xxx/32 ~all

Replacing xxx.xxx... with your IP address.

If you already have an SPF record, make sure it contains your new/current IP address.

[Ron Frigon]

>> Might have been better to wait out the IP address change?

Probably

If you were previously hosted with Miva, then moved your site to a dedicated server, the best solution would have been to NOT change your IP address. Even though you changed physical servers you should have been able to keep the IP address, if you were hosted with Miva. We've had to move our sites to new servers in the past and were able to keep the same IP addresses. IP address changes can be a real nightmare in a lot of cases. Especially credit card processing.

[SunCam]

We had a problem delivering transactional emails but found a solution. Miva hosts our main domain (suncam.com) but we own lots of other suncam domains so we use suncam.info on MailGun for our transactional emails. We tried gmail but ran into unacceptable traffic limitations. MailGun has solved the problem that we had with deliverability. It is free for our level of usage and nominally priced even if you do a huge volume.

[wajake41]

Seems like Miva should have a solution for this.
If I remember correctly the issue started when we got the dedicated environment and our IP address changed. After having emails blocked because of that, they suggested we change to host deda271.mivamerchant.net.
The issue continues and I wonder if changing the host wasn't a mistake. Might have been better to wait out the IP address change?

[Ron Frigon]

>> support has had to request at&t to unblock us several time already

Ya, I did that a couple times too. Fortunately I didn't have issues from any other domains, that I know of... It seems to me that if you switched over to Gmail as your Mail host then the problems of a new IP address would just start all over again?

[wajake41]

Hi Ron:
I think it's the same issue. However support has had to request at&t to unblock us several time already since going dedicated environment. And we've had the same issue with others, the latest being the example I show above.
The latest from support is a suggestion about getting a personal gmail account. The boss responded to me about their suggestion:
"Miva wants me to have all emails go through a personal gmail
account instead. I'm not sure that will look very professional though.
They said I can make it my domain name still but I have concerns. It sounds
like that may be the only way they know of fixing this issue."

Thanks for the reply.
Larry

[Ron Frigon]

Yes, I've also had this issue. I don't think it's a Miva issue, in my case. The IP address changed for my website, so AT&T sees the email coming from the wrong IP and blocks the email as spam. AT&T needs to update something on their end so they know that the site has moved to a new IP address. Cleared up in 2-3 weeks in my case.

The message I was receiving:

Reporting-MTA: dns; web032.mivamerchant.net
X-Postfix-Queue-ID: 48EED10828967
X-Postfix-Sender: rfc822; [email protected]
Arrival-Date: Sat, 22 Oct 2016 11:22:43 -0400 (EDT)

Final-Recipient: rfc822; [email protected]
Original-Recipient: rfc822;[email protected]
Action: failed
Status: 5.3.0
Remote-MTA: dns; al-ip4-mx-vip1.prodigy.net
Diagnostic-Code: smtp; 553 5.3.0 alph138 DNSBL:ATTRBL 521< 216.188.128.208
>_is_blocked.For information send an email to [email protected]


Not sure if this is related to your issue or not...

Ron