Most incoming mail servers use many different methods to analyze the incoming messages, including SPF, DKIM, spam (content) filters, rate limiters, and many other techniques.
We want to talk about the best practices to prepare your domain for e-mail success. To do this we’re going to cover the most important topics: SPF, DKIM, & DMARC Records
We will show below a brief non-technical analysis of what each is and how they function, however view the individual article related to each for more information and instructions on how to setup.
So How Does SPF Work, Briefly, and in Non-Technical Terms?
Sender Policy Framework (SPF) is an attempt to control forged (spoofed) e-mail. SPF is not directly about stopping spam – junk email. It is about giving domain owners a way to say which mail sources are legitimate for their domain and which ones aren’t. While not all spam is forged, virtually all forgeries are spam. SPF is not anti-spam in the same way that flour is not food: it is part of the solution.
SPF Records allow an incoming mail server to know what servers really are allowed to send mail for their domain. So if an incoming mail server recieves e-mail from a domain and it sees that the server IP that the mail is coming from is not in the list of ‘Allowed’ IP Addresses that can successfully send e-mail for their domain then it will not pass the SPF Record checks.
If the SPF record check that the mail server performs fails, then the result of the fail (such as deleting the mail, sending to junk, allowing the e-mail still, etc.) will be determined by the DMARC record that you have setup which we’ll be going over in just a few paragraphs down.
So How Does DKIM Work, Briefly, and in Non-Technical Terms?
DomainKeys Identified Mail (DKIM) allows senders to associate a domain name with an email message, thus vouching for its authenticity.
This is done by “signing” the email with a digital signature, a field that is added to the message’s header. A “signature” is generated by the sending mail transfer agent (MTA) using an algorithm, applied to the content of the signed fields, which creates a unique string of characters, a “hash value.”
When the signature is generated, the public key used to generate it is stored in the DNS Zone for the domain as a TXT record. After recieving the email, the recipient MTA can verify the DKIM signature by recovering the signer’s public key through DNS. It then uses that key to decrypt the hash value in the email’s header and simultaneously recalculate the hash value for the mail message it received. If these two match, then the email has not been altered. This gives users some security knowing that the email did actually originate from the listed domain, and that it has not been modified since it was sent.
DKIM uses a pair of keys to verify a senders authenticity. One key, the “Private Key”, is kept safe by the sending server DKIM is created on. It cannot be shared in any way because whomever has this key will be able to sign a message on behalf of the domain.
What we mean by this, is if someone had the DKIM’s Private Key for servermagagementco.com, then that person could send out email claiming to be from servermanagementco.com. Obviously this would not be good, which is why it’s important not to provide public notice as to what your private key is.
The second key is a “Public Key”. The Public Key allows anyone to verify that a signature, which is generated by the private key and stored in the e-mail headers, was made with the corresponding Private Key and hasn’t been tampered with since being sent. DKIM uses DNS to publish the Public Keys, so that any party that wants to validate a signature can easily find the public key.
So How Does DMARC Work, Briefly, and in Non-Technical Terms?
A DMARC policy allows a sender to indicate that their messages are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes – such as junk or reject the message. DMARC removes guesswork from the receiver’s handling of these failed messages, limiting or eliminating the user’s exposure to potentially fraudulent & harmful messages. DMARC also provides a way for the email receiver to report back to the sender about messages that pass and/or fail DMARC evaluation.
The DMARC protocol doesn’t eliminate the need for additional forms of filtering (such as content filters for keywords in spam), but it does provide a way for participating senders and receivers to streamline the process by coordinating their efforts. If the Incoming Server can tell that the sender is using DMARC, then the incoming server can have more confidence in the decisions they make about messages using that senders domain. Because they can more clearly tell which messages are legitimate and which aren’t, they can reduce their processing overhead while preventing more spam and phishing messages from reaching their customers’ inboxes.
A mail server configuration between different e-mail providers rarely is the same. Normally Server A is performing one set of checks, while Server B makes a different set of checks… and they handle the way they filter those messages that fail SPF & DKIM checks in a completely different way.
DMARC not only tells an incoming server what records the domain has available… but it also tells the incoming server recommendations on how it should handle those failures (such as delete the message, mark as junk, or allow the e-mail to go through). It is up the the incoming server on whether or not it abides by those recommendations, or if it wants to handle the actions taken differently. Most of the bigger e-mail providers aregoing to abide by your domains DMARC settings, so it’s a great thing to have set for your domain.