Email is used by businesses every day. Business correspondence is a core use, but email is used by applications to send surveys, notifications, data exchange, reports and alerts. Email’s universal adoption makes it a prime target for hackers looking to compromise businesses so it must be protected by filters to protect users, but which also risk stopping important emails. To make things more complicated, each antivirus vendor creates their own filters to detect unwanted emails and companies themselves often make further adjustments based on their own security rules and procedures. Feedback is not sent back to the sender for quarantined emails to avoid revealing information that could be used by bad actors.
In the face of uncertainty regarding email deliverability, business partners using email as part of their service often request email addresses or domains whitelisted to guarantee emails are delivered to recipients. While this does have the intended effect, I believe it is not the right approach.
Why Whitelisting is the wrong approach
Note, this article focuses on whitelisting as it relates to applications, as this is where I see most requests for whitelisting. If you are a business with your own email domain, and you are having issues with delivering regular emails to your customers, start by checking you have configured SPF and DMARC. Most email providers create suggested records you can add to DNS, and this should noticeably improve the situation.
As most people are aware, it is very easy to forge the sender email address. Once a company has whitelisted an email address, anyone on the Internet can use that address to send to the company, and it will be delivered to the recipient’s inbox. Worse yet, if the sending company is sending from the same email address to multiple companies, which have all whitelisted the address, the same forged email address could give access to many companies. This is bad for the receivers, but also for the company that owns the email address. What company wants to be responsible for their customers being compromised?
Alternatives to whitelisting
As the person responsible for your company’s email, what should you do when you receive a request for whitelisting? Luckily, developments in email authentication have made whitelisting largely unnecessary. Once you have decided not to whitelist, what should you do instead? Here are my recommendations:
First, the sending company should take as much responsibility for the delivery of their emails as possible. This means configuring SPF, DMARC and preferably DKIM on their end. Emails need to align with DMARC. (DMARC alignment is outside the scope of the article but look for an article on the subject here soon.) DMARC policy for the sending domain/subdomain should be set to quarantine or reject, but any DMARC record better than none. If the sender doesn’t send their emails so that their emails are deliverable, there isn’t much the receiver can do.
If you are thinking this is more work than just whitelisting the requested addresses, that’s true in the short run, but you are investing in better security and less maintenance down the road. In my experience vendors/business partners are willing to make changes if you make the effort to explain why it is important and help them understand what changes need to be made.
Once the above configuration is done, the receiving company should check that their email filters do not quarantine emails based on the volume of emails from a sender. Although some senders throttle emails to avoid this type of filter, it isn’t effective and is just one more thing that can go wrong.
Additional steps to take if emails are still going to quarantine
Hopefully, the above recommendations are enough, meaning no more setup is needed to ensure email delivery, but if system emails are still going to quarantine, here are a few more things you can do.
If you have implemented the above recommendations and emails are still going to quarantine, we suggest adding the email address to a DMARC pass rule, which allows emails from specific addresses when they pass DMARC. You can set up a single rule for DMARC pass and then add email addresses to the rule as necessary. Setting up the rule will be different depending on the email system you are using. Some systems allow you to create a rule directly based on DMARC results, while others require you do this via x-headers.
The difference between traditional whitelisting and using a DMARC pass rule is that a bad actor cannot spoof the email address and pass the rule, even if they know the rule exists. The DMARC pass rule relies on DMARC so the first step is always for the sender to set up DMARC and then add addresses to the rule as necessary.
By deciding not to whitelist you improve your company’s email security and even make email a bit more secure for everyone by encouraging vendors to implement DMARC.
While you are at it, why not check if you have whitelisted addresses that are no longer needed. You could start by removing inactive addresses (you can use message trace to identify inactive addresses). Once you have removed inactive addresses you could check for active addresses you can move from your whitelist to your new DMARC pass rule. I suggest making changes gradually over a few days, in case something unexpected happens, you won’t affect multiple systems at once.