The third part of our series of articles on e-mail security deals with the identification protocol DKIM and the standard method for e-mail authentication DMARC.
In our first article and second article on the topic of e-mail security, we informed you about the origins of e-mail and the current statistics in mail traffic at RWTH. In addition, we explained what the SMTP protocol is and what problems it can cause.
DKIM – An Identification Protocol for Ensuring the Authenticity of E-mail Sender Addresses
In order to be able to manage secure e-mail exchange for you, the IT Center plans to implement another security mechanism in the future: DKIM (Domain Keys).
While SPF (Sender Policy Framework), which we explained to you in more detail in the second article, ensures that the sending mail server is authorized to send e-mails for an e-mail domain, DKIM (Domain Keys) is to ensure authenticity. DKIM is therefore intended to ensure that the content of the e-mail cannot be changed in transit, for example by a compromised mail server. The sending mail server calculates a digital signature that can be verified by the receiving mail server. This can be used to ensure that an e-mail has not actually been modified in transit.
As with SPF, a DNS (Domain Name System) entry is also used here, which in this case provides a public key. The receiving mail server can then use the key to verify the signature.
In the example below, the mail provider GMX has already activated DKIM. The corresponding entry in the mail header looks like this:
DMARC – Standard Method for E-mail Authentication
The DMARC (Domain-based Message Authentication, Reporting and Conformance) method combines SPF and DKIM.
DMARC looks at the side of the person receiving the email and can specify a rule on how to deal with mails whose SPF and DKIM checks have errors.
Now, one might naturally conclude:
“That’s great, let’s just implement SPF, DKIM and DMARC, then we are “safe” “.
But unfortunately this is not the case, because especially the implementation also brings restrictions.
Especially affected by these limitations are automatic email redirections. In contrast to forwarding, the original sender address of the e-mail is retained here. However, the redirecting mail server now acts as the sender of this e-mail. And this with a sender address of a domain for which it is not authorized.
Here is an example:
- mail@Person1.de sends an email to Person2@rwth-aachen.de.
- a redirection to Person2@gmail.com is configured on the account Person2@rwth-aachen.de.
- the email is first delivered to RWTH, where it is redirected to Gmail.com while keeping the sender mail@Person1.de.
- From Gmail.com’s point of view, the RWTH’s mail server now appears as the sender of an e-mail of the domain @Person1.de, for which, however, it is not authorized at all.
- The SPF check fails in this case. The e-mail may be classified as SPAM or even rejected altogether.
What exactly happens is essentially determined by the mail domain holder’s DMARC policy published in the DNS. In no case can the redirecting server have any influence on the way of delivery.
Now you could also say:
“Oh, too bad. Let’s do without DMARC then.”
But no! The number of mail servers that require a DMARC implementation to accept mail from a mail domain is increasing. It can be assumed that DMARC will defacto become the standard. Therefore, RWTH Aachen University is also striving to implement DKIM and DMARC for its mail domains.
What Can Each Individual Do?
You can have a look at the different rule sets in the web frontend [0] of the mail system. If you have defined a redirection rule for your mailbox you can already convert it into a forwarding rule. A forwarding rule generates a new e-mail with your e-mail address as sender. If you don’t need this rule anymore, you can remove it completely. Modern email clients can also handle multiple integrated email accounts and sometimes even offer consolidated views for inboxes.
Responsible for the content of this post are Morgane Overath and Thomas Pätzold.
[0] https://mail.rwth-aachen.de
“Falls Ihr für Euer Postfach eine Umleitungsregel definiert habt könnt Ihr diese jetzt schon in eine Weiterleitungsregel umwandeln”.
RWTH-interne oder Domain-interne Umleitungen (Beispiel: funktionsadresse@iii.rwth-aachen.de zu nutzer@iii.rwth-aachen.de) sind kein Problem? Kann das problematisch werden falls die RWTH selbst einen DMARC-Eintrag im DNS veröffentlicht?
Hallo Jan,
vielen Dank für deinen Kommentar.
Ja, das ist derzeit unproblematisch und wird es wohl auch bleiben, denn wir überprüfen die DMARC-Policy nur bei der Mailannahme aus dem Internet.
Viele Grüße
Das IT Center Blog Team