In 2016 nearly 40 percent of enterprises were hit with ransomware, up 400% in just the past two years. The preferred attack vector? 59% of the time ransomware attacks originate in your employee’s inbox. Email gives attackers easy access to less security-aware employees who get tricked into thinking they are opening attachments or clicking links in spoofed emails. Fortunately, DNS offers solutions that can stop these kinds of attacks before they ever reach your employees inbox.
Using DNS to improve email security
DNS allows SPF, DKIM, and DMARC records to improve email security by (1) checking that the email is sent from an identity confirmed system and (2) validating the DMARC rules are met prior to allowing the email into the end user’s inbox. If DMARC rules are not met, you have the ability to (4) quarantine or (5) reject the email. DMARC also provides reporting for tracking messages are authenticating, what messages are not authenticating, and the reason why.
Diagram 1: DMARC workflow
The appendix of this article discusses the needed steps to configure your Managed DNS installation with SPF, DKIM, and DMARC records. Your Managed DNS provider may have additional instructions for you to follow when setting up these records. Please consult with your Managed DNS provider prior to configuring these records.
Standardization will help increase ability to prevent ransomware
Adding the SPF, DKIM, and DMARC capabilities leverages DNS to improve prevention of suspicious emails from flooding users’ inboxes. Unfortunately, no system is 100% perfect and malicious emails can get through. Higher adoption of SPF, DKIM, and DMARC coupled with high user awareness of email threats goes a long way to ensuring your network is as secure as possible. NS1 provides solutions that will enable you to meet the ever-changing demands that come with managing these threats.
Appendix: SPF, DKIM, and DMARC DNS Records
Sender Policy Framework
SPF (Sender Policy Framework) is a DNS text entry which gives you, the domain owner, the ability to display your domain’s legitimate mail servers allowed to send email. This helps control and stop attempted sender forgeries, ensuring the organization’s email is identified as coming from your organization.
Here is an example of an SPF DNS record. Table 1 explains the information for each piece of the record. Table 2 explains the specific meanings and usage of the ‘all’
SPF Example:
Mail1.com. IN TXT "v=spf1 ip4:198.51.100.0/24 include:mail.company.com include:_spf.google.com ~all"
Mechanism | Description |
all | Matches all local and remote IPs and goes at the end of the SPF record. Example: "v=spf1 +all" |
ip4 | Specifies a single IPv4 address or an acceptable IPv4 address range. A mask of /32 is assumed if no prefix-length is included. Example: "v=spf1 ip4:192.168.0.1/16 -all" |
ip6 | Same concept found in ip4, but, obviously, with IPv6 addresses, instead. If no prefix-length is given, /128 is assumed (singling out an individual host address). Example: "v=spf1 ip6:1080::8:800:200C:417A/96 -all" |
a | Specifies all IPs in the DNS A record. Example: "v=spf1 a:domain.com -all" |
mx | Specifies all A records for each host's MX record. Example: "v=spf1 mx mx:domain.com -all" |
ptr | Specifies all A records for each host's PTR record. Example: "v=spf1 ptr:domain.com -all" |
exists | Specifies one or more domains normally singled out as exceptions to the SPF definitions. An A query is performed on the provided domain; if a result is found a match occurs. Example: "v=spf1 exists:domain.com -all" |
include | Specifies other domains that are authorized domains. Example: "v=spf1 include:outlook.microsoft.com -all" |
Table 1: SPF DNS Record
Parameter | Result | Definition |
+all | pass | Permits all the email, as if SPF wasn’t configured. |
-all | fail | The source email server must match the SPF record exactly or the email will fail. |
~all | softfail | Permits the email to send, but will mark it as softfail if anything goes wrong. The host should accept the email, but mark it as an SPF failure. |
?all | neutral | No policy is set. |
Table 2: SPF entry feature all
DomainKeys Identified Mail
DKIM (DomainKeys Identified Mail) helps verify that the content of the email wasn’t changed after the message left your organization’s mail server. This is done by implementing a standard public/private key signing process.
1. Create a 1024-bit (or higher) public and private key pair using a DKIM wizard such as Port25 or openssl.
The DKIM wizard will provide a selector record. This record includes the DKIM subdomain that will store the public key. The public key is a combination of the domain and selector name.
2. Create a TXT record in your DNS with the public DKIM key.
The DKIM wizard will provide the private key. Store this according to the instructions in the DKIM package.
3. Your mail servers sign the outgoing email with the private key.
4. The receiving (target) mail servers use the public DKIM key to verify that the DKIM signature is correct. When email is received by the target’s email server, the server calls the sender’s DNS server for the public key and the digital signature is verified
DKIM Example:
google._domain.com IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAraC3pqvqTkAfXhUn7Kn3JUNMwDkZ65ftwXH58anno/bElnTDAd/idk8kWpslrQIMsvVKAe+mvmBEnpXzJL+0LgTNVTQctUujyilWvcONRd/z37I34y6WUIbFn4ytkzkdoVmeTt32f5LxegfYP4P/w7QGN1mOcnE2Qd5SKIZv3Ia1p9d6uCaVGI8brE/7zM5c"
Domain-based Message Authentication, Reporting, and Conformance
DMARC (Domain-based Message Authentication, Reporting, and Conformance) allows you, the domain owner, to determine what action the recipient’s email server should take an email fails an SPF check and/or a DKIM check. These actions can include rejecting the email, quarantining the email, or no action.
DMARC also provides reports on the actions taken by receiving email servers. The reports give you visibility into attempts by others to spoof your organization’s domain. Table 3 explains the specific pieces of a DMARC record in DNS and shows examples.
DMARC Example:
"v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]"
Tag Name | Purpose | Sample |
v | Protocol version | v=DMARC1 |
pct | Percentage of messages subjected to filtering | pct=20 |
ruf | Reporting URI for forensic reports | ruf=mailto:[email protected] |
rua | Reporting URI of aggregate reports | rua=mailto:[email protected] |
p | Policy for organizational domain | p=quarantine |
sp | Policy for subdomains of the OD | sp=reject |
adkim | Alignment mode for DKIM | adkim=s |
aspf | Alignment mode for SPF | aspf=r |
Table 3: DMARC Specification
Defeating ransomware requires enterprises to utilize technology to thwart attacks that target employee inboxes. Higher adoption of SPF, DKIM, and DMARC coupled with high user awareness of email threats goes a long way to ensuring your network is as secure as possible. That is why IT leaders and practitioners need to include intelligent DNS & traffic management in their security roadmap.
To learn more about how the NS1 platform can help your business use DNS to address these challenges, you can download this white paper or visit our platform page.