Email continues to be an excellent vector for cyber criminals to distribute malware, as well as links to unsuspecting victims. Email is a frequently misconfigured, and very misunderstood service that is being used to perform tasks that it was never designed to do. Not securely anyway. Thankfully, the Domain Name Service (DNS) has come up with several mechanisms for reducing the risk of receiving spam, and other potentially malicious messages.
What Is SPF?
The Sender Policy Framework (SPF) is an authentication method that is designed to detect when an email sender has sent an email from a server that isn’t approved to send email for the domain name of the sender email. The Sender Policy Framework provides the receiving email server a way of seeing what servers are approved to email. This occurs every time an email is received, if SPF is available. SPF is configured by adding a TXT record to your domain name’s DNS record with a string value consisting of various details, including approved sending servers.
The SPF Record
An SPF Record is a TXT DNS record that contains a list of IP addresses and domain names that are approved to send email using the domain name that the DNS record exists on. An SPF record may look something like this:
TYPE HOST VALUE TTL TXT @ "v=spf1 ip4:184.108.40.2062 include:domainname.com include:ses.amazon.com ~all" 1800
The SPF string always starts with the version of SPF, followed by various mechanisms including those that define approved IP addresses and domain names (which can be resolved back to an IP address), and finally the ALL mechanism is included with a qualifier in front of it to determine how the receiving email server should read the record.
The “all” mechanism needs a qualifier, however, qualifiers can be used in front of other mechanisms to setup any number of different configurations.
Four qualifiers exist: question mark (?), tilde (~), dash (-), and plus (+).
|+ (Pass)||Host or IP allowed to send||accept email|
|– (Fail)||Host or IP NOT allowed to send||reject email|
|~ (SoftFail)||Host or IP NOT allowed to send, but is in testing||accept email, but mark it|
|? (Neutral)||Nothing to be said about Host or IP||accept email|
What Is DKIM?
DomainKeys Identified Mail (DKIM), like SPF, is an authentication mechanism designed to detect when an email is being sent by a server approved by the domain owner. Unlike SPF, DKIM uses digital signatures that are setup by the mail server, referenced in your domain’s DNS record, and attached to every outbound message. DKIM adds to SPF by using cryptography to sign the message. This means that DKIM isn’t just verifying the sending server, but it also verifies the integrity of the message to ensure that contents of the email, including any possible attachments, hasn’t been altered in transit.
The DKIM Record
DNS TXT records are also used in the implementation of DKIM but look a little different. More specifically they use a different set of key/value pairs that supply a receiving server with information required to verify the authentication and integrity of inbound email. Here is what a DKIM record might look like:
TYPE HOST VALUE TTL TXT @ "DKIM-Signature: v=1; a=rsa-sha256; d=domainname.com; s=selector; c=relaxed/simple; q=dns/txt; t=1117574938;x=1118006938;h=from:to:subject:date:keywords:keywords;bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR 1800
There are a number of tags available,
|c||canonicalization algorithm(s)||q||query method|
|h||header fields||bh||body hash|
|b||signature of headers and body|
Since DKIM is a digital signature, it uses public-key encryption. When the receiving server looks up the DKIM DNS record for the domain name, it receives a response that contains the domain name’s public key and other key=value pairs that tell the server how to use it.
"k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEuyYiyMg4suA2Sy MwR5MGHpP9diNT1hRiwUd/mZp1ro7kIDTKS8ktkI6z6eTRW9e9dDOxzSxNuXmume60Cjbu08gOyhPG3 GfWdg7QkdN66R4V75MFlw624VY35DaXBvnlfJTgRg/EW72O1DiYVThkyCgpSYS8nmEQIDAQAB"
Another aspect of DKIM is that is provides non-repudiation. Non-reputability is a situation whereby the authorship of an assertion/statement made by an individual, cannot be disputed. In the case of DKIM, only the sending server should have the private key that was used to encrypt the email message. Thus, if the public key that we received is able to successfully decrypt the message, we can be certain where it came from.
What Is DMARC?
DMARC, or Domain-based Message Authentication Reporting and Conformance, is the third and final email authentication mechanism that we’ll be looking at today. DMARC was created to extend both SPF and DKIM protocols and provide incoming email authentication by providing instructions to a receiving email server on the policies surrounding both DKIM and SPF. The DMARC policy also informs the receiving server how it should handle emails that fail SPF checks, DKIM checks, or both.
The DMARC record is created with a subdomain label of _dmarc (i.e. _dmarc.roguesecurity.ca), and exists as a TXT record. Let’s take a look at what a DMARC record looks like:
TYPE HOST VALUE TTL TXT _dmarc.domainname.com. "v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:email@example.com;" 1800
The only required tags in your DMARC record are the ‘v’ and ‘p’ tags.
|pct||Percentage of messages subjected to filtering|
|p||Policy for domain|
|sp||Policy for subdomains of |
|rua||Reporting URI for aggregate reports|
|ruf||Reporting URI for forensics reports|
|adkim||Alignment mode for DKIM|
|aspf||Alignment mode for SPF|
|fo||Failure reporting options (will be ignored if ‘ruf’ is missing)|
|rf||Format to be used for message-specific failure reports|
|ri||Interval between aggregate reports|
DMARC also adds the capability of reporting in the form of aggregate reports and forensic reports. The reports are XML formatted files that are issued by the recipient servers, and can be quite large if your organization sends a lot of email.
SPF, DKIM, and DMARC are email authentication mechanisms that can help with anti-phishing, non-repudiation, spam prevention, and message integrity. Although the implementation can be very complex when more then one domains are involved, the benefits of SPF, DKIM, and DMARC far out weigh the amount of time that they may require to configure properly.