Product & Solutions
Resources
FREE TOOLS
Website Security Assessment SSL Certificate Checker Domain Expiry Checker HELP AND SUPPORT
Help Center Developer HubCompany
DMARC, stands for “Domain-based Message Authentication, Reporting & Conformance” and it is an email authentication, policy, and reporting protocol. It uses a set of 3 DNS records that work together to ensure that the email is originated from an authorized origin and thereby helping to protect from unauthorized use of a domain.
As you know emails are very easy to spoof. Criminals love it because it’s easy to bait and exploit users by phishing emails when they appear to come from senders you trust, especially from well-known brands.
Simply inserting the logo of a well-known brand into an email makes it appear more legitimate, exponentially increasing the likelihood that someone will click on something they shouldn’t.
In most cases, an end-user may not be able to distinguish between a real message and a fake one, and the mailbox providers have to make very difficult choices about which messages are legit and which ones are fake.
DMARC helps to solve these issues, helping email senders and receivers work together to better secure emails, protecting users and organizations from abuse.
There are 3 components to DMARC security and all are TXT records you need to set up in the specific domain’s DNS:
A DKIM record- this record helps to validate sending domain names associated to email messages through cryptographic authentication. This is achieved by inserting a digital signature into the email message header and later verified by the receiving mail server to validate the legitimacy of the sending domain.
A SPF record- this DNS record defines which all email servers are authorized to send mail on behalf of a domain.
A DMARC record- this DNS record checks to ensure both SPF and DKIM pass before delivering messages to their intended recipients, according to a policy that we enforce.
If you take a look at the above image, you’ll get a better understanding of how DMARC works for real.
First it checks whether the DKIM is a match
Then it checks the SPF record to ensure that the message is sent from an authorized server
Under the restrictive and most ideal policy setting (p=reject), when both DKIM and SPF pass these checks, DMARC delivers the message to the intended recipient. If one or more of these tests fail when a less restrictive policy is set, DMARC behaves accordingly (p=none or quarantine), which render using DMARC somewhat pointless
The goal is to get to a policy that denies anything that’s not up to snuff. Doing so, however, without interrupting the legitimate email delivery takes time and intention.
Let’s take a look into the step-by-step process of setting up DMARC Security. We can start from the SPF record.
SPF stands for Sender Policy Framework. SPF is set up as a TXT record in the domain’s DNS. An SPF record tells which email servers are authentic and permitted to send emails on behalf of a specific domain.
SPF works by publishing a “reverse MX” record for checking the same. When receiving an email, the receiver’s mail server can check those records to verify that the mail is coming from a legitimate origin.
Publishing a “reverse MX” or SPF record is no big deal, just one line in the DNS is all it takes to enable a SPF record for the domain.
Login to the domain’s DNS host.
Choose to edit the primary zone for the Top-Level-Domain (i.e. example.com)
Create a new DNS TXT record for SPF using the following conventions
Here are some credible SPF records you can copy and paste into a new TXT record:
Office 365: v=spf1 include:spf.protection.outlook.com -all
The hard fail variable above (-all) is recommended for fully-hosted Office 365 clients.
GSuite: v=spf1 include:_spf.google.com ~all
Zoho: v=spf1 include:zoho.in ~all
The soft fail variable above (~all) is recommended to ensure all mail is delivered.
If you have multiple servers that you use to send email, you’ll need to include that information in your SPF record.
You need to consider the character limitations of DNS entries while constructing SPF records, which means that you need to make the SPF records as concise as you can.
In case of IP addresses you can use CIDR notation to specify the IP address ranges.
For example:
Here’s an example of IP address ranges that can be specified with CIDR
v=spf1 a mx ip4:192.168.0.0/24 ip4:192.168.1.0/24 -all
Which means:
ip4:192.168.0.0/24 = 256 IP addresses; range: 192.168.0.0 – 192.168.0.255
ip4:192.168.1.0/24 = 256 IP addresses; range: 192.168.1.0 – 192.168.1.255
Considering a larger organization, the best way to reduce the number of characters in an SPF record is to create an SPF specific subdomain represented as: _spf.example.com. Using “_spf” as the subdomain instructs a mail server to treat the subdomain as a storage container, which is only used for listing additional SPF information.
Google is a huge organization and has a lot of IP addresses represented in different netblocks due to the size and scope of the organization. Placing all this information into one SPF record would easily exceed the DNS character boundaries.
They resolved it by creating smaller storage containers of SPF records with IP addresses that are shorter and combined them together using include statements.
Here’s a list of netblocks that Google uses and the corresponding SPF records:
_netblocks.google.com v=spf1 ip4:64.18.0.0/20 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:207.126.144.0/20 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all
_netblocks2.google.com v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all
_netblocks3.google.com v=spf1 ip4:172.217.0.0/19 ~all
In order to keep the SPF record short, they created an SPF specific subdomain of _spf.google.com and references each netblock using an include statement. The include statement tells a mail provider to search for additional SPF information for the domain listed.
Then it’s added to their SPF specific subdomain _spf.google.com with an include statement to the google.com SPF record.
And the final outcome is a simple SPF record for google.com that’s simple and short.
Before you create SPF specific subdomains, though, let’s try to use better CIDR notation for IP ranges in order to reduce the length of our SPF records. That’s the more straightforward way.
DKIM stands for DomainKeys Identified Mail. It is also set up as a new TXT record in the domain’s DNS. Basically it is an encryption tool that allows senders to digitally sign email to help keep them private.
DKIM uses a public key or asymmetric-key encryption, which is a commonly used method, where the private key is kept secret and the public key is made public for verifying authenticity.
The public key is stored at the DNS server (TXT record), which is used by the mail server to generate the signature.
After receiving the email, the receiving mail server can verify the DKIM signature by verifying it against the public key on the DNS server. The receiving mail server uses the key to decrypt the message’s header and also perform some calculations to ensure the message is authentic.
If everything is good, the mail server can presume the message originated from a legitimate and authorized mail server and is safe for delivery.
Depending on the mail service provider you’re using, there are specific unique steps for each of them.Let’s look at the example of setting up DKIM using Google Gsuite.
The comprehensive steps for setting up DKIM in Google’s G Suite is listed here.
The general steps are:
Sign in to your Google Admin Console.
From Admin console navigate to Apps -> G Suite -> Gmail -> Authenticate email
Select the domain that you want to configure DKIM.
Click of Generate new record
Select the key length based on the registrars support. If your registrar support 2048-bit key we recommend using them.
If your domain already uses a DKIM domain key that uses google as the selector prefix, you must change the default selector prefix. The default selector prefix for the Gmail domain key is google. Change the prefix only if your domain already uses a DKIM domain key with the selector prefix google.
Click Generate. Now you’ll be displayed with information you use to update the DNS record.
Add the domain key to DNS records:
Sign in to the management console for the domain’s DNS.
Create a new TXT record using the generated information from Google admin console.
Save your changes!
Alright now we have completed setting up SPF and DKIM records. Now we can move on to setting up the DMARC records.
A simple, generic DMARC record to start with will look like this
v=DMARC1; p=none; rua=mailto:admin@example.com
In the above example we used 3 parameters v,p,rua they are the most commonly used DMARC tags. So what are they?
The v and p are required to create a valid DMARC record whereas all the other tags are optional.
v stands for version and is always set to DMARC1 as this is the current version of DMARC in use. p is for policy and can be set to one of the following three values:
none: least restrictive; doesn’t impose any actions whether or not a message passes SPF and DKIM checks (we will be using this at initial set up of DMARC).
quarantine: Flags messages that fail SPF and/or DKIM checks to be directed to the recipients’ spam or junk folders.
reject: outright refuses messages that fail SPF and/or DKIM checks (this is the end goal of a good DMARC configuration).
rua stands for Reporting Uniform Resource Identifier (URI) for Aggregate reports. It’s not required for a valid record. This is where you set the email address where you want the DMARC reports delivered. These reports help us to understand more about how DMARC is working, what sorts of messages are being blocked, the reason why, etc.
We can follow a 3-phased approach to fine tune the DMARC email security configuration. Here we include some example DMARC TXT records using the common tags that we can modify as our process progresses. We start with an initial DMARC configuration that uses the policy setting as “none”, then moving to a restrictive policy setting of ‘quarantine’, and then onto the goal of a policy set to ‘reject’ all illegitimate messages.
During the initial phase of introducing DMARC email security to our DNS record we don’t implement any actions. It’s for just testing the DMARC and we do not intend to interrupt the flow of legitimate mail flow.
With that in mind, we can start with a policy that is least restrictive, meaning it won’t interfere with normal mail delivery.
This is a good choice for the first two or three weeks and it ensures that the legitimate emails are flowing and being delivered as it should be. This record will take no action on messages that appear to be from our example.com but don’t pass DMARC email security checks.
`v=DMARC1; p=none; rua=mailto:admin@example.com`
Through the second phase we’ll change the policy tag value to “quarantine” to send illegitimate messages to spam/junk folders, though making our policy to be somewhat restrictive in action. In order to make our policy restrictive in nature, we need to change the p tag’s value to “quarantine”.
Along with the new value we also introduce the pct tag, which stands for percentage, that allows us to set a value that tells DMARC to sample that much of the total flagged traffic (messages that fail SPF and/or DKIM checks) for analysis. Typically, a good value for pct is 1, initially.
`v=DMARC1; p=quarantine; pct=1; rua=mailto:admin@example.com`
The pct tag can be set to a value from 1 to 100.
In the final phase we’ll change the policy tag value to “reject” to block illegitimate messages.
`v=DMARC1; p=reject pct=1; rua=mailto:admin@example.com`
We’ll start by setting the pct tag at 1 and gradually increase it as we go. Once we’re 100% certain, we’ll then use this type of record and reject 100% of the messages that don’t pass DMARC checks.
Sign in to the management console for the domain’s DNS.
Create a new TXT record:
Name: _dmarc
Value: DARC record which created
You can analyse the reports being delivered to the email id which is provided at rua. These reports are important in helping us understand if our DMARC configuration is set up well or not. You can use these reports to:
By following the above mentioned steps you’ll be able to configure DMARC for your domain and thereby make sure email security is addressed correctly. If you have any further questions regarding DMARC email security, feel free to leave us a comment below. We’ll be happy to help you out.
