SPF, DKIM, and DMARC
What Business Managers Should Know About These E-mail Sender Authentication Technologies
Introduction
This article covers three technological methods available that can confirm or deny the authenticity of e-mails that seem to come from your company.
Having these configured helps you to:
- Minimize messages from your company being filtered as spam.
- Prevent criminals from successfully sending messages that appear to come from your domain.
Here are the technologies and what they do, in brief.
- SPF specifies which servers are allowed to send mail from your domain. Mail coming from unauthorized servers might be considered forged. This is the easiest to implement, and doesn't require reconfiguration of any devices or hosted systems that send e-mail from your domain.
- DKIM is more difficult to implement, especially if you have devices (such as scanners) that generate outgoing e-mail. But, it provides a great level of assurance to receivers as to authenticity of the message through cryptography.
- DMARC is a powerful tool for monitoring mail transmissions (including messages not from your company but claiming to be from your domain), and for signalling the level of integrity you wish for mail servers to enforce when a message comes in apparently from your domain. It's the easiest to set up, but the most complicated to make use of.
When these are configured, they are all transparent to your users. There's nothing your users have to do or even know. Mail systems receiving messages from your domain perform SPF and DKIM checks based solely on information posted in your company's public DNS, the IP address of the sending mail server, and/or e-mail headers (such as what address is shown in the "From" header). These checks have nothing to do with the content of the e-mail, attachments, or links, though. Even if fully authenticated by SPF and DKIM, legitimate messages from your organization still may be filtered by recipients' systems as junk if they contain excessive graphics, links to suspect websites, keywords found in typical solicitation or scam messages, etc.
SPF
Sender Policy Framework (SPF) is implemented as a record in your DNS that specifies what mail servers, identified by IP address, are allowed to send mail from your domain. Mail servers around the world, when they receive a message apparently from your domain, will look up this record and see if the sending server's IP address is in the list. The servers for your main e-mail hosting provider, of course, should be listed here. But, if you sign up for a marketing service that will send mail from their servers on behalf of your domain, or if you have a scanner in your office and you want it to transmit scans by e-mail directly, your IT provider should put the IP addresses for your marketing company's mail servers or your office, respectively, in your SPF record.
There are some weaknesses, though. SPF only checks the domain name the sending server uses to identify itself when commencing transmission of e-mail. It does not check the "From" address inside the message itself, which the recipient will see when it lands in his inbox and which does not have to match the sending server's domain name. Given this, if a criminal sends a message from his own server that identifies itself using the criminal's domain name, and the criminal's domain is configured with a valid SPF, the message will pass SPF even though he puts your e-mail address in the "From" line in the message itself. The spam filters on the receiving server may notice the mismatch, however, but it's up to that server whether to filter the message (unless you impose a restrictive policy to protect your domain through DMARC, which isn't necessarily a good idea—more on this below).
Also, if someone has an account on the same mail hosting system used by your company, he may be able to send an e-mail using your domain name for both the "From" address and the sending server identification, and it will pass SPF on your domain, with a matching From address, since it will come from a server using an IP address listed in your domain's SPF record.
As a result, passing SPF alone doesn't provide much confidence to the recipient's system that the message is legitimate, or protection for the recipient from getting a message with a forged sender address. It is still important to use, however, because your domain will have a low reputation, and mail servers will be more likely to dump messages from your domain to the junk folder, if no messages are ever seen from a server using your domain name and designated as authorized by your SPF record. In addition, in case the other common authentication system, DKIM, malfunctions, then having passed SPF may convince a receiving mail server to accept your legitimate message when it otherwise wouldn't.
DKIM
Domain Keys Identified Mail (DKIM) involves configuring your mail server to attach a code (called a digital signature) to each outgoing message, which is computed using a complex formula that combines the contents of the message with a secret key that only your mail server knows. Using a separate cryptographic key published in your DNS for validation purposes, a receiving e-mail server can run a computation on the message and its digital signature that can confirm both that the secret key was used to create the signature (meaning the message could only have come from your server) and that the message wasn't intercepted and modified in transit. This verification works without the receiving server needing the secret key, because the key published in your DNS is mathematically related to the secret key. It's a very clever process, and it's pretty much impossible for someone to forge an e-mail from your domain that will pass the DKIM check.
DKIM checks the domain name specified in the visible From address in the message itself, not the domain name of the sending server. As you can see, passing DKIM provides much greater confidence to receiving mail servers that an incoming message is legitimately from the company the recipient will think it's from. The only drawback is it takes some more effort to implement and maintain.
To use DKIM on all messages, each mail server your company uses to send mail must have the capability to apply digital signatures, and be assigned its own secret key, with its related validation key posted in DNS. Major providers now make this easy, so for your regular users sending mail through their usual apps or web browser, a DKIM signature is applied automatically to every message.
But devices, such as scanners, need to be configured to relay messages through one of your mail servers that can then apply the DKIM signature, rather than more simple mail relay methods typically used. This adds administrative complexity and therefore more ways for the scanner to stop working if someone makes changes to the enterprise e-mail configuration without updating all your scanners and similar devices.
If you use third parties to send mail from your domain, they will need to support DKIM, and you will need to publish the keys for validating their servers in your DNS. This isn't much more complicated than adding their IP addresses to your SPF record.
If any secret key is somehow leaked, though, the potential damage is great, as a scammer can send messages from your domain that recipients' servers will determine are legitimate, with a high level of confidence. So protecting access to the configuration of your mail servers and your IT documentation is of greater importance, as is validating the security readiness of third parties you trust with a DKIM key.
DMARC
Domain Message Authentication Reporting & Conformance (DMARC) informs all mail servers that receive messages from your domain that your system uses SPF and/or DKIM, and directs what a receiving server should do with a message that fails both tests. It also provides a method by which mail systems can provide feedback to each other to track the nature of forgery attempts, or whether SPF and DKIM are working for legitimate messages. DMARC is implemented simply as a directive published in your DNS.
In its most secure configuration, DMARC would specify to receiving mail servers that anything apparently coming from your domain that fails DKIM checks should be rejected, unless it can pass SPF using the domain name shown in the visible From header (enhancing the SPF system in that way). This strict setup should only be used for very limited and controlled e-mail implementations, however. You don't want one mistake in the various SPF and DKIM configurations that must be tracked to cause a whole subset or all of your outgoing mail to be bounced! Also, even if all your systems are configured correctly, if your users send messages to a group e-mail address (distribution list), the system hosting that list might modify those messages and resend them from its own servers while leaving your domain name in the From header, causing rejection (per your DMARC requirements) when it reaches its final destination. The same can happen when sending to an individual intended recipient who set up his e-mail system to forward messages to another address he uses.
If your DMARC does not request any specific action on failure, the recipient's mail system will make its own decisions, depending on what kind of junk mail filtering system is in use. It's certainly possible that mail from your domain that fails SPF and/or DKIM will be delivered normally. This can depend on the reputation of your domain and the sending server, which some systems track.
Given this, the best use of DMARC for most companies is simply to publish an e-mail address to which reports will be sent about mail received apparently from your domain. These are sent automatically every night from every mail server participating in the DMARC system, covering messages received in the prior 24 hours. The reports contain tons of information, and aren't useful for a human to look at. But, these can be forwarded to a DMARC analysis service, which can then parse and examine the records to allow you to find out how many messages were sent from impostors using your domain name, and what happened with them (whether they passed checks). You can reconfigure your outbound mail systems to mitigate any serious issues discovered. The reports can also give information on the message headers and links in the body of messages received, so you can report details about criminals who are forging your company's e-mail addresses to their mail hosting provider or law enforcement.
Because these reports are sent by receiving servers based on your published request, it gives you visibility not just on your own outbound messages, but messages claiming to be from your domain that never were sent or received by any systems you control. This cooperative information sharing is what makes DMARC such a powerful tool for managing your domain's reputation.
As far as legitimate outbound messages from your company, DMARC reports help you confirm they are being authenticated properly with SFP and DKIM by recipient servers (especially important if you use a third party to send out mailings).
Final Notes
Most companies work fine with SPF and DKIM configured to authenticate the e-mail servers that handle messaging for their regular users. But if criminals are sending a high number of forged messages apparently from your domain from their own servers, this can cause conspicuous problems. First, it can annoy your own users and business partners. Worse, it could cause mail servers around the world to consider your domain to have a low reputation because of the malicious software and links contained in these forged messages, causing legitimate messages from your company to be flagged as spam even when they pass SPF and/or DKIM. In these cases, careful analysis of DMARC reports can help with shutting down the spammers, or deciding whether implementing a "reject" directive in DMARC, despite its drawbacks, is best for your company and its security requirements.
As you can see, a balance must be struck, and monitored and adjusted, to limit the ability of forged messages reaching the intended recipients, while ensuring your legitimate messages aren't incorrectly rejected.
For help with all this, of course, your best bet is to contact J.D. Fox Micro.