When we are working in the email and messaging sphere, we are always confronted with spam, phishing, and other dangers. However, there are ways to prevent this. We can use tools such as SPF, DKIM, or DMARK. What these tools are exactly? How do they work and how can we use them in a way that they really work as were designed? Yes, there is documentation and articles on the Internet, but there are many people out there who are not that sure how these tools have to be used and how to configure them. In this article, I will take a closer look at them and explain all about how to use them correctly.
What is an SPF record?
SPF is an abbreviation of “Sender Policy Framework.” The SPF is a method to prevent forgery of the sender address of an email. It originated as a method of spam prevention. For SPF, the domain owner enters the Domain Name System, which authorizes computers to send emails for that domain.
To create an SPF record, we need to use the TXT entry in our domain’s DNS zone. Let’s explain this with the example of contoso.com:
In the zone of contoso.com we have the following SPF record:
v=spf1 +a +mx +ip4:18.104.22.168/24 +ip4:22.214.171.124/21 +ip4:126.96.36.199 –all
This SPF record states that all emails are sent with the sender “@contoso.com” via one of the IP addresses / ranges specified in the SPF. I use the CIDR notation for the IP addresses of my complete Contoso network, so I do not have to specify all IP addresses individually. Specifically, servers with the following IP addresses may send emails under the name of @contoso.com: 188.8.131.52 – 184.108.40.206 and 220.127.116.11 – 18.104.22.168. As well I have a single server in a dedicated network, which is also allowed to send emails from my domain.
Suppose a spammer sends a spam email using the sender @contoso.com. The mail server that receives the email checks the sender’s IP address and compares it with the SPF entry for contoso.com. If the spammer does not send spam via the Contoso server, the email is immediately rejected by the recipient because the sender IP does not match the SPF entry of contoso.com.
Building an SPF record
We have seen in the example what an SPF record must look like for the Contoso company. However, let us have a closer look at it.
Each SPF record starts with a version number — for the current SPF version “v = spf1.” It follows any number of expressions, which is evaluated in the order from front to back. Most expressions are so-called directives that define the authorization of the sender and consist of an optional qualifier and a so-called mechanism that yields either a hit or no hit for a given situation (IP address). The first mechanism that represents a hit determines the result of the entire evaluation of the SPF record.
There are the following qualifiers:
|the directive defines authorized stations;
this is the standard, d. H. if no qualifier is specified, + is assumed
|the directive defines unauthorized senders
|the directive defines unauthorized senders, but the recipient should treat this failure generously.
|the directive defines channels whose legitimacy is not to be stated; The transmitter must be accepted.
The following table shows some common mechanisms:
|Description (Directive applies if…)
|… an A (or AAAA) Record of the polled (or explicitly specified) domain contains the IP address of the sender
|…an MX record of the polled (or explicitly specified) domain contains the IP address of the sender
|…the specified IPv4 address is the IP address of the sender or the specified IPv4 subnet contains it
|…the specified IPv6 address is the IP address of the sender or the specified IPv6 subnet contains it
|…An additional SPF request for the domain specified in the include statement contains the IP address of the sender
In the DNS entry of a domain, there are already normal MX entries, which tell SMTP servers which host they should send emails for this domain. So, if an SMTP server should send an email to [email protected], it looks in the MX record of example.org for the server that should send the mail. SPF now adds a reverse MX-style record to DNS records in a domain. If a mail server receives an email from a sender of example.org, it will check the SPF record of example.org to determine whether the serving mail server is entitled to send emails for that domain according to the SPF record.
SPF can also help combat spam and hinder phishing by facilitating email traceability. However, SPF can only prevent sender address forgeries — it cannot directly combat spam.
SPF only needs to be supported by the recipient system — the protocol of the mail transfer (SMTP) does not change anything. The publication of SPF records is voluntary for a domain — emails from domains without SPF records should not be considered negative by recipients according to the SPF specification (RFC 4408). However, such domains naturally remain unprotected against envelope adulteration.
What is DKIM?
DKIM is short for “DomainKeys Identified Mail” and it is an authentication protocol to ensure the authenticity of email senders. It was developed by Yahoo and has been an Internet standard since the end of 2013. It is designed to help curb unwanted email such as spam or phishing.
The organization is a handler of the message, either as its originator or as an intermediary. Their reputation is the basis for evaluating whether to trust the message for further handling, such as delivery. Technically, DKIM provides a method for validating a domain name identity that is associated with a message through cryptographic authentication.
DKIM attaches a new domain name identifier to a message and uses cryptographic techniques to validate authorization for its presence. The identifier is independent of any other identifier in the message, such in the author’s “From:” field.
The first version of DKIM synthesized and enhanced Yahoo’s Domain Keys and Cisco’s Identified Internet Mail specifications. It was the result of a year-long collaboration among numerous industry players, during 2005, to develop an open-standard email authentication specification. Participants included Alt-N Technologies, AOL, Brandenburg InternetWorking, Cisco, EarthLink, IBM, Microsoft, PGP Corporation, Sendmail, StrongMail Systems, Tumbleweed, VeriSign, and Yahoo!. The team produced the initial specification and several implementations. It then submitted the work to the IETF for further enhancement and formal standardization.
How DKIM works
When an email has been sent, DKIM adds a so-called DKIM signature to the header of the email. When the email is received, the receiving server queries the public key published by the TXT resource record in the DNS zone of the domain. This key verifies that the signature is correct. The aim of this process is to make it more difficult for spammers and phishers to carry out their criminal activities.
Here is an example of a DKIM entry to make it more understandable:
By the way, Microsoft supports DKIM to prevent spoofing in Exchange and Office 365. For more information, you can get it straight from Microsoft.
What is DMARC?
DMARC, or “Domain-based Message Authentication, Reporting, and Conformance,” is a specification that has been developed to reduce misuse of email. It seeks to address some of the long-standing shortcomings of email authentication issues and has been submitted to the IETF for standardization.
The starting point of DMARC is to protect your own domain against misuse from other senders by acting as the owner to do the necessary preparatory work so that the recipients can check whether the sender can also send for this domain. There is already a method with SPF or RMX to publish the “source IP” of systems acting as a sender host for a domain. However, this limits the possibilities mails, for example through relays or providers where you change or extend mail server addresses. With DKIM, there is a way to sign a mail yourself. It is not a classic digital signature with S/Mime or PGP but very similar. The integrity of the mail is thus ensured, and that means the content is protected against changes and the sender is confirmed.
However, DMARC goes further and publishes information on how the recipients should inform you as the domain owner about abuse. The recipients not only check the incoming mails against SPF and DKIM parameters but also send status messages and summaries to the stored reply addresses via DMARC.
As a domain owner with a suitable processing, you get direct feedback on how strongly their domain is used by strangers unauthorized. It, therefore, serves primarily to protect our brand. Of course, this will be interesting if the major mail recipients and hosters not only use SFP and DKIM as spam filters but also use the data from the DMARC entry. So it is not a new spam filter, but DMARC primarily adds a way how abuse can be spotted.
Structure of a DMARC entry
DMARC uses the TXT records of the Domain Name System (DNS). There, in addition to the SPF and DKIM entries, another RR entry with the following structure is created:
v=DMARC1;p=quarantine;pct=100;rua=mailto:[email protected];ruf=mailto:[email protected];adkim=s;aspf=r
Here is an overview of the abbreviations:
|percentage of emails to be filtered
|forensic Report will be sent to:
|aggregated report is sent to:
|instruction on how to deal with mails of the main domain.
|instruction on how to deal with mails of the subdomain.
|calibration mode for DKIM
|matching mode for SPF
SPF, DKIM, and DMARC: Put them to use
SPF, DKIM, and DMARC — now that we have had a closer look to all of them, it`s up to you to decide which of them you want to use for your environment. My advice is to use at least one of them for your organization. Years ago, I personally started using SPF. Nowadays, this should be a standard in each company. If we have a closer look at the messaging providers like Cyon, Yahoo, Gmail, and Yandex, we can see that even they are using these technologies to get a higher anti-spam score. These tools also help our anti-spam environment in general to presort malicious traffic and prevent it from getting to our users.
Featured image: Shutterstock