Fight Against SPAM With DKIM and SPF
Fight Against SPAM With DKIM and SPF
Spammers are a bane to individuals and businesses alike. Here's how to use DKIM and SPF to fight the good fight and secure your inbox.
Join the DZone community and get the full member experience.Join For Free
Far away, in a distant galaxy called the Internet, SMTP (simple mail transfer service) servers transmitted emails without asking questions. Then the nasty aliens, a.k.a. Spammers, landed and it became crucial to rethink everything.
The following post shows how to fight against these demonic creatures. It also sheds light on why it has become vital to set up weapons such as SPF and DKIM that will help verify whether the emails are transmitted via SMTP servers or not.
We’ll end this lighter side of the introduction here, as you think what is the role of the SMTP server is in sending and receiving emails.
Mail transfer agent (MTA) or mail relay is software that transfers electronic mail messages from one computer to another using a client-server application architecture. POP/IMAP servers are services set up to allow the user to retrieve emails on the SMTP server using a client (heavy clients such as Outlook, Thunderbird, Webmail, etc.).
The most well-known and used SMTP servers are the Send mail history and its little brothers Postfix, Exim, and Qmail. The configuration examples that you will find later in the article are from Postfix.
How Does the SMTP Server Know Where to Route the Mail?
As simple as hello, he queries the DNS zone of the domain – the part to the right of the “@” in an email address. He wants to join a search for an MX record (mail exchange) that points to the IP mail server responsible for collecting mail for this area. If you are looking to send an email to firstname.lastname@example.org, your SMTP server will look for where to send the mail in the DNS zone of eukhost.com. You can do the test yourself using the
| Nslookup –q = mx eukhost.com
| Eukhost.com MX preference = 1, mail exchanger = mx0.eukhost.com
| Eukhost.com MX preference = 100, mail exchanger = mxb.eukhost.com
In the above example, you’ll notice the presence of two MX records, which differ in their “preference” or “priority.” Here, too, we start by trying to reach the server with the lowest priority, and if it does not answer, we move on to the server with a higher priority to the first server that responds. Note that it would be better to drop the MX records in favor of SRV records, which offer more features, such as load balancing or the ability to specify the port where the service is hosted.
For example, consider the MTA as a little post office. The company takes care of transferring the mail from one post office (server) to another based on your address (email) where the postal service code acts as field MX to know in which post office to send the mail. The MUA is your factor, it delivers the mail that arrives at the post office in your mailbox (Computer, Smartphone, PDA, etc…). The interest of the exchange of mail on the Post Exchange is that one can easily receive the mail in several places simultaneously leaving a copy of the message on the server for a more or less long duration.
Like the post office, by default the SMTP server does not try to verify the sender’s address, nor does it try to authenticate the person using the service, a trifle for spammers and other malicious people acting on the web. The first thing to do is to implement the security mechanisms you need so that your SMTP server does not become an open-relay that can be used by the first-comer.
The mail server configuration systems have mechanisms for accepting or rejecting the sending of an email based on the client configuration or on the destination. For example, the configuration directives “smtpd_client_restrictions” or smtpd_recipient_restrictions (Postfix) allow you to do this job. That’s why the value of this kind of guidance is extremely important and should never be left to change.
If your SMTP server is open on the Internet, you’ll also need to set up an authentication mechanism such as SASL, so that only users with a mailbox and therefore a login & password associated on your server can use it.
Of course, as in SMTP everything goes clear and you do not want that someone can catch your password or read the mails you send, it will be necessary to set up an SSL/TLS overlay with a valid certificate to finally have a secure service to offer to your users. You will also need to set up an authentication mechanism such as SASL, so that only users with a mailbox and therefore a login/ password associated on your server can use it.
Your SMTP server is now secure and only authenticated users are allowed to use it, so the mail that comes out can be considered legitimate. But since it is possible to send mails without any verification of the identity of the sender via any unsecured server, what proves to your recipient that the mail that he has just to receive from you legitimate?
Since our server is considered trustworthy, we will seek to establish the identity of the server that sent the message and to verify that it is indeed a reliable server. This is exactly the purpose of DNS SPF and DKIM registration.
SPF (sender policy framework) is a standard for verifying the domain name of sender of an email, standardized in RFC4408. SPF aims to reduce the possibility of spoofing by publishing, in the DNS, a record (SPF or, formerly, TXT type) indicating the IP addresses of the servers that are authorized to send mail for the domain in question. When the destination SMTP server receives the mail, it can do a check of this type, in which case it either decides to refuse the mail altogether or it can accept it anyway.
It can still decide to notify the user by adding a line in the body of the message – for example the administrator. More generally, it will mainly affect the score that the anti-spam set up at your recipient gives your message and it is the latter who will decide the fate of this message. The decision to take in case of failure of the verification or absence of registration SPF belongs to the solution set up by the administrator. Just keep in mind that even today, only a small percentage of domains have an SPF record before rejecting all mails that do not meet this requirement.
SPF Registration Example
v = spf1 to mx ptr ip4: 22.214.171.124 mx: mail.example.com ~ all
DKIM (domainkeys identified mail) is a reliable authentication standard for the email sender’s domain name, which is standardized by the Internet Engineering Task Force (IETF) in RFC 4871 to address weakness of SPF. DKIM was produced by an industry consortium in 2004. It integrates and enhances DomainKeys from Yahoo! And Identified Internet Mail from Cisco. It should be noted that other major players in the Internet and information systems have taken part in the project, IBM, Microsoft, PGP Corporation, Sendmail, StrongMail Systems. The end goal of the solution is the same for SPF: fight against spam and identity theft. There are free implementations ready to be coupled to the mail MTAs. The most successful project to date seems to be OpenDKIM.
DKIM registration example:
mail._domainkey.example.com. IN TXT "v = DKIM1; k = rsa; p = MEwwPQRJKoZIhvcNADAQCQADOwAwOAIxANPpYHdE2tevfEpvL1Tk2dDYv0pF28 / f5MxU83x / 0b sn4R4p7waPaz1IbOGs / 6bm5QIDAQAB "
But What Does DKIM Bring to SPF?
SPF relies on IP addresses or blocks of IP addresses to verify the source of the message. Only, unlike that tries to make us believe the IP address is the smoking gun, and it is relatively easy or at least far from impossible to spoof an IP address on a network. This technique is called spoofing. This is why an asymmetric cryptographic system is used here.
It generates a key pair, it stores the public key in a type of TXT record in the concerned DNS zone and preciously stores the private key on the server. Whenever the SMTP server sends an email, it will encrypt a small part of the message using its private key. Upon receipt of the message, the SMTP server that detects this field will try to decrypt it with the public key available in the DNS zone of the sender’s domain. If the operation succeeds, it can then ensure that the message received comes from a server with the private key. It his becomes impossible, except in the case of the theft of the private key to impersonate an SMTP server. Here too, the decisions resulting from verification are to be defined by the administrator (acceptance, rejection, notification to the user or administrator).
But then why put in place such solutions since everyone does not do it? First of all because it is clearly the part of the so called "Best Practices." Then, it is a citizen gesture that can reduce the global scourge of spam — that's why so many industry players have gathered around the project. Finally, you will gain valuable points in the anti-spam mechanisms put in place by your recipients, so that the number of messages that end up in the mailboxes will be reduced.
Admittedly, DKIM and SPF authenticate the domain, but what about the left part, the username? How to verify the authenticity not of the server that sent the mail but the user? You will have to use a system of encryption and/or data signing such as PGP or S/MIME to authenticate the message and thus ensure the confidentiality and / or integrity of the transmission.
Opinions expressed by DZone contributors are their own.