Skip to content

Secure Email

SPF - Sender Policy Framework

It allows the domain of the envelope-From: address (the sending domain) to identify and assert the authorized mail senders.

The sending domain does this by placing a specially formatted TXT RR in the DNS database for the domain. The RR is composed of a space-separated sequence of name=value pairs, including the v=spf1 pair. For instance:

example.com IN TXT "v=spf1 ip4:192.0.0.1 include:third-example.net -all"

The set of allowed pairs along with their meaning is specified in the standard.

SPF and DKIM both have the problem of “identifier alignment”. It means that the sender email address that user sees can be different from the address that is actually used to perform authentication.

An attacker can set the “Return-Path” domain to her own domain and set her SPF record to pass the authentication. However, what the receiving user sees on the email interface is set by the “From” field. Since SPF does not require the two domains to be the same, then the spoofing email can pass the SPF check while displaying the impersonated address to users*

DKIM - DomainKeys Identified Mail

It allows the sending domain to claim some responsibility for a message by means of a signature inserted in the message headers.

A DKIM signature is generated using the message body and headers and included in a new DKIM-Signature header inserted in the message headers. To validate the signature, the public key is retrieved from a specially formatted TXT RR placed in the DNS by the sending domain.

In detail, the value of the DKIM-Signature header is composed of a set of name=value pairs. The set of allowed pairs along with their meaning is specified in the standard. Name bh identifies signature; name d identifies the sending domain while name s identifies the TXT RR in the sending domain (the standard specifies how to link the From: address to the d name of DKIM). For instance:

DKIM-Signature: ... d=example.gov; s=adkimkey; bh=base64 string; ...

The corresponding RR would be:

adkimkey._domainkey.example.gov. IN TXT "v=DKIM1; k=rsa; p=<base64 string public key>"

Note that there is no way to detect if DKIM is implemented by the sender without getting a mail from the sender, extracting the selector from the DKIM-Signature header and getting the DKIM policy from DNS based on this selector.

One can check if some commonly used selectors can be found in DNS. But a successful check does not mean that any of these selector actually gets used for signing nor does it mean that the messages gets signed at all. And, no typical selector found does not mean that DKIM is not implemented.

  • Unlike SPF, DKIM requires specialized functionality on the sender agent to generate the signatures.
  • Since DKIM requires the use cryptographic keys, enterprises must have a key management plan in place to generate, store and retire key pairs.
  • Administrative boundaries complicate this plan if one organization sends mail on another organization's behalf.
  • Softwares for managing mailing lists often alter a message body thereby invalidating any signature computed before.

DMARC - Domain-based Message Authentication, Reporting and Conformance

It allows the sending domain to specify whether SPF and DKIM checks should be performed (and possibly how to inform the sending domains of failed checks: this is important for figuring out whether the domain is being targeted, how and toward whom).

Without DMARC, an attacker stripping DKIM-Signature information and altering email content would be undetected because the receiver would not know whether the sending domain indeed uses DKIM.

A sending domain asserts its usage of DMARC with a TXT RR named _dmarc. The specific DMARC policy used is specified by means of a set of name=value pairs; the set of allowed pairs along with their meaning is specified in the standard. For instance:

_dmarc.example.gov 3600 IN TXT “v=DMARC1; p=reject; rua=reports@example.gov;“

This policy advises receivers to discard messages that failed SPF or DKIM checks and to inform the sending domain at reports@example.gov.

PEC

Il messaggio originale è inserito come allegato in una busta di trasporto. La busta di trasporto è firmata dal gestore mittente (integrità, autenticità).

Il colloquio tra i gestori deve avvenire con SMTP su TLS, come descritto nella RFC 3207. Il punto di ricezione deve prevedere ed annunciare STARTTLS ed accettare anche connessioni in chiaro (per la posta ordinaria).

MTA-STS

MTA-STS is an inbound mail protocol designed to add a layer of encryption/security between sending and receiving mail servers. It was designed to patch an existing hole in the STARTTLS protocol that allowed for communication to be unencrypted via an attacker who could remove parts of the SMTP session (such as the “250 STARTTLS” response). This is accomplished by bringing DNS as a third party to verify connections.

The MTA-STS protocol works by having a DNS record that tells mail servers to fetch a policy file via HTTPS from a defined subdomain. This file contains a list of the receiver’s mail servers which are authenticated and approved to receive the messages and also what policy to apply to inbound messages. The policy file for example.org is placed at:

https://mta-sts.example.org/.well-known/mta-sts.txt

A DNS TXT resource record is needed in order to enable MTA-STS on your domain. This record exists at a unique subdomain _mta-sts. For the example.org domain, it would be _mta-sts.example.org.

An example of such record is as below:

_mta-sts.example.org. IN TXT “v=STSv1; id=202104012135;”