High email security standard through SPF, DKIM and DMARC

by | Nov 29, 2018 | Services

High email security standard through SPF, DKIM and DMARC

Hornetsecurity offers secure protection against spyware and malware in email authentication through standardized sender reputation procedures.

Emails are still regarded as the most commonly used medium for the transmission of electronic messages. They are inexpensive, with unlimited distribution and offer the possibility of sending and receiving texts and file attachments in real time. Yet precisely these characteristics make email communication so vulnerable. Cyber criminals are constantly expanding their range of threats and developing new strategies to overcome security mechanisms. The authorization of permitted domains using a corresponding SPF record in the DNS zone is therefore no longer sufficient to successfully protect incoming email traffic from phishing and spam.
For this reason, Hornetsecurity’s email service has been expanded including further important sender reputation procedures in the fight against widespread attack patterns. In addition to SPF, procedures such as DKIM and DMARC are implemented against spam, spoofing, phishing and malware attacks as well as targeted CEO fraud attacks. Hornetsecurity has thus been applying the current recommendation for email security from the Federal Office for Information Security (BSI) and the Federal Association for IT Security (TeleTrusT) and thus offers a high security standard in email communication.

Secure from attacks with SPF, DKIM and DMARC

The SPF, DKIM and DMARC authentification procedures operate interconnected as a secure instrument to prevent from attacks on a company’s email communication. In the following, the used standards for sender and recipient reputation are presented and their functionalities are explained.

Sender-Policy-Framework (SPF) [RFC 7208]

SPF is a method by which unauthorized sender addresses of domains can be recognized and the delivery of their mails can be prevented. Authorized servers that are allowed to send emails in the name of a domain are entered in the so-called SPF record of the DNS zone. When an email is dispatched, the receiving server takes the sender domain from the envelope sender of an email and uses a DNS query to check whether the domain is registered in the SPF record. If the domain is not registered, the server is not authorized to send emails in the name of the domain. Emails from unauthorized servers, for example, can be classified as spam. Due to insufficient cryptographic security mechanisms that could ensure the senders authenticity, SPF should not be used as spam or phishing prevention. Despite successful SPF authentication, the sender ID of the envelope sender can be changed in the Body-From field, making it easy to manipulate the sender address.
Sender Policy Framework (SPF)

Domain-Keys-Identified-Mail (DKIM) [RFC 6376]

For a more comprehensive email protection, SPF can be usefully supplemented with DKIM. The main intention is to prevent spoofers from accessing sensitive data. As a special feature for email authentification, DKIM adds a digital signature with cryptographic encryption (SHA-256) to the email header. This signature operates as a kind of fingerprint and must have the same hash value in the checksum as calculated before sending. Any change to the data, no matter how small, would change the hash value and indicate an intervention in the message during transport.
To decrypt the signature, a key pair is needed which consists of a public key and a private key and is required for successful authorization of the sending server. The public key is entered as a TXT record in the DNS zone analog to the SPF entry. The secret key remains exclusively on the server that is authorized to send emails.
In the authorization procedure, the receiving server first determines the sender domain of the email and then checks for the name under which the matching public key can be found in the DNS zone of the sender domain. A successful signature check ensures that the decoded hash value corresponds to the original checksum before sending and that the email has not been modified during transmission.
Domain Keys Identified Mail (DKIM)

Domain-based Message-Authentification, Reporting and Conformance (DMARC) [RFC 7489]

A constant verification of the authenticity of emails cannot be guaranteed by SPF and DKIM on its own. This gap is closed by the DMARC test procedure, which complements the SPF and DKIM methods in their combined appearance to form a safe test procedure for sender reputation. DMARC ensures that the envelope sender address matches the body form address. This verification is important because traditional email programs only display the body-from information of an email and the actual sender information remains hidden.
DMARC also establishes certain guidelines for the SPF and DKIM procedures, which are stored in the TXT record of a DNS zone in form of requirements. These guidelines determine the instructions for the further handling of received emails. Thus for SPF the verification must be positive and the envelope sender address of the domain must match the address stored in the SPF record. For DKIM it is required that the signature is valid and that the domain matches the body-from address of the mail.
Domain Based Authentification Reporting and Conformance (DMARC)
If one or more requirements are not met, the check is negative and the email can be quarantined or rejected depending on the matrix.

DMARC offers the option to send reports in the versions of “Aggregated Reports” and “Failure Reports” (The reports may only be transmitted in compliance with the Federal Data Protection Act in the context of the detection and limitation of spam and phishing as well as for the protection of telecommunications systems and in accordance with the principle of proportionality. An authentication and verification system must be used to avoid misuse. ) The reports can help the domain administrator to keep track of his own email traffic and to check the DNS entries for syntactical correctness. Furthermore, the results can be used to support other systems. For example, the ZIP file of an undisputedly identified sender can be delivered without further effort, while for unidentified senders it is quarantined or rejected. This way, Hornetsecurity supports its own product Content Filter for fast and secure delivery of attachments in emails.

*The reports may only be transmitted in compliance with the Federal Data Protection Act in the context of the detection and limitation of spam and phishing as well as for the protection of telecommunications systems and in compliance with the principle of proportionality. An authentication and verification system must be used to avoid misuse.

Further technologies and encryption methods at a glance

  The so-called Domain Name System (DNS) is responsible for the connection with servers and can be used to convert host names into IP addresses. Sending and receiving messages to one or more recipients is made possible with the User Datagram Protocol (UDP). A connection between sender and receiver is not established and the data is delivered to the receiver without further control mechanisms. Therefore, even the sender is unable to determine whether his message has arrived successfully. Various security techniques such as TLS, DNSSEC and DANE are used to solve the security problem of outdated DNS. In the area of “secure email communication”, however, no standard has yet been able to establish itself. The latest standard is called MTA-STS and promises to successfully protect e-mails during transmission from electronic eavesdropping and manipulation.

Transport Layer Security (TLS) [RFC 5246 ]

TLS is a popular encryption protocol that has been developed further and standardized on the basis of the Secure Sockets Layer (SSL). The TLS protocol is used to ensure confidentiality, authenticity and integrity when transmitting data in insecure networks. The TLS protocol, divided into two levels, is a hybrid encryption method that uses both symmetric and asymmetric algorithms. It encrypts an end-to-end connection using symmetric algorithms. The TLS Handshake Protocol is based on the TLS Record Protocol and negotiates security parameters between sender and receiver. Connections to email servers can be initiated and encrypted via STARTTLS. TLS is used nowadays in many applications in which data, in particular access data, PINs and passwords can be transferred securely. These include applications such as e-commerce, home banking and e-government.

DNSSEC (Domain Name System Security Extensions)

[RFC 4035 ]

DNSSEC is an extension of DNS. It verifies the authenticity of the information stored in the DNS zone and ensures that an attacker cannot manipulate the DNS responses in his favour. With two different keys and a corresponding signature, the DNS data is protected. The recipient can verify the sender on the basis of the signatures used. If the signature is not valid, the DNS server of the provider blocks the response. DNSSEC cannot be applied to every domain and is therefore not commonly used.

DNS-based Authentification of Named Entities (DANE) [RFC 6698]

The DANE protocol is another technique based on DNSSEC. This technique extends the basic protection of TLS connections by a cryptographic combination of certificates with DNS names. Thereby it should be verified whether an email server can establish and authenticate encrypted connections. This is to prevent a man-in-the-middle attack in which the message first reaches an attacker’s server. The DANE entry is stored in the DNS zone under a TLSA record which contains different characteristics of the respective TLS connection. These features define the certificate which a server must expect when connecting to the email service of the particular email server. For many domain administrators, however, DANE cannot be implemented since not every domain can be resolved via DNSSEC.

SMTP MTA Strict Transport Security (MTA-STS) [RFC 8461 ]

The connections between the servers so far are mostly unprotected. Thus, an important component for secure transport encryption is missing. This problem was apparently also recognized by large mailhosters such as Google, Microsoft and Verizon Media Company (Yahoo, AOL) as well as 1&1, which are participating in the development of the new MTA-STS standard. MTA-STS is intended to replace the often unrealisable DANE as well as the common STARTTLS, since attacks on the procedures cannot be excluded with absolute certainty. The new standard offers a similarly secure standard as DANE, but a much easier implementation than DNSSEC. For the implementation of the standard, email server operators can define a policy that can be retrieved by the sending mail transfer agent (MTA) using HTTPS [RFC2818]. The current version is displayed by a TXT data record in the Policy. In addition, these TXT data records contain an ID field which the sending MTA can use to check the temporarily stored policy for actuality without having to request an HTTPS connection. To find out if a receiver domain implements MTA-STS, the sender only needs to resolve a TXT dataset and identify the TXX record with the label “_mta-sts” (e.g. “_mta-sts.example.com”). The main difference to DANE and STARTTLS is that the results of DNS queries are stored in a cache so that manipulations by later connection attempts during the retention period are very likely to be detected.

Conclusion – Hornetsecurity offers highest email safety

Recent events show that widespread security protocols such as TLS by itself cannot guarantee safe connections between email servers. Previous improvements, such as DANE and DNSSEC, have so far not been applied worldwide, partly due to technical difficulties in implementation.
With standardized sender reputation procedures such as SPF, DKIM and DMARC, Hornetsecurity’s email service offers reliable protection against cyber attacks on email communication. The recommended standards of the BSI and TeleTrusT for secure email authentification have already been fully implemented and are successfully applied in the products of Hornetsecurity such as the spam filter and the content filter. For secure email communication, it is advisable to rely on the additional protection of content encryption using S/MIME (Secure / Multipurpose Internet Mail Extensions) or PGP (Open Pretty Good Privacy). The PKI-based email encryptions ensure the confidentiality of the transmitted messages between sender and recipient and protect the transferred data using cryptographic encryption methods. The Hornetsecurity encryption service offers this security solution directly in the cloud and thus completely secures the transmission process.
The new MTA-STS standard is supposed to provide better protection for the transmission process of emails with the help of already known techniques such as HTTPS and to provide methods for the detection of irregular access.
The ease of implementation and the rapid distribution are currently increasing the acceptance of this standard, which is currently being used by more and more mail administrators for its security potential.