One of the calls that a CISO hates getting is the one from a customer who just received documentation from a vendor they have contracted to allow all of their emails coming from a certain domain through to an allow list so they don’t end up in the spam folder. The reason why we dislike these calls is because we have invested significantly in adding protection. This is because a significant amount of the Phishing, Business Email Compromise, and Malware emails come from computers that don’t have email security controls or are set to bypass them.
Asking us to remove protection for a domain is asking us to give an avenue to allow phishing emails in from it that put the entire network at risk. Many of us discuss disciplining team members who click on the links in phishing email tests. However we don’t hold the team members who bring in third parties to send bulk messages to the workforce that bypass security controls accountable. These messages often have links to click in them that go to web sites that are indistinguishable from real phishing sites. This is an incongruence we have to also address.
Any message that comes from these allowed domains instantly bypasses security controls, even if they come from a malicious source.
Allowing these sites in and expecting team members to distinguish them from actual phishing sites is difficult. This is compounded by the primary caregiver devices being smartphones. This is also compounded by their user interfaces making it extremely difficult to see where links go. It is possible in iOS or Android. However, it’s not intuitive.
If we allow all emails from a company to be marked as safe and trusted, what happens when their domains get compromised? Several of the large data breaches that have occurred over the past year have included marketing firms or data aggregators. We’ve already seen emails from healthcare providers used to send phishing messages that bypass security controls. In several cases, it was because they utilized a message encryption platform in common that bypassed border email security. This enabled phishing messages to bypass security controls and directly reach the inboxes of caregivers.
What happens when criminals Google the words “add the domain to the whitelist” and send emails as those domains? You’ve given them a means to target your company. People add domains to allow lists because it’s easy. Larger companies such as Proofpoint, SendGrid, Google, Emma, Microsoft, Constant Contact, or Oracle have good email security set up to prevent this. Microsoft must be given credit for making configuring good email security easier to set up in Microsoft 365.
Today we’re going to give you the information you need to fight just allowing third parties to send to your domain without security checks. Email, despite the emergence of secured messaging, Microsoft Teams, Slack, and Zoom, is still very popular. Just blindly allowing mail from a domain takes the investment you’ve made to protect your caregivers and team members and significantly lowers its value.
We’re going to ask that you require anyone that sends you mails to follow the Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) standards. By requiring all three, you ensure that all inbound emails follow the same security controls. You also reduce the risk of spoofed emails bypassing controls and putting Phishing or Ransomware emails right into your environment. We’re also going to go over what you can do to protect Domain Name System (DNS) servers in your organization.
Sender Policy Framework (SPF)
Sender Policy Framework (SPF) is a technology that leverages your organization’s DNS Servers to identify who can send mail on your behalf. This requires your organization to identify servers and domains that directly send your mail and send it on behalf of you. This is something you enable so that random computers just can’t send email claiming to be you. You can generate SPF records for your domain here or check the SPF records for a domain using MX Toolbox here. These are good tools that we recommend using that make it simple to verify these records in real time.
DomainKeys Identified Mail (DKIM)
DomainKeys Identified Mail (DKIM) uses digital signatures linked to the domain names used to send email to prevent forgery. This technique requires the use of a digital signature appended to each email and a public key published on your DNS servers. Recipients can look up the public key and cryptographically verify the digital signature to ensure message authenticity. Microsoft provides an excellent guide on how to set it up for their services here. Mailjet also provides a good guide that we also recommend here.
Both require secured DNS technologies, as does DMARC. SPF and DKIM are all for naught if you do not protect your DNS servers. If you host your own DNS servers, make sure your organization leverages the guidance provided by NIST in Special Publication 800-81-2, Secure Domain System (DNS), available here. If you choose to use a third party, make sure they have good SPF and DKIM support. In both cases, you want to use two-factor authentication that is not based on SMS text messaging. Changes to DNS by unauthorized people mean that they can send mail as you too.
Also remember to secure your records at your domain registrar of choice as well. Again, you want to use two-factor authentication not based on text messaging. Also utilize a group mailbox for warnings or messages that goes to more than one person. It’s very difficult to recover a domain from someone leaving the company, or a compromise. Protect your registrar so that you have one less avenue for someone to compromise your security.
Domain-based Message Authentication, Reporting, and Conformance (DMARC)
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a standard, based on RFC 7489. It builds on DNS and DKIM to provide a DNS-based method for sending domains to quickly ascertain the email security policy of the recipients. It uses DNS records to advertise the following:
- Whether or not an email domain supports relaxed or strict enforcement of SPF
- Whether or not an email domain supports relaxed or strict enforcement of DKIM
- Options for generation of delivery failure reports
- Requested mail receiver policy – messages that fail DMARC can be ignored, quarantined as potential spam, or rejected. We recommend rejecting them.
- Percentage of messages that are inspected for DMARC policy using random sampling (0-100)
- Format for message-specific failure reports
- Interval between aggregate reports in seconds
- Address to which aggregate feedback is to be sent to
- Address to which message-specific failure information is to be sent to
- Requested Mail Receiver policy for all subdomains
- Version of DMARC used
This is designed to automate several formerly manual processes and provide a good feedback loop for mail systems to know where to send error reports and provide better security. For bulk mailing services, this, again, may be challenging for smaller providers to implement and maintain. However, there are numerous providers of DMARC services that can assist, such as Valimail, Proofpoint, ReturnPath, Menlo Security, Microsoft, and Amazon.
Having DMARC and its supporting technologies of SPF, DKIM, and good DNS in place increases email security. It makes it significantly more difficult for forged and spoofed emails to reach team members’ inboxes and reduces that risk. However, it requires a strict stance from CIOs to be effective.
Allowing exceptions to DMARC puts all of your team members and customers at risk. When you allow all emails from a domain, you’re allowing anyone that can send an email using that domain name to target them. This is something we want to reduce. Using these technologies without exceptions protects those who we are charged to do so.
The next time someone comes over and immediately asks for all emails from a domain to be allowed, you’ll have a good explanation as to why this increases risk. You’ll also have a good way for both to de-risk your environments using DMARC instead. We’re all in this together, and whatever we can do to improve security for everyone is a step ahead for all of us.
