In an attempt to prevent users from receiving spam, a large number of e-mail providers are adding additional content filters and adopting the DMARC Anti-Spam Policy.

A great example of a major email provider that has already adopted this policy is GMail. When you email to a @gmail.com address your emails pass through their spam content filters, which if you do not abide by the correct use of DMARC standards then you might find your email showing up in the user’s spam folder… or worse… never received at all.

There are a large number of other major email providers in addition to Gmail that have also adopted this policy, such as Microsoft (Hotmail, Live, Outlook, etc), Yahoo, AOL, AT&T, and other Internet Service Providers.

With over half of the total emails sent on the web being malicious or of spam content, it has been a struggle for email service providers to stop these emails from affecting their users’ inboxes. Until a few years ago, the majority of spam blocking had been done via custom content filters searching for specific text or strings of text within the body of email messages, or by checking the IP reputation of the sending server sending the email.

While custom content filters and IP reputation checks are still heavily done on most email servers a new form of preventing spam was needed for the growing amount of spam on the internet. This is when SPF and DKIM came into play, which both were designed (separately, and for their own individual purpose) to prove to email servers that their emails are legitimate.

Before diving into DMARC any further, let’s first review exactly what SPF and DKIM are and their intended use case. Click to toggle the below sections for SPF and DKIM respectively:

SPF stands for Sender Policy Framework and is one of the methods used to help e-mail servers determine if an e-mail originating from a domain is spam or legitimate and can help prevent spoofing.

On the internet, there are billions of possible IP Addresses that you could receive mail from. If a domain does not have an SPF record, a spammer could spoof the domain by sending from any server they have access to.

The SPF record allows for us to limit the allowed sending server IP Addresses, so that only IP Addresses we know email will be sent from for a domain are allowed to send on the behalf of the website.

So, if an SPF record exists and a spammer tries to send from a server IP that is not in the allowed IP list for the domain, which is specified in the SPF record, then the SPF check the recipient server performs will fail.

How the recipient server handles SPF check failures is dependent on the configuration of that server, which in most cases will ask the domains DMARC policy (if one is setup) on how to handle the failure.

Shown below is an example of an SPF record:

In the example above, the following server IPs are allowed to send mail on behalf of a domain:

The -all part of the record states that if the server IP sending the mail is not an IP that is provided within this record, then the SPF check should fail.

The actual information you want to use will vary depending on your situation (where your mail is being sent from). The above is just to provide you with several types of ways to add allowed servers to your SPF.

DKIM stands for DomainKeys Identified Mail and, just like SPF records, is another one of the methods used to help e-mail servers determine if an e-mail originating from a domain is spam or legitimate and can help prevent spoofing.

How does it work?

DKIM can be separated into two main parts: signing and verifying

If DKIM is enabled on a domains mail server, then every message that is sent out from that domain will contain a DKIM signature within the header content of the email.

An example of this is as follows:

The above is an example of the DKIM signature within an e-mail header. In this case, the e-mail was signed with DKIM and used several key=value combinations to tell the recipient server information about the DKIM signature.

A list of the valid DKIM key=value arguments are below with their respective definitions:

The DKIM-Signature header field is a list of tag=value parts. Listed below are the tags and their use/meaning:

If the recipient server is set up to perform DKIM checks, then the above-mentioned DKIM signing helps the recipient server process the DKIM to ensure it’s validity.

The recipient server will query the selector used within the DKIM signature in order to gain the public DKIM signature. In the above example of a DKIM signature the selector (controlled by the S= key) was set to ‘default’. So, in this case, the server would query the following TXT record:

The query result should look something like this, if valid:

The signature retrieved by the Selector DNS query will then use this information to decrypt the hash value in the header field while also recalculating the hash value for the email (header and body).

If the two matches, then this proves the originating server is allowed to send an email for the domain.

The above sections (SPF and DKIM - how it works) should have helped give you an understanding of how adding SPF and DKIM records for your domain’s email can help prove your legitimacy to email servers.

We will dive into how to add these SPF and DKIM records momentarily, but let’s first continue on to the next part of the DMARC policy: The DMARC record itself.

Click to toggle the below section regarding DMARC and how it works.

Every domain should have a DMARC record. If not enabled for a domain, then this could hurt the delivery for the domain for some email providers that require DMARC to be set up. The DMARC record tells recipient servers how to proceed with an email that is failing SPF or DKIM checks.

So, a recipient server setup with proper DMARC configuration checks will check an incoming mail against the sending domains SPF and DKIM records. If the email fails one or both of these checks, then it asks the domains DMARC policy how it should proceed with the message. The options are:

To show the different configurable options for DMARC, let’s show an example of a DMARC TXT record below:

In this example, the sender requests that the recipient server rejects all non-aligned messages and send an aggregate report about the rejections to a specified address.

It is recommended to set the policy to quarantine instead of reject when you are first creating the DMARC policy for your domain. We also recommend ensuring that you have SPF and DKIM setup properly so that all servers that your domain sends mail from will abide by your domains DMARC policy.

A full list of configurable options for your domains DMARC can be found below:

The DMARC policy allows for you to specify an email address that you will receive reports of SPF/DKIM failures. This allows you to review the failures to see if you need to modify any of your SPF or DKIM settings, such as a mail server you did not realize that your domain actually sends from.

The PCT= setting allows you to choose the percentage of failures to actually send to your address. Keep in mind that it’s the recipient mail servers that are sending these reports (if you have the option enabled), so you might receive a large number of reports if you have any misconfigurations or a spammer is attempting to spoof your domain.

By default, the DMARC record will tell recipient mail servers to only send reports every 24 hours. You can change this using the ri= flag within your record if necessary.

An aggregate report doesn’t contain any information about the emails themselves. The DMARC aggregate reports contain information about the source that sent the message, the domain that was used to sent these messages, the sending IP, the number of messages sent on a specific date, the DKIM/SPF sending domain, the DKIM/SPF authentication result and the DMARC result

A forensic report contains more detailed information about the emails, which allow you to see specific information such as the subject of emails that are failing the domains DMARC policy. In most cases, only the aggregate reports really need to be enabled, but this depends on the situation and your own preferences.

The option for reporting is completely optional, so we recommend that you enable it initially when first creating your DMARC policy just to be safe. Once you gain complete confidence that every mail server your domain sends mail from is set up properly in order to work with your DMARC policy, then it is safe to remove the reporting functionality from your DMARC record.

If you do wish to disable reporting, then you can go with the most basic record such as below:

Again you can set the policy to ‘none’, ‘quarantine’, or ‘reject’.

SPF/DKIM Alignment

The adkim and aspf attributes in the DMARC record allow you to specify the options for strict or relaxed. The default option is relaxed if not specified in the record.

Relaxed - Allow both the primary domain and sub-domains to send e-mail as long as SPF and DKIM checks pass.

Strict - Only allow the primary domain (such as servermanagementco.com). Do not allow additional sub-domains to send mail (such as email.servermanagementco.com).

If this is your first time adding DMARC for a website (or you just prefer to use this method as we do!), then we recommend using the free DMARC setup wizard provided by dmarcian.

Another option would be signing up for a free account at Dmarc Analyzer and going through their DMARC setup wizard.

Disclosure: Tools such as Dmarc Analyzer have the option to send reports to their system so that you can view the reports in a much easier readable format with graphs and other helpful information. While this is very helpful, please keep in mind that they might be receiving sensitive information from your domain’s email for failed reports. The free setup wizard tool is harmless and will help you in setting up your records, however.