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.
Okay, so why is everyone using DMARC. What is it?
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:
Sender Policy Framework (SPF) - How it works
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:
“v=spf1 ip4:123.123.123.123 include:spf.ezhostingserver.com a mx -all”
In the example above, the following server IPs are allowed to send mail on behalf of a domain:
- The IPv4 Address of 123.123.123.123.
- Any of our shared mail server IP ranges (via the include:spf.ezhostingserver.com).
- The IP that the domains A record resolves to.
- The IP that the domains MX records resolves to.
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.
DomainKeys Identified Mail (DKIM) - How it works
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
Signing:
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:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=servermanagementco.com; s=default; h=content-type:mime-version:message-id:reply-to:date:subject:to:from; bh=Xn/5OltmP4s/jyp9pH9Uqf8CkQz32ttdic6YY2QxVHs=; b=oTwyDYIGXq3qTZkI+nOwI04AJF4vNlI/Fb+GzxFEj0o+asbxaGcaeLl0mtaRy0IIO
wwg0I/aTPF0iuEsMQ8n46K/xiw7r+xTbeGjSqLALk3mJhtNUPt61CvCGNBw6i3edy
cn7ZBpvXodZTL7NASURpetVzYFsbTRtjOCwaZTeSQ=
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:
b = The actual digital signature of the contents (header and body)
bh = Body Hash
d = Signing Domain
s = Selector
v = Version
a = Signing algorithm
c = Canonicalization algorithm for header and body
q = The default query method
l = Length of the canonicalized part of the body that has been signed
t = Timestamp
x = Expiry time
h = List of signed header fields, this is repeated for fields that occur multiple times
Verifying
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:
default._domainKey.servermanagementco.com
The query result should look something like this, if valid:
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC5iu6t90xQLVPkDDO2DbSicSDYFtJReBlM/y99Bop1SKLGECQLW/lq5Gy5nQ9FAaYbpLk6Urb/qmgHzTfoP2IbEzJ7R4hQo440vHyjCDdAFqcM/ZkDJ3tEheaNjBCEWX+71TJZbUXfWBYKnxuTgAral4218BModt1goY/EdFK+xwIDAQAB
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.
Domain Message Authentication, Reporting & Conformance (DMARC) - 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:
- Reject - If SPF/DKIM checks fail then the message will be deleted as spam.
- Quarantine - If SPF/DKIM checks fail then the message will be sent to Junk/Spam folders.
-
None - If SPF/DKIM checks fail then allow the message anyways.
Note: The mail server performing the checks may still flag emails as spam regardless of the settings used depending on its configuration. Some mail servers respect DMARC, while some have additional actions taken on emails that fail SPF and/or DKIM checks.
To show the different configurable options for DMARC, let’s show an example of a DMARC TXT record below:
v=DMARC1;p=reject;pct=100;rua=mailto:[email protected]
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:
| Tag Name | Purpose | Example |
|---|---|---|
| V | Protocol version. | v=DMARC1 |
| pct | Percentage of messages to be filtered (emailed reports). | pct=20 |
| ruf | Address forensic reports get sent to. | example@example.com |
| rua | Address aggregate reports get sent to. | example@example.com |
| p | Policy for the domain. | quarantine |
| sp | Policy for sub-domains. | reject |
| adkim | Alignment for DKIM (r=relaxed, s=strict). | r |
| aspf | Alignment for SPF (r=relaxed, s=strict). | r |
Aggregate/Forensic Reporting
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:
v=DMARC1; p=quarantine
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).
A great practice is setting your DMARC policy to None for 24-48 hours after enabling the policy. This should allow you to receive the DMARC failure reports within this time period to see if you need to modify your SPF/DKIM records to include any additional mail servers your domain might be sending from.
As an example, we recommended this approach to a client and after 48 hours they realized they did not include MailChimp to their SPF, nor did they enable DKIM for this MailChimp service. If the policy was set to Reject or Quarantine then their mail may have not arrived at their intended recipients that were sent from the MailChimp service.
Setting up your domain with SPF, DKIM, and DMARC
If you have not yet read what the DMARC policy is, or how SPF and DKIM play a huge part in it, then we recommend reading the above sections before proceeding.
See the below steps for instructions on enabling these records:
Step 1: Enabling SPF for your domain.
If managing DNS via WCP:
- Login to your WCP control panel.
- Click on the option for DNS Manager.
- If you do not already have an SPF record, then click the Add Record button.
- For the record name leave the field blank (so the record is for domain root).
- For the record type choose “TXT” (create another with SPF type for legacy if desired).
- For the data field enter in the desired record (example provided earlier in guide).
If managing DNS via cPanel:
- Login to your cPanel.
- Click on the option for Email Deliverability (Under the Email section).
- Click on Manage next to the domain in question.
- Scroll down to the section for SPF and you can customize your record.
In cPanel, a suggested record will be made available. You can customize the record to your needs, but be sure to save the record for it to take effect.
Step 2: Enabling DKIM for your domain.
If using SmarterMail via WCP:
- Login to your WCP control panel.
- Click on the option for Advanced (Under the Email section).
- Click on the tab for Domain Keys.
- Click the button for Enable DKIM.
The WCP control panel will interact with the SmarterMail server the domain is attached to and enables DKIM signing within the mail server settings for the domain. In addition, WCP will automatically create the public DKIM record for you.
If you manage your DNS elsewhere, then copy the text in the field next to Current Domain Key and create a TXT record for _default.your-domain.com and for the record data enter this key value.
If using email via cPanel:
- Login to your cPanel.
- Click on the option for Email Deliverability (Under the Email section).
- Click on Manage next to the domain in question.
- Scroll down to the section for DKIM and you can click the Enable button to activate DKIM.
If you have your DNS managed elsewhere (not within the local cPanel server), then it will provide you with the DNS TXT record to create. You will want to ensure the DNS record name and value are inserted with the exact information that cPanel provides in order for this to work.
If using external SMTP services (such as MailChimp, GSuite, etc.):
-
Login to your dashboard for the service in question. Most mail delivery services will provide the necessary DKIM record needed for your mail to be signed by their services. You will add the record they provide to the DNS zone for your domain.
-
If you are unable to find the DKIM record needed, then you will most likely need to contact their support in order to obtain the necessary records for your domains DNS.
Step 3: Enabling DMARC for your domain.
Prior to adding DMARC:
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.
If managing DNS via WCP:
- Login to your WCP control panel.
- Click on the option for DNS Manager.
- If you do not already have a DMARC record, then click the Add Record button.
- For the record name leave the field blank ( so the record is for domain root ).
- For the record type choose “TXT”.
- For the data field enter in the desired record.
If managing DNS via cPanel:
- Login to your cPanel.
- Click on the option for Zone Editor ( Under the Domains section ).
- Click on Manage next to the domain in question.
- Click on the drop-down next to Add Record and choose Add DMARC Record.
- You can now choose the optional parameters and the policy type (Quarantine, Reject, or None). You can also click on the Raw tab and enter the record manually instead of using the GUI.