Ir para conteúdo


This document describes the importance of and recommends the use of the SPF, DKIM and DMARC standards for strengthening e-mail security in organisations
Classification Date Document version
TLP: WHITE 14/06/2019 1.0
National Cybersecurity Centre Technical Recommendation: SPF, DKIM and DMARC
Version History
Version Date Reviewer Comments/
1.0 14/06/2019 CNCS Initial version of the document
2.0 11/10/2021 CNCS Updating the document


AFRF: Authentication Failure Reporting Format
DKIM: DomainKeys Identified Mail
DMARC: Domain-based Message Authentication,Reporting and Conformance
DNS: Domain name system
IETF: Internet Engineering Task Force
MTA: Mail Transfer Agent
SPAM: Unsolicited email
SPF: Sender Policy Framework


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 WEBCHECK.PT platform

The correct implementation of the standards mentioned in this technical recommendation, as well as a set of other standards, configurations and good practices, can be assessed, in real time, through the WEBCHECK.PT platform.

Launched in 2019, this is a joint initiative of the National Cyber security Centre and the DNS.PT Association (.PT) with the aim of facilitating the identification of the necessary technical measures for greater resilience and security in online presence as well as promoting the adoption of good practices and standards that contribute to ensuring security, integrity and confidentiality in internet communications.

Its use is intended to be simple and practical, simply by inserting the domain to be evaluated in the box available for that purpose on the homepage, and evaluations may be made of any type of domain and subdomain, regardless of its top level domain.

Sender Policy Framework (SPF)

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 to send messages coming from the domain: TXT "v=spf1 -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.

Components of an SPF record

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

  1. All organisations with an Internet presence must adopt the SPF standard in the configuration of their email domain;
  2. When performing the initial settings of SPF, you can choose a neutral qualifier ("? all") in order to assess the application of the respective policy;
  3. Once you know exactly what IP addresses the mail servers are legitimately sending on behalf of your domain name, update the SPF record accordingly and assume a more restrictive qualifier ("-all");
  4. 4. If you are responsible for managing domains from which no e-mail is sent, it is recommended to configure the following SPF record (which explicitly indicates that no MTA is authorised to send e-mail on behalf of that domain) on each of them:
    v=spf1 -all

DomainKeys Identified Mail (DKIM)

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 Operationalisation

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 website, which may vary depending on the MTA and/or operating system used.

DKIM - CNCS Recommendations

  1. All organisations with an Internet presence must adopt the DKIM standard at the level of their email domain configuration;
  2. The security and confidentiality of the private key is essential. Therefore, it must be protected using standard methods (access limitations through the operating system, disk cipher, etc.);
  3. It is recommended to use a key with a minimum of 2048 bits. Note, however, that large keys (normally above 4096 bits) may potentially cause problems at DNS level.


Domain-based Message Authentication, Reporting and Conformance (DMARC)

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.

How DMARC works

In general terms, the DMARC validation process works as follows:

  1. A domain administrator publishes the policy that defines its email authentication practices and how the recipient of the message should handle messages that violate that policy. This DMARC policy is defined by a record in the DNS service of the sender's domain;
  2. When an MTA server receives an email message it uses DNS to look up the DMARC policy of the domain contained in the "From" (RFC 5322) header of the message. The MTA then checks the message by three main factors:
    • Is the DKIM signature of the message valid?
    • Did the message come from IP addresses allowed by the SPF records of the sending domain?
    • Do the message headers show proper "domain alignment"?
  3. Using this information, the MTA is ready to apply the DMARC policy of the sending domain and decide whether to accept, reject or otherwise flag the email message;
  4. After using the DMARC policy to determine the appropriate message disposition, the MTA can report the result to the sending domain manager.

Example of a DMARC record

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 "" (note the "_" prefix): IN TXT "v=DMARC1; p=none;;; pct=100"

Looking at this specific example, from left to right:

  • "v=DMARC1" defines the version of DMARC;
  • "p=none" specifies the preferential treatment, or DMARC policy to be applied;
  • "" defines the mailbox to which the aggregated reports should be sent;
  • "" defines the mailbox to which forensic reports should be sent;
  • "pct=100" represents the percentage of e-mail messages for which the domain holder wants to see its policy enforced.

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

"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:

  • In the case of SPF, the domain defined in the “from” of the message and the domain present in its “return-path” must match (the manipulation of the “return-path” is a technique widely used in phishing messages, in order to forge the sender that is presented by the e-mail client);
  • In the case of DKIM, the domain present in the "from" of the message and the domain defined in the "d= domain" field of the DKIM signature must match.

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).

DMARC policies

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:

  • none: treat the message in the same way as it would occur without any DMARC validation;
  • quarantine: accept the message, but put it somewhere other than the recipient's inbox (usually the spam folder);
  • reject: reject the message immediately.

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

DMARC reports are generated by the input MTA(s) as part of the DMARC validation process. There are two formats of DMARC reports:

  • Aggregate report consists of XML documents showing statistical data about incoming messages claiming to be from a specific domain. The information includes authentication results and message disposition. Aggregate reports are designed to be machine-readable;
  • Forensic report are individual copies of messages that failed authentication, each included in a complete message using a special format called AFRF. The forensic report can be useful for troubleshooting authentication problems for a domain and for identifying malicious domains and websites

DMARC - CNCS Recommendations

  1. All organisations with an Internet presence must adopt the DMARC standard when configuring their e-mail domain;
  2. As DMARC reports are difficult to read, tools (provided by third parties) can be used to aggregate these reports in order to obtain a more effective reading and analysis of the results. However, we draw attention to the fact that this operation implies sharing the information contained in these reports with the service provider, so it is up to each organisation to assess the advantages and disadvantages of this operation;
  3. There are several web tools available that can assist in the process of configuring a DMARC record. However, and as a safeguard measure, we suggest using non-real values to replace the most sensitive data (domain, email addresses, etc.);
  4. In an initial configuration phase of DMARC at the level of a domain, we suggest the adoption of a "p=none" policy. Following that, and after analysing the aggregated reports received in the meantime, as well as any adjustments made to the DKIM and SPF configuration, a progressive transition to a more restrictive policy should be made ("p=quarantine" and "p=reject").


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:

  1. Configure MTA(s) to ensure that they correctly validate DMARC records;
  2. Configure MTA(s) so that they are able to send aggregated DMARC reports;
  3. Inventory domains;
  4. Implement SPF;
  5. Implement DKIM;
  6. Configure mailbox(es) for receiving DMARC reports;
  7. Configure the DMARC DNS record(s);
  8. Analyse the DMARC reports received;
  9. Adjust SPF record(s), DKIM signature(s) and DMARC policy(ies) as necessary.
Last updated on 26-09-2022