List of content you will read in this article:
DAMRC rule sets are defined in a DMARC record. To understand it more clearly, we must first know what DMARC is and how it is important. DMARC is an abbreviation for Domain-based message authentication, reporting, and conformance and is an email authentication protocol. It is designed to give email domain owners the privilege to safeguard their domain from unauthorized access. A DMARC policy allows a senders domain to indicate that if their emails are protected by SPF or DKIM protocol. If yes, only then are they authenticated. Under DMARC standard messages can fail when it lacks alignment even if it passes SPF or DKIM.
DMARC record informs various internet service providers like Gmail, Yahoo, Microsoft, and alike about your domain setup. DMARC is a DNS TXT record published for a domain to control messages with failed authentication or when the recipient fails to recognize the sender. It tells a receiver to take a dedicated step if emails fail to pass the authentication test. This technical standard protects email senders and recipients from email spoofing, spam, and phishing and establishes a method for the domain owner to publish its email authentication.
Hence the DMARC record contains policy and should be placed right in your email domain. The TXT record name should be "_dmarc.xyz.com," where "xyz.com" represents the name of your domain or subdomain.
Services Offered by DMARC Record
A published DMARC record serves two primary purposes, and these are as follows:
- It tells the receiver server about the action to be taken after receiving a message.
- Sends a report to an email address or addresses with data about all messages that have been seen with the same domain name.
Receiving mail servers like Gmail, Yahoo, and others determine what they have to do with a message based upon a domain that has been published in DMARC. The recipient mail servers may take up one of the following action based on policy set up in DMARC record on receiving the message:
- Quarantine a message: Messages that fail DMARC checks are put into quarantine by putting them into the junk folder.
- Completely reject it: With this policy, the receiver rejects all messages that have failed DMARC checks, and receivers do it on the SMTP level.
- None: The receiver monitors the messages. This policy is used to gather DMARC reports and analyze data in the DMARC reports.
If the domain has not been published a DMARC record, the receiving server determines on its own what action it should take on receiving a message. However, with the increase in phishing attacks, malware threats, and a variety of other security concerns, the failed DMARC has become a golden rule to reject emails to block fraudsters.
DMARC Record Explained
A DMARC record is essentially made up of hostname and tag pairs. Hostname represents the name of the record. For example - dmarc.mxtoolbox.com is the Host/Name for MxToolbox. At the same time, tag pairs have a tag. For example, the policy is represented by "p=" and a value such as "none" paired that tells recipients about desirable action that should be taken. To understand it better, I have come up with a sample DMARC RECORD:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
Here the DMARC RECORD contains three tag pairs viz v- that represents the version of DMARC, p- that represents the action to be taken if the message fails DMARC, & Rua- a tag that represents to send DMARC aggregate reports to and the three (3) values are DMARC1, none, and mailto:dmarc@yourdomain.com.
There is a total of 11 tags policy that can be applied to DMARC. Of those, 11 v and p are required in every domain. I also recommend using rua tags to receive the reports. Below is a complete list of tags that can be added to DMARC policy depending set of your requirements:
- Version (v): The v tag represents the protocol version for example v=DMARC1
- Policy (p): The p tag represents the policy for domain or requested handling policy. This tag directs the receiver to report, quarantine, or reject emails that have failed authentication.
- Percentage (pct): This tag specifies the percentage of email messages that are subjected to filtering; for example, pct=25 means the recipient will filter a quarter of your company's emails.
- RUA Report Email Address(s) (rua): This is an optional tag and is designed for reporting URI(s) for aggregate data, for example, rua=mailto:CUSTOMER@for.example.com.
- RUF Report Email Address(s) (ruf): The ruf tag is optional and directly addresses which message-specific forensic information is to be reported. For example, ruf=mailto:CUSTOMER@for.example.com.
- Forensic Reporting Options (fo): The tag pertains to forensic reports. It tells us about how they are created and presented to DMARC users.
- ASPF Tag (aspf): The aspf tag represents alignment mode for SPF and is an optional tag, for example, aspf=r.
- ADKIM Tag (adkim): The adkim tag is optional and represents the alignment mode for the DKIM protocol, for example, adkim=r.
- Report Format (rf): The DMARC rf tag pertains to the Forensic reporting format.
- Report Interval (ri): The ri tag corresponds to the DMARC feedback for the outlined criteria and pertains to the aggregate reporting interval.
- Subdomain Policy (sp): This tag represents the requested handling policy for various subdomains.
Aim of DMARC
DMARC has been developed to give receivers of email a better suggestion to judge what to do with an email based on sending domain reputations. It acts as a platform where the sender can publish its policies, and the receiver reacts based on the sender's policies. A sender publishes policies to improve effectiveness against spam and phishing and builds its reputation. DMARC provides guidelines for addressing messages and what happens if emails do not follow policies as published by the sending domain. Here is a quick sneak peek at the bullet point to which DMARC aims:
- To reduce false negatives.
- Provide authentication.
- Apply senders' policy at receiving end.
- Reduce phishing.
- Be scalable.
To start with DMARC, the sender's domain needs to have SPF and DKIM records published. Only once they are published can you configure DMARC by adding various policies to the domain's TXT records. The TXT record name will look like "_dmarc.abc_zzz.com." where the "abc_zzz.com" represents your domain.
DMARC policies are published as TXT records, and this is what tells the email receiver what it should do with an email that does not follow policies. DMARC record's name on creating a TXT record is "_dmarc," which forms a TXT record such as _dmarc.mydomain.com _dmarc.mydomain.net and alike.
Let us understand this with an example:
For "v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@dmarcdomain.com"
The sender defines this policy where the receiver outright rejects all messages if it fails guidelines and sends a report about rejection to the specific email address.
For "v=DMARC1;p=quarantine;pct=100;rua=mailto:postmaster@dmarcdomain.com"
The sender defines this quarantine policy and would ask the receiver to quarantine the message at receiving for failing guidelines.
Email addresses with optional rua tags will have daily reports that will be sent to that address in XML format. These reports provide feedback telling you about sending sources IP addresses that have been sent on your domain behalf. This is a key point that lets you know which sender is valid and which is not thus leading to more effective deployed SPF and DKIM records. A common example of a report is:
<record>
<row>
<source_ip>207.126.144.129</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
</policy_evaluated>
</row>
<identities>
<header_from>stefanomail.com</header_from>
</identities>
<auth_results>
<dkim>
<domain>stefanomail.com</domain>
<result>pass</result>
<human_result></human_result>
</dkim>
<spf>
<domain>stefanomail.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
<record>
<row>
<source_ip>207.126.144.131</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<reason>
<type>forwarded</type>
<comment></comment>
</reason>
</policy_evaluated>
</row>
<identities>
<header_from>stefanomail.com</header_from>
</identities>
<auth_results>
<dkim>
<domain>stefanomail.com</domain>
<result>pass</result>
<human_result></human_result>
</dkim>
<spf>
<domain>stefanomail.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
The judgment result is shown with the sender's IP address and judgment made; you can also specify an optional size limit argument.
Note: The guidelines refer to the analysis when sender records are compared to SPF and DKIM signatures with two values, relaxed "r" or strict "s". Relaxing gives you a relaxation to partially match domains, while strict refer requires an exact match.
DMARC Deployment
For those who want to deploy DMARC records, here is a read that gives you a quick idea of getting started with DMARC.
Startup by monitoring your traffic and reports to access vulnerabilities like whether messages being delivered are digitally signed or not are coming from valid source IP addresses. If there are any vulnerabilities found in your email, address them using SPF and DKIM records.
When traffic results are satisfactory, change action on your DMARC policies and use quarantine action by changing the TXT record. Continue monitoring for some time before moving to the next step of changing the policy and using the reject tag to deploy DMARC fully. Monitoring reports and spam feed is an important part of DMARC accuracy. To make it simple, I have summarised the whole process into simple five steps as listed below:
- SPF and DKIM records need to be deployed for your domain.
- Based on the specified domain, make sure that all MTA's are aligned to appropriate identifiers appropriately.
- Publish DMARC record with the use of the "monitor" flag. You can also specify rua value to receive daily aggregate reports.
- From daily reports, you can assess vulnerabilities and adjust SPF and DKIM records as per your assessment. You can also make changes to mail streams as per your need.
- Change DMARC policy as per your need. Please change it to quarantine policy and then eventually reject the policy as you see fit.
How to create DMARC record on cPanel?
In this tutorial, we will learn how to build the DMARC record in cPanel, so you can use this cPanel feature to solve some problems with sending and receiving emails.
The DMARC is a TXT record that is built into DNS, with the help of SPF as well as DKIM to authenticate your emails.
For creating a dmarc record in cPanel, follow the steps below.
- Login to cPanel web hosting control panel
- In the Domain section, click on Zone Editor.
- On the Zone Editor page click on Manage in front of your domain.
- Now click on click on the arrow down next to the +Add Record button and select Add DMARC Record.
- After choosing this option you can set your wanted settings and after that click on Add Record
- After adding DMARC record, you will see it on the current page.
Conclusion
DMARC is a set of three DNS records that flag and reject fraudulent messages. It checks the DKIM record of the domain owner and authenticates whether an address in question matches the server. It checks the SPF record and makes sure the server from where the mail is coming is authorized or not. If both checks are successful, then the mail is delivered. DMARC proves an important line of phishing defence and also hugely impacts the delivery of email marketing campaigns. Setting up records helps the sender to stay outside of the blacklist and build their market reputation.
