Spam has been an constant and chronic problem since the early days of the internet. The first unsolicited mass e-mailing (later termed SPAM) was sent on May 1, 1978 by Gary Thuerk of Digital Equipment Corp (DEC) advertising the VAX T-series to 400 of the then 2600 ARPAnet users.
The SMTP protocol we still use today for emailing, grew out of these early mail protocols used in ARPANET (Postel RFC788 and RFC821) in the early 1980's, and has changed relatively little since. From its inception, the SMTP protocol had little (no) security built in, and when used to send email it provided no protection against the spoofing of emails addresses or servers. However, several new tools have recently been added to the email security arsenal to protect against these threats.
SPF, DKIM and DMARC are closely related features for the detection of spoofed or spam emails, but are subtly different.
SPF (Sender Policy Framework) uses a DNS entry to specify a list of servers that are allowed to send email for a specific domain. Its security relies on the fact that only authorized domain administrators are allowed to make changes to the domain DNS zone records.
DKIM (DomainKeys Identified Mail) differs from SPF in that rather than simply validating that the sending server is authorized to send mail for the domain, it also validates that mail content has not changed since being sent by the server. DKIM utilizes a public/private key signing process using DKIM keys stored in DNS.
With DKIM, the following steps are added to the email process:
If any change is made to the email body content, the email signature will no longer match and will fail validation.
This process validates both that the email content has not been modified, and also that the email was indeed sent by an approved server for the domain.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) combines elements of both SPF and DKIM by stating a clear policy which should be used with both the aforementioned tools, and additionally allows the domain administrator to set an address which can be used to send reports about forged mail messages statistics to that have gathered by receivers against the specific domain, e.g.
In an ideal world, all email servers would be using these methods, and the SPAM problem would be a whole lot better than it is. In reality, however, making a mistake configuring the required DNS TXT records can result in important emails being lost, so some domain owners have been reluctant to adopt the methods. In spite of this, major email domain owners such as Google, Microsoft, and Yahoo have adopted these methods, and FortiMail has been an early adopter, supporting these standards on the full range of FortiMail appliances since their inception.
Even with these methods, however, SPAM can still occur through compromised accounts and servers, shared hosting email servers, and misconfigured servers, so multi-level email security is the only way to guarantee a clean and secure email feed.
Definitely...but with caution. These methods can certainly have a major impact on the war against SPAM, and the more domains that employ them, the better this becomes for everyone. However, care should be taken in configuration to ensure that settings are correct before making the changes live. SPF, for example, has the ability to set the changes in a test mode whereby recipient domains will not block any mail that fails the check.
If you need more details on configuring SFP, DKIM, and DMARC validation of your FortiMail appliance, see the following Cookbook article.