Increased Email deliverability is an important business need. If your email does not arrive at  your customers’ or suppliers’ inboxes, then you are no longer top of mind nor part of their considerations, let alone the fact that your business purpose cannot be served in a timely manner and you are reduced to calling them to receive a reception acknowledgement.

A dialogue like this, is definitely something you have experienced being on either side.

-Did you get my email?

-No!

-Can you please check your spam folder?

-oh, I see it now….

 

This “I see it now”, may affect your organization’s prestige or make you lose an important deadline.

 

There are many reasons why emails go to recipients’ spam folders. I will try to summarize some of them.

1. Lack of appropriate DNS entries on your DNS server, such as:
   1. SPF records
   2. DKIM and
   3. DMARC compliance issues
2. Overall health of your Internet Service Provider (ISP)
3. Overall health of the email server used to send out your emails
4. Outgoing email volume sudden change between time periods.

We will see each one of the above in the paragraphs below.

 

1. Lack of appropriate DNS entries on your DNS server.

This point takes for granted that you have access to your DNS servers so as to create or update your DNS records; if you do not, then you should get access and then come back.

If you do not know what DNS does on the internet, then you should have a quick read here, before continuing.

• SPF records.

What is SPF record?

Sender Policy Framework (SPF) is an email authentication method that specifies the mail servers authorized to send email for your domain. SPF helps protect your domain from spoofing and helps ensure that your messages are delivered correctly. Mail servers that get mail from your domain, use SPF to verify that messages that appear to come from your domain, actually are from your domain.

A good way to create your own spf records is www.spfwizard.net and I suggest you combine it with mxtoolbox.com, while a good way to test those records is mxtoolbox.com.

• DKIM

DKIM (Domain Keys Identified Mail) is an authentication process that can help protect both senders and recipients from forged and phishing email. By adding DKIM signatures to your domain, recipients know that email messages actually came from users in your organization and they were not modified after they were sent.

You can create it here: tools.socketlabs.com and you can test it here: mxtoolbox.com after putting the records on your dns.

 

A server administrator maybe needed if you don’t have full access on it, or you are on a shared hosting environment. Even better, your hosting may have already put those records for you.

 

In the case of a Microsoft 365 implementation the process of creating DKIM is different as in this case, Microsoft 365 requires CNAME records instead of txt records. You can follow guidelines provided from Microsoft for that on your Office 365 portal > Admin > Exchange admin center > Protection > dkim.

In this particular scenario your test to mxtoolbox, stated above may fail, as it is looking for txt record rather than CNAME records your zones is providing. So, do not panic, you are correct, as long as Microsoft 365 admin panel states so.

• DMARC

DMARC, which stands for “Domain-based Message Authentication, Reporting & Conformance”, is an email authentication, policy, and reporting protocol. It builds on the widely deployed SPF and DKIM protocols, adding linkage to the author domain name, published policies for recipient handling of authentication failures, and reporting from receivers to senders, to improve and monitor protection of the domain from fraudulent email.

DMARC compliance is another DNS related issue whose failure can result in unsuccessful mail delivery.

You can create it here: mxtoolbox.com and you can test it here: mxtoolbox.com.

If all the above points are covered, then the chances that your mail is classified as spam become really slim. However, we have experienced issues with that when we face DNS availability issues.

To check your DNS health, you can try dnschecker.org and we suggest doing this regularly.

A friend of us, old IT Professional keeps saying:

“The root of all cause is DNS”

 

2.Overall health of your Internet Service Provider (ISP)

ISPs have a reputation regarding email delivery, and their reputation regarding spam is measured against UCEPROTECTL2 or UCEPROTECTL3 criteria. If you are blacklisted on the UCEPROTECTL2 / L3, then you are unlucky, as you may have an IP Address from your ISP that falls into a poor reputation range. Most of the times, the entire range of IP Addresses is blocked as a result of the fact that this provider hosts spammers. It’s a good administrator practice to check against those blacklisting criteria when your provider assigns you a new IP  range or even a new static IP address. You can always refuse to accept an already blacklisted IP!

Subnet-based Blacklists are used to reject email from entire ranges of IP Addresses, i.e. providers that are hosting companies sending spam, as well as single IP Addresses that may fall in that range of IP Addresses. This blacklist type does not offer any form of manual request to delist. Your IP Address will either automatically expire from listing after a given timeframe, or after time expires from the last receipt of spam into their spam traps from your IP Address.

 

3. Overall health of the email server used to send out your emails

That was the part of the ISP, but you also should definitely check your email server against blacklists as part of your regular maintenance process. One of the most widespread tools to try regularly is mxtoolbox.com. In this and others, you can check whether your IP is registered on spam and other offender databases.

 

4. Outgoing email volume sudden change between time periods.

Hm, that is something that needs to be taken into consideration. Suppose you have no problem with your email deliverability for quite a long time, and suddenly your emails land to your recipients’ spam folders. What is wrong? You may need to check if you have a change in the volume of your outgoing emails and if you don’t have a systematic way to do that, you may check a posteriori on talosintelligence.com.

It may be a secretary sending out wishes for Christmas, or a new campaign launched from your marketing department. All domains have an average of outgoing volume and if there is a significant increase, then Talos may report it, and as other spam engines take its word for it, a chain reaction of blacklisting may come into play.

This is exactly what happens, when a computer in your network is infected with some kind of Trojan or malware that fires around to recipients around the globe. The longer the incident carries on, the wider the damage is and your IP is being listed to more and more spam registry databases.

Tough ha? It is! Email deliverability is a constant battle as many others in IT. You have to be cautious; you have to check regularly and be fast!

Increase Mailchimp deliverability

Especially for marketing purposes, many corporations utilize the MailChimp service, in order to manage mass mail sending.

A good practice would be to enable GDPR forms for your audience. For this go to audience > settings > GDPR fields and settings

A few tips related to DNS modifications follow.

• To increase deliverability through MailChimp do not forget to:
• 1. Verify and
  2. Authenticate your domain.

This can be found under account (top right corner) > Profile

Settings > Domains

Your domain should be both verified and authenticated. Please note that in order to be authenticated it has to be verified first.

A very important thing to have in mind, when you use MailChimp for mass mail sending: No matter how hard you try, no matter how cautious you are with your DNS zone configuration, regarding spf, dkim, dmarc, etc., you will never avoid Mailchimp emails bounce on certain domains. Which (recipient) domains? The domains that strictly take into consideration your spf records.

Example: You have Office 365 deployed in your organization and if until now you had no reason altering the spf record proposed by Microsoft then your spf record would look like this

“v=spf1 include:spf.protection.outlook.com -all”

At the end you will notice a “-“. When you have this, it means that the recipient server should reject non-compliant emails, whereas when you use “~”, the recipient should accept but mark as spam.

The reason is that Mailchimp does not support SPF, as it uses its own domain in the bounce address. Their domain authentication verification tool requires including Mailchimp, though. Mailchimp always fails DMARC’s SPF alignment test because the Return-Path path does not match the “From” address. MailChimp does not support custom Return-Path (even though Mandrill, which is owned by Mailchimp, does). This makes it impossible to be 100% SPF-compliant under DMARC rules with Mailchimp.

There is one cheap trick you can do.

Before you launch and for as long as your Mailchimp campaign is running, you should switch your spf record to:

“v=spf1 include:spf.protection.outlook.com ~all”

And after your campaign ends revert it back to

“v=spf1 include:spf.protection.outlook.com -all”

Nevertheless, Mailchimp recommends SPF setup using “~all” instead of “?all”. It does not state using “–all“.

Computer technology is the, unfathomably evolving, assisting prosthesis to societies, economies, and individuals, attempting to persevere in a world stricken by the pandemic.

And yet sometimes…it – the prosthesis – does not fit all that well. Sometimes the grafts get rejected… Or the amputee rehabilitation fails – since he/she/they never lost the limb – they must learn to use. Or even – and here is where all immersion in medical similes fails spectacularly – someone gets control of that extra *insert appendage of choice* and gives  you a thorough thrashing with it.

Avoiding said thrashing is the job of data security. But how do we go about implementing it? More is more right? Is the weak point the manufactured one, the interface, or the user-patient?

In the yesteryears, everyday tools got away with laconic big WARNING signs. Using a bandsaw for example, one did not have to be a master-luthier to associate mistakes with delimbing one’s self. That is not the case today though, when the tool evolves constantly, along with its associated risks, but the user and his ability to understand it remains the same. We keep stacking new technologies and implementations one upon the other, but leave the user to his own devices? The “binomial” will keep getting more and more precariously balanced.

So, what does the IT-doctor prescribe?

Complete automation?

I mean yes…we could fully restrict and monitor each and every user’s activity to the point where they work on a fully sterilized environment. Will this promote productivity though? And more importantly are we certain we can maintain such condition permanently? Finally, can we persuade our clients that they need to keep paying for such an implementation?

Well, we always come back to the adage (sic) “Τhe user needs the expert and vice versa”.

The users need to be educated and appreciative of the dangers lurking in their work environment. A pop-up warning is not something to be ignored or even scared of.

Simplified and concise knowledge of what the various paraphernalia, installed by the IT department, do is key. Such training will allow the user to better understand and notice irregularities, to trust and inform the IT Department timely and point them in the right direction. Mind you “this icon should be green” should not be considered simplified but rather dumbed down.

“This is my AntiVirus | Firewall | VPN client | OS Updates | […], it does […]” should be something taught and familiar for all users requiring a workstation to function. Such education becoming the norm, will fortify against social engineered attacks/phishing attempts as well.

Starting from the fundamentals makes more “convoluted” necessities & requirements easier to understand and not “just something the IT claims we must do”. Security should never interrelate with inconvenience in the users’ minds.

Clients’ Management & HR understanding and approving the above, will certainly be more amenable to go further down the rabbit hole with triple A controls, backups & recovery, encryption, masking, erasure police etc.

See you all safe and sound in the next installment!

 

Various tidbits and rumblings by Apostolis Drakakis

Any meme resemblance to actual persons and work conditions is purely coincidental.

It is a recurring phenomenon, in the IoT era, for network devices to be required to send emails and have access to SMTP functionality.

Thus, most device manufacturers attempt to follow through and implement the contemporary security protocols while designing and when firmware patching is possible.

However, only so much can be done by firmware updates on aged chipsets, whereas communications security protocols keep evolving, have their vulnerabilities exposed, depreciating, and getting replaced.

So how do you proceed when such a device finally shows its age?

We were called to resolve such a case when a domestic ISP finally decided it was time to upgrade its mailing services to TLS 1.2. This caused a broad range of all-in-one network printer/scanner/copier devices, used in corporate environments, to be unable to use any of their “mail to…” services as the TLS protocol was not possible to be implemented.

The Work-around.

The client employs a Windows-Server-based infrastructure.

A Windows Server VM was setup and IIS Services, SMTP Server and Telnet client features were installed.

TCP 25 (RFC5321) port was opened.

Minor nitpick: As IIS 8 cannot manage SMTP services, for the rest of the tasks we used the IIS 6 embedded console.

We proceeded with configuring the allowed hosts that can connect to this SMTP server:

Loopback IP and the address of the afflicted network device (in our case a printer/scanner/copier)

Smarthost must be configured next. We used the corresponding mail server of our domestic ISP and the available corporate mail account with enabled TLS.

For the last step we returned to the management interface of the All-in-one device and on the SMTP configuration page we replaced the SMTP server from the IP of our ISP to the IP of the newly-setup Virtual Machine.

The story’s log

Ricoh MPC 2050 incorporates a scan to email functionality many years now, but does not support sending out emails over SSL, therefore we introduced the idea of putting a local smtp server in the network that could handle “unauthenticated” open relay and submit on behalf of the sender through the ISP, in our case Cosmote.

Picked up a vm with low resource consumption footprint and Installed the IIS 8 role and SMTP server feature.

IIS 8 cannot manage smtp service, so we used the IIS 6 embedded console.

Configuring hosts that can connect to this smtp server: 127.0.0.1 and the MFP MPC2050 IP address.

Configured as smarthost the mailgate.cosmotemail.gr using the customer’s email account XXXXXXX@otenet.gr and enabled TLS.

Opened up port 25 TCP incoming on the VM’s windows firewall.

Changed the smtp server on MPC 2050 from the resolved ip of mailgate.cosmotemail.gr to the VM ip address 192.168.2.26.

Unless an IP spoofing is made, the VM’s SMTP will never send out emails of this kind.

Now how to test the setup? We are not there, and we cannot scan.

Testing with the Pickup directory: You can compose a simple e-mail text file (with no extension!!!) based on the SMTP specifications (RFC 822).

Here is the content of a sample text file typed in Notepad:

From: xxxxxxxxx@otenet.gr

To: yyyyyy@creativepeople.gr

Subject: testing

This is the test message body.

Simply copy or move the text file into the Pickup directory where SMTP was installed.

With the above configuration the SMTP service will periodically check the Pickup Directory (%systemdrive%\Inetpub\mailroot\Pickup and %programfiles%\ Exchsrvr\Mailroot\Vsi 1\Pickup if you have Exchange installed.) and will attempt to deliver any messages found in the directory.