Secure your Domain & Your Business. | Prevent Email Spoofing
Email DNS Master Course - SPF + DKIM + DMARC
Author: Emad Zaamout
Sunday, October 17, 2021
Table of Contents
- Introduction
- What is Email Spoofing?
- What is DKIM?
- What is DMARC?
- DMARC - Aggregate Report (RUA)
- DMARC - Forensic Report (RUF)
- How to create a DMARC Record?
- DMARC Tags Table
- What is an SPF Record?
- SPF Record – Qualifiers
- SPF Record – Mechanism
Introduction
Welcome back,
In this tutorial, were going to cover SPF, DKIM and DMARC records.
If you own a domain, it’s very important that you have those records setup to prevent email spoofing, and fraud.
If you don’t have these records set, then you basically allow anyone to send emails impersonating your domain identity. This could get your domain listed. Its important for every domain you purchase, you set your SPF D KIM and DMARC records even if you’re not planning on sending any emails.
Finally, I will show you how you can obtain both your free Aggregate and Forensic Reports so you could monitor emails sent from your domain. These reports can give you insights and records of emails that were sent out on your behalf.
This is a DNS course, so you should be comfortable adding DNS records to your Domain such as TXT record.
Before we get started, don’t forget to subscribe to our channel to stay up to date with our latest training videos.
Email Spoofing
Email spoofing is a technique used in spam and phishing attacks to trick users into thinking a message came from a person or entity they either know or can trust.
If you don’t have a SPF, DKIM and DMARC records set up, spammers can easily send emails impersonating your Domain Identity.
Email spoofing works on exploiting human trust where the attacker asks the recipient for sensitive information or to take some action that could result in fraud using your Domain Identity.
Regardless of the goal or type of actions the spammers aim for, most of the time spam emails are easily detected by the Mail Vendors such as Gmail, Microsoft and if such emails got sent out, this could get your Domain to be blacklist.
If your Domain got blacklisted, its game over as it would be nearly impossible to reverse that. Any email sent from a blacklisted domain will be marked spam and, in many cases, it would even be blocked by the Mail Service Providers.
Also, it’s worth to mention that more than 90% of cyber-attacks start with an email message and there are more than 3.1 billion domain spoofed emails sent per day.
To protect against all that, you will have to set up your SPF, DKIM and DMARC records. It’s very easy to do and literally it should take you just a few minutes to set it up once you fully understand how it works.
What is DKIM
Unless you’re hosting your own mail server, you probably don’t need to worry about setting DKIM records as it would be set up by your mail vendor such as Google, Microsoft, etc. …
If you guys are running your own mail server and would like me to create a tutorial on how it’s done, post a comment, let me know. Otherwise, I will briefly explain it.
DKIM, is a lock and key Authentication process used to make sure that message is not altered in transit between the email sending server and the email receiving server.
The DKIM Authentication process is very simply.
The first step is you create a public and private key pair using either rsa-sha1 or rsa-sha256 (signature algorithms).
You add the public key to your DNS records, and you store the private key either on your own server, or with an email service provider.
For every email sent, the sending mail server adds to the email header a DKIM-SIGNATURE that’s generated using the private key.
The receiving email server extracts the DKIM-SIGNATURE from the header and validates the message using the public key stored inside your DNS.
If the DKIM-SIGNATURE is valid, then the email is sent to your recipient inbox. Otherwise, the email will go to SPAM or JUNK.
Unless you’re running your own mail server, you don’t need to do anything. Its all done by the email service provider.
What is DMARC?
DMARC stands for Domain-Based Message Authentication Reporting & Conformance.
DMARC was first published in 2012; It is a protocol built by Google, Microsoft, Yahoo and PayPal to prevent email abuse. It is supported by all major mail service providers (if not all).
DMARC is used to determine the authenticity of an email message. It lets you control who can send emails using your domain and allows you to set various instructions for the receiving email server.
To get started with DMARC, you must have both your SPF and DKIM records set.
DMARC record is a TXT record that defines what an email receiver should do with mail sent on your domain behalf that is not aligned with your domain policy.
The DMARC record is a TXT record that is added to your domain DNS; It basically includes instructions for the receiving email server on how to handle mail sent under your domain that does not align with your Policies.
We can also specify inside our DMARC TXT record, an email address so that we can receive 2 very important reports:
-
DMARC - Aggregate Report (RUA).
-
DMARC - Forensic Report (RUA).
What is DMARC Aggregate Report (RUA
A DMARC aggregate report contains information about the authentication status of messages sent on your domain behalf. Aggregate reports are free reports that are sent to you and contain information such as:
-
Source that sent the message
-
Domain that was used to send the message.
-
Sending IP address.
-
Number of messages sent on a specific date.
-
DKIM/SPF sending domain.
-
DKIM/SPF authentication result.
-
DMARC results.
What is DMARC Forensic Report (RUA)
A DMARC Forensic report are generated when the SPF or DKIM do not align with your DMARC.
Forensic reports are free reports sent to you ONLY when an email sent by your domain fails DMARC authentication. It contains information such as:
-
The email “to” field.
-
The email “from” field. (From address, Mail from address, DKIM from address).
-
IP address of the sender.
-
The email “Subject” field.
-
Authentication Result (SPF, DKIM, DMARC).
-
Message ID.
-
URLs.
-
Delivery Result.
-
ISP Information.
How to create a DMARC Record?
You create a DMARC record by creating a TXT record for your domain named “_dmarc”. For example, if your domain name is ahtcloud.com, then your DMARC TXT record name is: _dmarc.ahtcloud.com
For example, this a DMARC record: "v=DMARC1;p=reject;pct=100;rua=mailto:support@ahtcloud.com;ruf=mailto:support@ahtcloud.com; fo=1; adkim=s; aspf=s;"
The syntax for DMARC record, is basically a combination of tags separated by a semicolon.
“tag=value;tag=value;”
At the bare minimum, your DMARC record will look like this: "v=DMARC1;p=reject;”.
The “v” tag specifies the DMARC protocol version. There is only 1 DMARC version available which is DMARC1. This is a required field so you should always include it.
The “p” tag allows you to specify how you want mail service providers to handle emails that are sent using your domain identity but are not aligned with your policy.
You have 3 options. Do nothing, set p = 0. Or to quarantine or reject the email. I highly recommend you set it to reject the email to prevent anyone from sending emails using your domain name.
Both the “v” and “p” tags are required. N ow we will cover all the optional tags.
The “sp” tag is an optional tag. Like the “p” tag, it allows you to specific your policy but for subdomains. If you don’t include this, then the value to specified inside your “p” tag will be used.
The “pct” tag, is an optional tag. It allows you to specify the percentage of email messages in which your stated DMARC policy applies for. The values can be anywhere from 1 to 100. I always recommend you set it to 100%. This tells the email receiver to reject 100% of emails that fail DMARC authentication.
The “rua” tag, is also an optional tag. It allows you to specify an email address or addresses to receive DMARC Aggregate Feedback reports too. I cannot emphasize how important it is to have this field set up. Even if your domain does not send emails, you should always set this record so you could get insights into domain spoofing or phishing attacks that impersonates your domain. You can specify multiple emails by separating them with a comma.
I always recommend you have this tag set. The value of the “rua” tag, can be any valid email address.
The “ruf” tag, is also an optional tag. It’s like the “rua” tag but allows you to specific any email address or addresses to receive your DMARC Forensic reports too. I always recommend you have this tag as well even if your domain is not sending emails. The Forensic reports are sent to you when someone attempts to send an email impersonating your domain and it fails your DMARC and DKIM authentication. It instructs the email service providers to send you a copy of that email.
The “fo” is an optional tag. It allows you to tell email service providers that you want email samples if the emails failed. You have 4 options.
-
The 0 value generates report if all authentication mechanisms fail. This means both your SPF and DKIM policy fails.
-
The 1 value generates reports if any of your authentication mechanisms fail. SPF OR DKIM.
-
The d value generates reports if only your DMARC failed
-
The s generates reports of any SPF failure.
You can specific multiple values by separating them with a colon.
I personally recommend you set the “fo” tag to 1 so you can receive a copy of any email sent on your behalf that fails for either SPF or DMARC authentication.
The “aspf” tag, is an optional tag. You can use this tag to speficiy if you want to set your SPF policy to strict or relaxed. By default, if you don’t include this option its set to strict, which is the best option. Remember guys, your SPF policy basically makes sure all emails sent using your domain are authorized to send.
The “adkim” tag is identical to the “aspf”, but its form your DKIM policy.
The “rf” tag, is an optional tag. Honestly, at this point, its useless to include. This tag allows you to specify the DMARC Forensic report format. Theres only 1 value, which is afrf. This is used by default. You shouldn’t need to include this. But this could change in the future maybe if more report types are added.
The last available tag you can use, is the “ri” tag. This is also an optional tag. The “ri” tag allows you to specify the aggregate report interval in seconds. The minimum and default value is 86400 seconds which equates to 24 hours. This means, every 24 hours you will receive a DMARC Aggregate report. I recommend you keep it at the minimum.
DMARC Tags Table
Tag | Description | Example | |
---|---|---|---|
v |
Required |
DMARC Protocol version. |
v=DMARC1 |
p |
Required |
Indicates policy for the email receiver how to handle messages that fail DMARC. |
p=none p=quarantine p=reject |
sp |
Optional |
Like “p” (above) but for subdomains. |
sp=none sp=quarantine sp=reject |
pct |
Optional |
Percentage of messages to which DMARC policy is to be applied |
p=100 |
rua |
Optional |
Indicates where aggregate DMARC reports should be sent to. |
rua=mailto:emailaddress |
ruf |
Optional |
Indicates where Forensic DMARC reports should be sent to. |
ruf=mailto:emailaddress |
fo |
Optional |
Let’s email providers know you want message samples of emails that fail SPF and/or DKIM. 4 Values: 0: Generate a DMARC failure report if all authentication mechanism fails (SPF and DKIM). (Default). 1: Generate a DMARC failure report if any authentication mechanism fails (SPF or DKIM). (Default). d: generate DKIMN failure report for DKIM failures. S: Generate SPF failure report for SPF failures. |
fo:0 fo:1 fo:d fo:s (or multiple) fo:0:1:d:s |
aspf |
Optional |
Strict or relaxed SPF policy. |
aspf=r aspf=s |
adkim |
Optional |
Strict or relaxed DKIM policy. |
adkim=r adkim=s |
rf |
Optional |
Forensic Reporting Format. Set by default. Only 1 option available |
rf=afrf |
ri |
Optional |
Aggregate Reports interval. Value in seconds. Specify the interval between when reports should be sent. Default is 86,400 seconds (24 hours, Minimum Value). |
ri=86400 |
sp |
Optional |
Like “p” (above) but for subdomains. |
sp=none sp=quarantine sp=reject |
What is an SPF Record?
SPF Stands for Sender Policy Framework – It is a TXT record that you add to your Domain DNS.
It is used by all mail providers such as Gmail and Outlook so that they can detect, and block email spoofing and unauthorized mail sent on your Domains behalf.
SPF record allows you to specify one or more IP addresses or domain names that are allowed to send mail on your domain behalf (i.e., mail “from” your domain).
Your SPF record should list exactly all the servers that are authorized to send mail on your domain behalf and should tell the mail service providers how to handle any mail that is not authorized.
For example, if your using Outlook for your Email Provider, then your SPF record would like something like this: "v=spf1 include:spf.protection.outlook.com -all"
The first part, v=spf1 specifies the spf version; the current SPF version is 1. This is required for all spf records. This line should always be added.
The second part include:spf.protection.outlook.com consists of 2 parts
-
The "include:" is called Mechanism
-
The "spf.protection.outlook.com" is called Directive
The last part also consists of 2 parts known as the Qualifier and Directive.
Putting this all together, your SPF record should always look like this.
“v={spf version} {mechanisms}{directive} {qualifiers}all”
We will cover each part in detail, but to give you an idea, what this record is saying that spf.protection.outlook.com is a third-party email vendor and is authorized to send email on our domain behalf. The include part basically copies the SPF record stored inside that url.
The last part is saying all other emails sent not included in our list should fail. Which means the email server provider will report that email as spam.
"v=spf1 include:spf.protection.outlook.com -all"
SPF Record – Qualifiers
So far, we know that your spf record should always look something like this “v=spf1 {mechanisms}{directive} {qualifiers}all”
Your spf record is read right to left.
if an email got sent out using your domain name, you would list all the authorized server IPS that can send emails on your behalf. Otherwise, the last parts tell the Email Service Providers how to handle emails that are not authorized based on the qualifier you use.
There is 4 different types of qualifiers.
The first one is the plus sign. This is the default qualifier. It’s used if you don’t specify a qualifier.
This qualifier means that the email service provider should always accept the email.
I don’t recommend you use this option because you don’t want any unauthorized email using your domain name to be accepted.
The second qualifier is a dash sign. I always recommend you use this qualifier.
This qualifier will tell the email servicer provider to always fail when the email is not a part of your authorized list.
The third qualifier is Tilda. This qualifier tells the email server provider to accept the email but mark it as suspicious. So basically, throw it in the junk folder.
The last qualifier means neither pass nor fail. This qualifier tells the email service provider that your SPF record, says nothing about passing or failing.
I always recommend you use the dash qualifier, to make sure all unauthorized emails are not accepted.
Qualifier | Result Code | Description |
---|---|---|
+ |
Pass |
Default if no qualifier specified. Accept the message. |
- |
Fail |
Server matching IP address is unlikely authorized. Accept the message but mark it as suspicious. |
~ |
SoftFail |
Server matching IP address is unlikely authorized. Accept the message but mark it as suspicious. |
? |
Neutral |
Neither pass nor fail SPF. Accept. The SPF record does not state whether the Server(s) should be accepted/rejected. |
SPF Record – Mechanism
Now the last part in your spf record, is a combination of mechanisms and directives.
This is where you can list as many ip addresses or domain names that you want to authorize.
When an email is sent out on your domain behalf, the email service provider receiving your email will check if the email is authorized by looking in this list.
There is 5 different mechanisms to authorized servers.
You can authorize mail servers by domain name using the letter “a” for the mechanism.
So if you want to authorize any other domain to send email on your domain’s behalf, you would write “a” then colon then your URL name.
The second way you can authorize servers is by another domain MX record. To do that, you write “mx” colon then the domain name where the mx record is stored.
The third way is to authorize by IP4 address or a range of IP4 addresses. This mechanism is straight forward you just write ip4 colon then the ip4 address or range.
The fourth way is to authorize servers by IP6 address or a range of IP6 addresses. Similar to the ip4, you write ip6 colon then the ip6 address or range of ip6 addresses.
The last mechanism you can use is the include. This will basically authorize a third-party email sender.
Mechanism | Directive Applies When |
---|---|
1 |
Authorize mail servers by domain name. Example: autodiscorver.outlook.com |
a |
Authorize mail servers by domain name. Example: autodiscorver.outlook.com |
mx |
Authorize one or more mail servers by another domain MX record. For example, if you use Outlook, Gmail, Amazon SES …, You add a mx record to authorize their servers. 10 inbound-smtp.us-east-1.amazonaws.com |
ip4 |
Authorize mail servers by IPv4 address or a address range. Example: ip4:192.168.0.1 or ip4:192.0.2.0/24 |
ip6 |
Authorize mail servers by IPv6 address or address range. Example: ip6:3FFE:0000:0000:0001:0200:F8FF:FE75:50DF or ip6:2001:db8:1234::/48 |
include |
Authorize 3rd party email senders by domain. Example: include:spf.protection.outlook.com |