We rely on email as one of our most common methods of communication. In this video, you’ll learn about SPF (Secure Policy Framework), DKIM (Domain Keys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting, and Conformance).
If you check your spam folder right now, you’ll probably find some messages in there that say they’re from a friend or a family member, but obviously those messages did not originate from those people. That’s because the protocols that we use to get emails from one server to another don’t have a lot of security checks built into the protocols themselves. We’ve had to add on additional security features just to include some type of checks and balances with our emails.
And it’s remarkable how many of these emails in our spam folder are spoofed. This means that the name that is on the email is not the person who actually wrote this email. This is obviously a significant concern, not only for individuals but for corporations and other organizations. They want to be sure that if you receive a message that it really did originate with that person. For example, you may see an email from me that says it came from james@professormesser.com. But how do that message really originated from me?
Fortunately, there are additional security checks that we can add to our DNS servers that will allow us to confirm if an email address was really sent from a legitimate server. First, we need some device that will be able to make the decision on whether this email is legitimate or if it should go into the spam folder.
This decision is often made by the mail gateway. This is the gatekeeper of all of the mail for your organization. Sometimes there’s a single server. There may be multiple mail gateways for your environment. This will take information coming from other mail servers on the internet, and it will grab those emails before putting them into your email inbox. It checks those emails to see if it was really sent from a valid source. And if it’s valid, it gets put into your inbox. If it’s not valid, it will probably be discarded or put into your spam folder.
If you have a mail gateway that is on premises, then you’re probably putting that into a screened subnet because it does need to communicate with other devices on the internet. But, of course, you can have that mail gateway function also stored in the cloud, and there are many third-party services that will provide that functionality for you.
If you’re in charge of email for a domain, then you need to add a Sender Policy Framework, or SPF, record to your DNS server. This SPF protocol defines which email servers are authorized to send mail on our behalf. These are added to your DNS as a text, or TXT, record. That means that anyone on the internet could query your DNS server to see the values that are saved in that text record.
So when an email that I sent to a third party is received by that third party’s email gateway, it will check my DNS server and try to find all of the servers that are allowed to send mail on my behalf. In this TXT record, you can see for professormesser.com that mailgun.org is allowed to send mail on my behalf. And if the third party looks through the headers of that email and they see it originated at mailgun.org, they can feel comfortable that this email really did originate from an authorized server.
If you have a web-based front end to your DNS, you can add this information very easily. This is a text record that I’m adding. This is the content of the text record that says, for professormesser.com, we’re going to include mailgun.org as one of the authorized servers.
An additional verification to my outgoing emails can be provided using digital signatures. I can configure my mail server to automatically digitally sign all of the email being sent to a third party. This is using a key that can be validated from a DKIM, or Domainkeys Identified Mail Record, that is in my DNS.
This is not a digital signature that I’m adding to my message. This is a digital signature added to the transport process between mail servers. This is not something that’s commonly seen in your email you would have to look at the headers of the email, and you should find a DKIM signature in those headers. The receiving email server can then query my DNS server and find the text record containing the DKIM public key. That public key can then be used to validate the digital signature and confirm that that really was sent from my server.
Because the DKIM information is also added to a DNS text record, it’s the same process as adding an SPF record. You can see that we’re putting in hostname information. There is the content, which is the public key for this record. And then we can save the changes into our DNS.
When I send an email to a third party, they’re able to validate the SPF and DKIM information and feel comfortable that that email really did originate from me. But what if the SPF and DKIM information did not properly validate? What process should the receiving email server take with that particular email?
We can specify what we would like people to do with those emails by adding a DMARC record to our DNS. DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. This is an extension of the Sender Policy Framework and the Domainkeys Identified Mail Function.
As you probably guessed, there is a DNS text record that we would add defining what to do with these messages that don’t validate. And we can specify different actions depending on what we would like to have happen to these emails. For example, your options for DMARC are to accept all messages, send those messages to a spam folder, or simply reject those emails. So now, when that third-party mail server is not able to validate the email, they can check with my DNS server to see what I would like to have happen to those messages.
Another nice feature of DMARC is you can specify a destination for compliance reports. This means that the receiver of email messages that say they’re from me can validate those and create a report showing how many of those messages validated properly and how many of those messages did not validate properly. All of these metrics can be sent to 1 centimeter reporting engine. This allows the domain owner to create reports showing how many messages are being sent and validated properly on the internet and how many messages may be sent that are spoofing my email domain.
Here’s a DMARC record, and it is added to the DNS server as a TXT or a text record. You can see that it’s designated as DMARC1. I’ve set my emails to be put into quarantine if they’re not properly validated, and all of the statistics surrounding the receiving of these email messages is sent to one central DMARC reporting engine. Now, I, as the domain owner, can go to this reporting engine and get an idea of how many emails are being received properly by the end users and how many emails may be spoofed by a third party and what the disposition of those emails might be.