email AUTHENTICATION guidelines

!! ATTENTION !! This document has been automatically translated from Italian

Guidelines

Configuration of email service for authentication

The Italian National Cybersecurity Agency has published the Guidelines for configuring the email service for authentication, with the objective of strengthening the reliability of the email service for all interested organizations and increasing its overall level of security.

Version Control

INDEX

1. Introduction

1.1. Premise

Email represents today one of the most critical services in the digital context as it is among the main channels used by organizations and users for communications and information exchange¹.

The functioning of the email service and in particular the transmission of messages is based on the SMTP protocol which, however, does not natively incorporate adequate mechanisms for sender authentication and protection of the confidentiality and integrity of messages. These vulnerabilities expose it to the risk of attacks such as spoofing, phishing, tampering and message interception during transit.

To mitigate the weaknesses of the SMTP protocol and therefore reduce the risk due to the aforementioned attacks, mechanisms for sender authentication and protection of message integrity have been developed over time, such as SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting and Conformance).

These guidelines illustrate these mechanisms with the objective of strengthening the reliability of the email service and increasing its overall level of security, with particular reference to the threats described in Chapter 4.

The countermeasures and protocols necessary to protect the confidentiality of email messages (such as S/MIME and OpenPGP which concern message encryption) are not the subject of these guidelines.

1.2. Reference Regulations

1.3. Reference Documents

» back to top

2. Regulatory Context

To protect the digital assets of the country, including email services and the infrastructures hosting them, a broad body of security measures derived from current legislation is in place and subject to constant updating.

The highest level of protection for the country’s most critical services, connected to the protection of national security, is ensured by the National Cyber Security Perimeter, established by Decree-Law 21 September 2019, no. 105, converted with amendments by Law 18 November 2019, no. 133. This provides security measures with particularly high levels of protection, detailed in Annex B of the Prime Minister Decree 14 April 2021, no. 81, which apply to the networks, information systems, and IT services of public and private entities upon which the exercise of an essential function of the State or the provision of an essential service for the maintenance of civil, social or economic activities fundamental to the State’s interests depends, the compromise of which could result in prejudice to national security.

Furthermore, email services, like all digital services of public administration, are subject to the provisions of the so-called Cloud Regulation, adopted pursuant to Article 33-septies of Decree-Law 18 October 2012, no. 179 and updated by the National Cybersecurity Agency (ACN) with Directorial Decree no. 21007 of 27 June 2024. Under the aforementioned Regulation, all public administrations are called upon to classify their digital data and services as ordinary, critical or strategic, according to the model prepared by ACN. This activity is aimed at ensuring that public administration digital data and services are processed and delivered through digital infrastructures and cloud services that meet requirements, including security ones, appropriate to the risks associated with the relative classification level, as detailed by the Regulation.

Legislative Decree 4 September 2024, no. 138 (the so-called NIS decree) transposing Directive (EU) 2022/2555 also established – through Annexes 1 and 2 of ACN determination 379907/2025 – the basic security measures that essential and important entities adopt for the purposes of the obligations under Articles 23 and 24 of the NIS decree, defining a security framework to strengthen the protection of network and information systems, including email services.

» back to top

3. Email Service Architecture

As noted in the premise, the functioning of the email service is based on the SMTP protocol which regulates the transmission of email messages from the sender to the recipient.

The SMTP protocol was originally defined in 1982² as a store-and-forward protocol, in which the sender generates a message through their mail client, in jargon Mail User Agent (MUA), which sends it to the sender’s mail server. This, through a component called Mail Transfer Agent (MTA), forwards the message, possibly also through one or more intermediate MTAs, delivering it to the destination mail server’s MTA. The recipient user accesses the message through their mail client (MUA)[1].

The MTA is therefore a component of the email service that handles the transmission of email messages from the sender to the recipient. MTA components are present on the sender’s and recipient’s mail servers, and intermediate MTAs can also be configured, for example, to manage distribution lists.

Although the term MTA identifies a specific component of email servers³, since for the purposes of this document reference is made to the latter mainly in their function as MTAs, where there is no ambiguity, for simplicity of exposition the term email server will often be used instead of the more specific MTA.

In this guideline we focus on the configuration of the SPF, DKIM and DMARC protocols to allow mail servers to verify the authenticity and integrity of email messages.

» back to top

4. Threats

The SMTP protocol introduced in the previous chapter was initially designed to operate in a relatively small academic network and did not take into account aspects relating to the security of transmitted messages or sender authentication [1].

The growing spread of email and the intrinsic weaknesses of the SMTP protocol have favored, over time, the emergence of attacks whose main types are briefly illustrated in the following paragraphs.

4.1. Sender Spoofing

Spoofing is a cyber attack technique used to forge the sender’s address of a message and make the latter appear to come from a reliable address (such as, for example, that of a colleague, an acquaintance, or one’s own banking institution), inducing the recipient to perform potentially dangerous actions, such as, for example, opening an email attachment or clicking on links contained in the message.

This type of attack is relatively simple to carry out, as the SMTP protocol does not include sender authentication mechanisms and, therefore, through the email client it is possible to configure any sender address when originating the message.

Sender email address: envelope-from and message-from

The email message format provides for two distinct fields to indicate the sender’s email address. These fields are named envelope-from and message-from: the first (also referred to as return-path because it specifies the email address to which any error messages generated when an email does not reach the recipient must be sent) is the address used to correctly route the message, the second is the address displayed by the recipient in the received message header.

Drawing an analogy with sending a letter within an envelope via traditional mail, the envelope-from represents the sender’s address shown on the letter’s envelope, while the message-from corresponds to the heading present in the letter that indicates who wrote to the letter’s recipient.

It is important to note that the two addresses may not coincide. This distinction allows managing situations such as, for example, forwarding messages from third-party services, distribution via mailing lists, or automatic email replies.

It is indeed possible to indicate any sender both at the message-from level (sender’s email address displayed by the recipient in the received message header) and envelope-from level (sender’s email address used for message transmission).

To counter these threats, it is therefore essential to provide mechanisms that allow reliably authenticating the sender and verifying that the person who sent the message is actually authorized to do so.

4.2. Phishing

Phishing is a cyber attack technique aimed at the fraudulent acquisition of information (such as, for example, login credentials, credit card numbers, or other sensitive data), generally by sending deceptive messages that simulate origin from reliable senders³.

Spoofing, examined in the previous paragraph, is among the main techniques adopted by an attacker to forge the sender’s identity and make the message appear to come from a legitimate user or domain.

Alternatively, a sender address/domain similar to one recognizable by the recipient can be used, altering, for example, the so-called display name⁴ in order to strengthen the apparent authenticity of the message.

To send phishing messages, legitimate accounts previously compromised by the attacker can also be used.

A phishing message typically has content constructed to generate urgency, alarm, or economic interest in the recipient, creating situations that induce them to react impulsively and perform specific actions such as opening malicious attachments or clicking on links that redirect to apparently legitimate websites, but which in reality have been created by the attacker with the goal of stealing information and/or installing malware.

Usually, phishing attacks are conducted by transmitting the same email message to a large number of victims, without adapting the text to the specific profile of the victims.

A variant of phishing is so-called spear phishing, in which the attacker knows and specifically targets the victim’s profile.

Unlike a generic phishing email, a spear phishing message uses more precise contextual information to convince the user that they are interacting with a reliable sender [2].

4.3. Message Tampering

The content of an email message, like any other communication traveling over the Internet network that does not make use of end-to-end encryption (E2EE) techniques, can be intercepted and modified during transit between sender and recipient (a type of threat commonly called man-in-the-middle).

Consequently, in addition to the loss of confidentiality, the received message might not correspond to the one originally composed by the sender.

An attacker could, for example, manipulate the message content to make it appear to come from a reliable sender, modify the text or any links and/or attachments present in the message or insert malicious code.

The recipient, trusting the apparent authenticity of the message, can thus be induced to perform potentially harmful actions, such as communicating login credentials, authorizing payments, or opening malicious files.

To counter these threats it is therefore essential to adopt mechanisms that guarantee the integrity and authenticity of the message, ensuring that the received content has not been modified and that the sender is really who they claim to be.

» back to top

5. Countermeasures

Chapter 2 recalled the regulations that provide for security measures also for the protection of email services. This document is intended primarily to provide a guide to the implementation of the security measures, provided for by these regulations and reported in Appendix A, which are also relevant for the configuration of email services, in order to mitigate the risks associated with the threats discussed in Chapter 4. It should be noted nonetheless that the indications contained in these guidelines are also recommended to those subjects who are not subject to the aforementioned regulations.

The security measures in question do not explicitly refer to the configuration of the email service but – depending on the regulation considered – to the configuration of IT systems and industrial control systems (PSNC and Cloud Regulation) or information and network systems (NIS2). The email services, subject of these guidelines, fall into both types of systems.

In particular, the SPF, DKIM, DMARC protocols are illustrated below, which provide security mechanisms designed with the aim of strengthening the overall security of the email service and in particular of sender authentication and message integrity control.

5.1. SPF

SPF – Sender Policy Framework is an authentication protocol, formalized by RFC 7208, that allows a domain owner to specify which IP addresses are authorized to send email messages on its behalf and to establish the policies that the recipient must apply if the IP address associated with the domain⁵ of the sender’s email address is not among those explicitly authorized.

The authorized IP addresses are listed in a DNS TXT record relating to the sender domain called SPF record and illustrated in the subsequent section of this paragraph.

In this way, the recipient’s email server⁶ when receiving a message from a given domain can query the related SPF record and authenticate its origin by verifying that the IP address from which the message was received falls among those authorized to send messages on behalf of the domain.

It is important to observe that the domain being verified at the SPF level is the one relating to the envelope-from, consequently the adoption of the SPF protocol alone is not sufficient to counter spoofing as this type of attack could be carried out at the message-from level⁷.

In the event that an organization outsources, in whole or in part, its email service to a third party, such as, for example, a cloud provider, it must ensure that the messages sent by such providers pass SPF checks. To this end, the organization should include in its SPF record the IP addresses from which the providers send emails on behalf of the organization’s domain.

In the case of automatic email forwarding, since messages are typically redirected by an intermediate server, the IP address making the final delivery no longer coincides with the one originally authorized by the sender domain. In these cases, in order not to cause the SPF verification to fail, it is necessary to authorize also any intermediate forwarding servers, or resort to mechanisms such as SRS (Sender Rewriting Scheme) or ARC (Authenticated Received Chain) which can be more effective, especially in the presence of numerous intermediate forwarding servers.

It should be highlighted that for SPF to be truly effective, it must be correctly configured not only by the sender, but also by the recipient. In particular:

• the sender must publish the SPF record in the relative DNS server declaring the addresses that are authorized to send emails on its behalf;
• the recipient must configure its own mail server so that it executes SPF verification on received messages and coherently applies the resulting policies.

5.1.1. SPF Record

An SPF Record is a DNS record of TXT type whose name corresponds to the sender domain and whose content is constituted⁸ by the section indicating the version⁹ and a series of directives that indicate the behavior of the recipient’s mail server when there is a match between the IP address of the sender domain and a directive.

The directives are formed by a mechanism preceded by a qualifier. The main mechanisms used in SPF records are [2]:

• ip4, lists authorized IPv4 addresses;
• ip6, lists authorized IPv6 addresses;
• a, authorizes IP addresses present in the domain’s A record;
• mx, authorizes IP addresses relating to the domain’s MX records;
• include, authorizes IPs present in the SPF record of another domain;
• all, represents all IP addresses that have not been explicitly authorized through the other mechanisms.

In particular, the all mechanism allows establishing policies for messages coming from IP addresses that have not been declared by previous mechanisms.

Furthermore, SPF provides the following qualifiers to associate with mechanisms:

• + (pass) indicates that IP addresses matching the associated mechanism are authorized. It is the default qualifier if another is not specified;
• - (fail) indicates that IP addresses matching the associated mechanism are not authorized;
• ~ (softfail) indicates that IP addresses matching the associated mechanism are probably not authorized. This is a more uncertain declaration than the previous one. In these cases the message should be accepted but marked for more in-depth analysis, it is used for example in debugging cases or when it is foreseen that SPF verification might not be successful;
• ? (neutral) indicates that no indication is given for IP addresses matching the associated mechanism. The default behavior is to accept the message.

It is good to highlight that in practice, the SPF record is composed to specify authorized IP addresses, then resorting to the directive -all to specify that all other addresses are not authorized (in this regard, please refer to the examples below). This represents the recommended configuration as it allows explicitly indicating authorized IP addresses and excluding all others.

In any case, it is recommended to never use the directive +all (or the equivalent all) as it would correspond to the authorization of all IP addresses.

Examples of SPF records

Authorize a specific IP address

v=spf1 ip4:203.0.113.0 -all

The SPF record shown above uses SPF version 1 and authorizes through the ip4 mechanism the IP address 203.0.113.0 (in fact, as no qualifier is specified for the ip4 mechanism, the default + is implicitly used). The -all directive formed by the all mechanism and the - (fail) qualifier specifies that all other addresses are not authorized.

Authorize a specific IP address space

v=spf1 ip4:203.0.113.0/24 -all

The SPF record shown above is analogous to the previous one, but authorizes all IP addresses of the 203.0.113.0/24 address space.

Authorize multiple IP addresses

v=spf1 ip4:203.0.113.22 ip4:203.0.113.44 -all

The SPF record shown above authorizes exclusively the IPv4 addresses 203.0.113.22 and 203.0.113.44.

Authorize MX record addresses and a specific domain

v=spf1 mx include:spf.emailprovider.it -all

The SPF record shown above authorizes exclusively the IP addresses of the MX records of the same domain as the SPF record and those authorized of the domain spf.emailprovider.it (for example, the domain of an email service provider).

5.1.2. Authentication Process

If correctly configured to perform SPF verification, the recipient’s mail server upon receiving a new email message retrieves the sender domain’s SPF record by querying the DNS server that contains the records of such domain as it results from the address reported in the envelope-from field. For example, if the address reported in the envelope-from field is alice@example.com, the recipient’s mail server retrieves the SPF record of the domain example.com.

The recipient’s mail server then performs the SPF verification, analyzing the SPF record to determine if the IP address from which it received the message is authorized to send emails for the example.com domain. In case the email message passes the SPF verification it is delivered to the recipient.

For example, if the SPF record of the example.com domain were v=spf1 ip4:203.0.113.22 -all the verification would pass only if the sender server’s IP address were 203.0.113.22, while it would fail for any other address.

» back to top

5.2. DKIM

DKIM – DomainKeys Identified Mail is an authentication protocol, formalized by RFC 6376, that allows a domain owner to guarantee the authenticity of email messages sent by affixing a digital signature (DKIM signature) generated by the mail server via public cryptography algorithms and inserted in the headers of the message to be transmitted.

To allow the recipient to verify that the message has not been modified during transmission, the public key associated with the DKIM signature is preserved in a TXT record of the sender domain’s public DNS, called DKIM record, which is queried by the recipient mail server upon message reception.

The DKIM signature and record are illustrated in the subsequent sections of this paragraph.

As with SPF, DKIM must also be correctly configured by the sender and recipient and in particular:

• the sender must configure its mail server to generate DKIM signatures and publish the DKIM record in the relative DNS server;
• the recipient must configure its mail server so that it performs DKIM verification on received messages.

5.2.1. DKIM Signature

The DKIM signature is generated starting from designated elements of the message body and headers and consists of a series of key-value pairs that specify elements among which:

• v: protocol version¹⁰;
• a: encryption algorithm used¹¹;
• d: signing domain declaring message authenticity¹²;
• s: selector indicating which DKIM public key to look for in the DNS record¹³;
• h: list of email headers included in the signature¹⁴;
• bh: hash of the message body encoded in base64 format¹⁵;
• b: actual digital signature generated with the private key and encoded in base64 format¹⁶;
• x: signature validity date;
• c: type of canonicalization.

Canonicalization is the process of normalizing message elements before being digitally signed in order to reduce the impact of small modifications that can occur during transit, such as repeated spaces or line breaks. There are two types of canonicalization: simple, which requires an exact match between the original message and the received one, and relaxed, which applies normalizations like space removal, conversion of uppercase letters to lowercase in headers, and reduction of consecutive empty lines in the message body.

5.2.2. DKIM Record

The DKIM record is preserved in a TXT type DNS record whose name has the structure selector._domainkey.domain, where _domainkey is a label used to indicate that the DNS record is indeed a DKIM record. The content of the DKIM record consists of a series of key-value pairs specifying elements among which:

• v: protocol version;
• k: key type, which by default is RSA;
• p: public key encoded in base64 format.

Example of DKIM record

Name: s1._domainkey.example.com
Value: v=DKIM1; k=rsa; p=Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h...

The example DKIM record is associated with the selector s1 of the example.com domain, uses version 1 and contains the RSA public key encoded in base64 format (Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h...).

5.2.3. Authentication Process

If the DKIM protocol is correctly configured on both the sender’s and recipient’s mail servers, the functioning of the DKIM authentication and verification process provides that the sender mail server creates the DKIM signature of the message as described in paragraph 5.2.1, which is added to the message itself. In particular, the DKIM signature contains in the d field the signing domain¹⁷ and in the b field the digital signature of the message generated with the private key of the signing domain.

Upon receiving a message, the recipient mail server retrieves the DKIM record of the signing domain (d field of the DKIM signature) from the DNS server containing the records of that domain. Then it uses the public key contained in the DKIM record to verify the digital signature (b field) contained in the DKIM signature. If the verification is successful, the message is delivered to the recipient.

5.2.4. Cryptographic Aspects

On the cryptographic front, DKIM has historically used the RSA algorithm, particularly in the rsa-sha256 variant, considered the standard since 2007. The new alternative, introduced by RFC 8463, is Ed25519-SHA256, a modern form of digital signature based on elliptic curves that guarantees greater efficiency and much more compact keys.

On a technical level, RSA, with a key length of 2048 bits, remains the universal standard, but the keys are long and signatures relatively large, while Ed25519 offers keys nine times shorter and signatures four times smaller, with signing performance up to thirty times superior compared to RSA 2048. Despite these advantages, real-world support is limited: in 2026 Ed25519 is verified only by a few providers, while some major operators do not reliably support either signing or verification, making it unsuitable as the sole solution in production.

For this reason, despite being technically superior, at the time of writing this document, the use of Ed25519 is not recommended except in combination with RSA, via dual signature, from an experimental perspective and as a future compatibility measure. Until major providers fully implement its verification, RSA remains essential to guarantee maximum message delivery assurance.

Regarding long-term security, it is important to remember that neither RSA nor Ed25519 are resistant to attacks by future quantum computers [3], and the transition towards post-quantum algorithms will require new DKIM standards that do not currently exist, making it essential to monitor next-generation cryptography developments and future ACN recommendations in this area.

Regarding cryptographic key management aspects, the DKIM private key must be protected with rigorous security measures, keeping it on isolated systems accessible only to authorized services, adopting restrictive permissions, periodic rotation, and constant monitoring to prevent unauthorized access or compromises.

» back to top

5.3. DMARC

DMARC – Domain-based Message Authentication, Reporting and Conformance is an authentication protocol, formalized by RFC 7489, that integrates¹⁸ the SPF and DKIM mechanisms allowing a domain owner to specify, to recipients of messages transmitted from that domain, the policies for managing those messages that fail SPF and DKIM verifications.

In particular, DMARC introduces an authentication mechanism – called alignment – that verifies the correspondence between the domains authenticated by SPF and DKIM and the domain relating to the message-from field of the received message. Note that the alignment check between the message-from field and the SPF/DKIM domain fails in any case if the corresponding SPF/DKIM verification fails (see Figure 4).

Alignment can be verified in strict mode, where an exact match is required between the domains authenticated by SPF/DKIM and the one relating to the message-from field, or relaxed, where it is sufficient that the primary domains match, even if subdomains might be different.

For example, in relaxed mode for domains sub1.example.com and sub2.example.com an alignment would be found for DMARC verification purposes (since the primary domain, example.com, is the same). In strict mode, however, the DMARC alignment check would fail due to the lack of an exact match between domains.

Through alignment verification, even if an attacker managed to pass SPF and/or DKIM checks using a message-from different from the envelope-from authenticated by SPF and/or from the authenticated signing domain, DMARC would still detect the discrepancy, ensuring coherent and reliable verification of the sender’s identity [2].

The policies for managing messages that fail¹⁹ DMARC verification are specified in a TXT record of the sender domain’s relative DNS server called DMARC record and illustrated in the subsequent section of this paragraph.

DMARC also allows indicating to recipients to send reports, to the sender domain owners, regarding messages claiming to originate from that domain. In this way, the domain owner can verify if their domain is being used in an unauthorized manner and to what extent, analyzing, for example, how many messages are actually traceable to them out of the total messages claiming its origin.

As with SPF and DKIM, DMARC must also be correctly configured by the sender and recipient and in particular:

• the sender must publish the DMARC record in their DNS specifying the policies with which to manage messages failing DMARC verification;
• the recipient must configure their mail server to execute DMARC verification on received messages.

5.3.1. DMARC Record

The DMARC record name has the structure _dmarc.domain, where _dmarc is a label used to indicate that the DNS Record is a DMARC record and domain is the domain to which the policy refers.

The DMARC record consists of a series of key-value pairs specifying elements among which:

• v: DMARC protocol version²⁰;
• p: policy to apply to messages failing DMARC verification, can assume one of the values none, quarantine, reject;
• aspf: alignment mode to apply to SPF check (can be relaxed, default value, or strict);
• adkim: alignment mode to apply to DKIM check (can be relaxed, default value, or strict);
• rua: email addresses to which to send aggregate reports with statistical and summary information on messages received from the sender domain;
• ruf: email addresses to which to send detailed reports on individual messages received from the sender domain that failed DMARC verification.

Example of DMARC record

Name:
_dmarc.example.com
Value:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; adkim=s; aspf=s

The example DMARC record is associated with the example.com domain, uses version 1 and specifies the reject policy for messages failing DMARC verification, requesting strict mode (s) for verification of alignment of SPF and DKIM domains and to transmit aggregate reports to the email address dmarc-reports@example.com and failure reports to the address dmarc-fail@example.com.

5.3.2. DMARC Policies

As described in the previous paragraph, the DMARC record indicates the policy that the recipient mail server should apply for messages that do not pass DMARC verification. The possible policies are the following:

• none: the sender domain gives no indications regarding the delivery of messages failing DMARC verification;
• quarantine: the sender domain indicates that messages failing DMARC verification should be considered suspicious (e.g., subjected to further scrutiny, treated as spam or labeled as suspicious);
• reject: the sender domain indicates that messages failing DMARC verification should be rejected.

5.3.3. Policy Verification and Application Process

If the DMARC protocol is correctly configured on both the sender’s and recipient’s mail servers, upon message reception the recipient mail server retrieves the SPF and DKIM records to perform the related verifications, as well as the DMARC one (detailed in the incipit of paragraph 5.2.4). In the event the message does not pass DMARC verification, the policy indicated in the DMARC record (none, quarantine or reject) is applied.

Note that each mail server can adopt local heuristics and policies to determine the delivery or not of a message, also taking into account the outcome of SPF, DKIM and DMARC verifications. Therefore, generally, there is an additional decision-making process (“Standard filter” in Figure 5) downstream of the aforementioned verifications, which may also include further checks (like, for example, anti-spam and anti-malware filters).

Furthermore, the recipient mail server can transmit:

• to the addresses indicated in the rua field of the DMARC record, aggregate reports with statistical and summary information on messages received from the sender domain;
• to the addresses indicated in the ruf field of the DMARC record, detailed reports on individual messages received from the sender domain that failed DMARC verification.

» back to top

6. Conclusions

As discussed in the previous chapter, in order to best counter threats linked to sender domain impersonation it is necessary that all three examined protocols are implemented jointly and, in particular, that [3]:

• the sender domain correctly publishes SPF, DKIM and DMARC records in DNS;
• the sender’s mail server is configured to sign messages with DKIM;
• the recipient’s mail server is configured to perform SPF and DKIM verifications and apply DMARC policies.

With reference to protocol implementation, the following recommendations are also formulated [2]:

• configure SPF specifying which IP addresses are authorized to send emails on behalf of the domain; for domains not used for email transmission, for example those intended exclusively for websites, an SPF record should still be created to explicitly indicate that there are no valid email senders for that domain;
• use state-of-the-art encryption protocols and algorithms considered secure for DKIM keys, at the date of writing this document 2048-bit RSA is recommended;
• adequately protect the DKIM private key stored on the mail server, adopting restrictive access permissions, and ensure that only the mail server software has read privileges to the key;
• configure each mail server with a unique key pair and selector, in order to reduce the impact of a potential private key compromise;
• protect the private key from both accidental disclosure and attempts at access or modification by an attacker;
• provide that software relating to any mailing lists verifies DKIM signatures on incoming messages and affixes new DKIM signatures on outgoing ones;
• use unique DKIM key pairs for each third party sending emails on behalf of the organization;
• periodically rotate DKIM key pairs (at least every six months) to mitigate the impact of a potential compromise;
• immediately revoke keys in case of suspected compromise;
• monitor DMARC reports to identify any configuration errors or abuse attempts.

For further details, refer to the resources listed in Reference Documents.

It is observed that, to adequately protect email security, in addition to the authentication protocols examined here, there are further protocols – not the subject of these guidelines – such as, for example, TLS – Transport Layer Security which guarantees transmission channel encryption and SMIME and OpenPGP which concern end-to-end encryption and message authentication.

It is also noted that – while not an email security protocol in the strict sense – for the purposes of email service security it is recommended to implement DNSSEC (Domain Name System Security Extensions), a DNS protocol extension that adds cryptographic signatures to DNS records in order to guarantee the integrity and authenticity of DNS queries. Thanks to DNSSEC, for example, information relating to SPF, DKIM and DMARC records is protected during transmission, reducing the risk of alteration and therefore increasing email service security.

» back to top

Appendix A: Security Measures

National Cyber Security Perimeter (PSNC)

PR.IP-1: Reference practices (so-called baselines) are defined and managed for the configuration of IT systems and industrial control systems that incorporate security principles (e.g., principle of least functionality).

1. There is a detailed updated document indicating, also in relation to category ID.AM, at least:
   • a) the security policies adopted for developing configurations of IT and industrial control systems and the deployment of only the adopted configurations;
   • b) the list of IT and industrial control system configurations employed and the reference to relative reference practices;
   • c) the processes, methodologies and technologies employed that contribute to compliance with security policies.

Cloud Regulation – Digital Infrastructures and Services for Public Administration

PR.IP-01: Reference practices (so-called baselines) are defined and managed for the configuration of IT systems and industrial control systems that incorporate security principles (e.g., principle of least functionality).

1. Policies and procedures are defined with reference to application security to provide adequate support for planning, realizing and maintaining application security features, which must be reviewed and updated at least annually.
2. There is a detailed updated document indicating, also in relation to category ID.AM, at least:
   • a) the security policies adopted for developing configurations of IT and industrial control systems and the deployment of only the adopted configurations;
   • b) the list of IT and industrial control system configurations employed and the reference to relative reference practices;
   • c) the processes, methodologies and technologies employed that contribute to compliance with security policies.
3. Basic requirements for the security of various applications are defined and documented.
4. Metrics, of a technical nature, useful for monitoring the level of adherence to defined security requirements and compliance obligations are defined and implemented.
5. There is a process for application vulnerability mitigation and recovery for application security, automating remediation when possible.
6. There is a process for validating device compatibility with operating systems and applications.
7. There is a variation management system in terms of operating system, patching and/or applications.

Cloud Regulation – Cloud Services for Public Administration

PR.IP-01: Reference practices (so-called baselines) are defined and managed for the configuration of IT systems and industrial control systems that incorporate security principles (e.g., principle of least functionality).

1. Policies and procedures are defined with reference to application security to provide adequate support for planning, realizing and maintaining application security features, which must be reviewed and updated at least annually [IaaS, SaaS].
2. There is a detailed updated document indicating, also in relation to category ID.AM, at least:
   • a) the security policies adopted for developing configurations of IT and industrial control systems and the deployment of only the adopted configurations;
   • b) the list of IT and industrial control system configurations employed and the reference to relative reference practices;
   • c) the processes, methodologies and technologies employed that contribute to compliance with security policies [SaaS].
3. Basic requirements for the security of various applications are defined and documented.
4. Metrics, of a technical nature, useful for monitoring the level of adherence to defined security requirements and compliance obligations are defined and implemented. 5.There is a process for application vulnerability mitigation and recovery for application security, automating remediation when possible.
5. There is a process for validating device compatibility with operating systems and applications [PaaS, SaaS].
6. There is a variation management system in terms of operating system, patching and/or applications [PaaS, SaaS].

NIS 2

PR.PS-01: Configuration management practices are established and applied.

1. For at least relevant information and network systems, their secure baseline configurations (hardened) are defined and documented in an updated list.
2. In compliance with the policies referred to in measure GV.PO-01, procedures are adopted and documented in relation to point 1.

» back to top

Bibliography

[1] NIST, «Technical Note 1945».
[2] NIST, «NIST Special Publication 800-177 Revision 1»
[3] National Cybersecurity Agency, «Post-quantum and quantum cryptography - Preparation for the quantum threat».
[4] National Cybersecurity Agency, «Email authentication framework».

» back to top