Classification | Date | Document version |
---|---|---|
TLP: WHITE | 14/06/2019 | 1.0 |
Title |
---|
National Cybersecurity Centre Technical Recommendation: SPF, DKIM and DMARC |
Version History | |||
---|---|---|---|
Version | Date | Reviewer | Comments/ Notes |
1.0 | 14/06/2019 | CNCS | Initial version of the document |
2.0 | 11/10/2021 | CNCS | Updating the document |
The email service is still one of the most used Internet services in the context of personal, institutional and business use. However, it was designed to guarantee the delivery of messages (availability), but without security concerns regarding either the integrity of the content or the authenticity of the envelope (authenticity of the sender).
In fact, the email service is used abusively on a daily basis, either for sending mass unsolicited messages, commonly known as SPAM, or for sending messages with a forged sender. While the first technique is characterised by high intensity and low impact, the second is commonly used in identity theft, computer fraud and cyber-espionage schemes.
To address these and other problems, the industry, through the Internet Engineering Task Force (IETF), has been promoting the adoption of a number of tools to improve the security of the popular email service, including the Sender Policy Framework (SPF), DomaimKeys Identified Mail (DKIM) and Domain-based Message Authentication, Reporting and Conformance (DMARC)
Considering the distributed architecture of the Internet, the success of these initiatives does not depend only on the user, but also on the respective adoption rates and the example set by both the industry and the states. In this context, it is worth highlighting that among the most important Internet domains, the adoption rate of these techniques is higher than 70%, where giants Google, Microsoft or Yahoo are included. In Portugal, SPF in particular was operationalised at the end of the last decade both in the academic network and in the school network.
Thus, the National Cybersecurity Centre (CNCS) recommends the adoption of the SPF, DKIM and DMARC standards to all public and private organisations with an Internet presence.
The Sender Policy Framework (SPF) was first adopted by the IETF in April 2006 and today has an adoption rate of around 70% among the most visited domains.
SPF is a validation framework for the email delivery channel, based on the use of the Domain Name Service (DNS) for publishing the IP addresses of the servers authorised to send email for the respective domain. The following DNS record represents, as an example, the specific authorisation for the Mail Transfer Agent (MTA) with the address mail.example.com to send messages coming from the example.com domain:
example.com. TXT "v=spf1 a:mail.example.com -all"
Each SPF record consists of a "TXT" DNS record at the root of a domain or subdomain that starts with "v=spf1". From here parameters are used to describe the authorized (or not authorized) mail servers to send mail on behalf of that domain or subdomain. A domain or subdomain can have only one SPF record, but each subdomain can have its own SPF record
The destination server (also known as destination Mail Transfer Agent – MTA ) validates the origin of the received message, more precisely the respective “return-path” field, with the information published in the DNS and applies a message handling policy that results in the acceptance, rejection or quarantine of that message
Because the SPF checks the “return-path” field and not the “from” field, a malicious sender can still manipulate the message envelope and mislead the recipient of the message. Note that the average user looks at the “from” field and not the “return-path”. This flaw is closed with the use of DMARC, in addition to SPF.
An SPF record consists of the version number followed by a set of parameters, called (i) mechanisms and (ii) qualifiers. Validation processes ignore records that do not start with the version statement "v=spf1 ...".
SPF records may define zero or more mechanisms, which are used to describe the set of servers authorised to send e-mail on behalf of that domain. The most commonly used mechanisms in an SPF record are listed below:
all | ip4 | ip6 | a | mx | ptr | exists | include
All mechanisms, or each one individually, can be matched with one of four qualifiers. The qualifiers determine how the MTAs should handle the respective match.
Qualifier | Description |
---|---|
+ | Pass = The address has passed the test; Accept the message. Example: "v=spf1 +all" |
- | (Hard) Fail = The address has failed the test; Discard any message that does not comply with this validation. Example: "v=spf1 -all" |
~ | Soft Fail = = = The address has failed the test, but the result is not definitive; Accept and mark any message that does not conform. Example: "v=spf1 ~all" |
? | Neutral = The address neither passed nor failed the test; Leaves it up to the recipient to decide what to do with the message (probably to accept). Example: "v=spf1 ?all" |
If the SPF record does not contain a qualifier, the following is assumed: "+".
SPF - CNCS Recommendations
O DomainKeys Identified Mail (DKIM) was first promoted by Yahoo at the IETF in 2007 and now involves the major email service providers.
DKIM provides a method for validating a digital identity associated to a message (typically the sender's domain). The goal is the non-repudiation of the message attribution, achieved by affixing a cryptographic signature to each message sent. In other words, DKIM only attributes the responsibility of sending a message to a digital identity.
A DKIM signature by itself does not increase or decrease the reputation of a message. However the signature attached to the message is an important data for reputation assessment systems and for making a decision about a particular message.
Thus, from a practical perspective, it is as important to make the DKIM signature operational for outgoing messages as it is to adapt the mechanisms for receiving electronic mail by integrating DKIM validation to assess the reputation of incoming messages.
DKIM uses public key cryptography, which means that there is a private key that only the message subscriber knows, and a public key that everyone knows and can use to verify the message. The email subscriber (who may be different from the sender) creates the hash and the recipient of the message can verify this hash using the public key, which should be published in the DNS service of the respective domain (digital identity).
More detailed information on the implementation of this standard can be found on the dkim.org website, which may vary depending on the MTA and/or operating system used.
DKIM - CNCS Recommendations
O Domain-based Message Authentication, Reporting and Conformance (DMARC), adopted by the IETF in March 2015, complements SPF and DKIM by adding a control layer that enables cooperation and information sharing between senders and recipients to improve the validation of email message authenticity.
DMARC enables the sender to declare to the recipient the use of SPF and/or DKIM, as well as what the recipient must do with a message that fails the validation of any of the methods declared. On the other hand, it verifies the "alignment" between the address presented in the “from” field and the MTA verified through SPF.
This functionality allows the recipient of the message to apply the policy for handling received messages in accordance with the declaration made by the sender.
In general terms, the DMARC validation process works as follows:
A DMARC record should be defined at the level of the organisation's own DNS service. It is a particularly formatted version of a "TXT" DNS record, with a specific record name, namely "_dmarc.example.com" (note the "_" prefix):
_dmarc.example.com. IN TXT "v=DMARC1; p=none;
rua=mailto:dmarc-aggregate@example.com;
ruf=mailto:dmarc-afrf@example.com; pct=100"
Looking at this specific example, from left to right:
The above options represent the most commonly used set of parameters for defining the DMARC policy, but there are more configuration options available.
"Domain alignment" through DMARC is a concept that expands the domain evaluation intrinsically performed by SPF and DKIM. In this way, DMARC compares the “from” domain of a message with relevant information from these other standards:
The alignment can be “relaxed” (matching between base-domains but allowing different subdomains) or “strict” (exact match of the whole domain). This choice is defined at the DMARC policy level established for the originator domain of the message.
It should also be noted that alignment with DKIM is more important than with SPF because only DKIM remains aligned when the message is forwarded (e.g. through a rule defined in the user's mailbox).
At the DMARC specification level, three options are provided for the persons responsible for each domain to define the preferential treatment to give to an e-mail message that fails the DMARC validation checks. These policies (“p=”) are:
Note that the domain holder can only request, not force, the application of their DMARC registration. It is up to the destination MTA(s) to decide whether or not to comply with the requested policy.
DMARC reports are generated by the input MTA(s) as part of the DMARC validation process. There are two formats of DMARC reports:
DMARC - CNCS Recommendations
DKIM, SPF and DMARC are standards that address complementary issues associated with email security and authentication.
SPF allows senders to define which IP addresses are authorised to send email from a given domain.
DKIM provides a cipher key and a digital signature allowing to verify that an e-mail message has not been forged or altered.
DMARC unifies the SPF and DKIM authentication mechanisms in a common framework and allows the managers of each domain to define how an e-mail message from that domain should be handled if an authorisation test fails.
Finally, the following sequence of steps is suggested for the implementation of these three standards: