DMARC – Domain-based Message Authentication, Reporting and Conformance
DMARC
Domain-based Message Authentication, Reporting and Conformance (DMARC)
Unsolicited or undesired electronic messages or in simple words, spam emails can be irritating as well as very dangerous to end users. Most of the email spam messages are commercial in nature, but may also contain links lead to phishing websites or sites that are hosting malware. Spam email may also include malware as scripts or other executable file attachments.
DMARC is an email-validation system. It was designed to detect and prevent email spoofing. It is intended to combat certain techniques such as emails with forged sender addresses that appear to originate from legitimate senders.
DMARC is built on top of two existing mechanisms. One of them is SPF (Sender Policy Framework) 2nd one is DKIM (DomainKeys Identified Mail. It is designed to allow the owner of a domain to publish a policy (DKIM, SPF or both), it will let the receiver know that how to deal with failures. Additionally, it provides a reporting mechanism of actions performed under those policies. It thus coordinates the results of DKIM and SPF and specifies under which circumstances the From: header field, which is often visible to end users, should be considered legitimate.
I am text block. Click edit button to change this text. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
Email Authentication Process (DMARC)
The basic working principle is to help email receivers determine if the message “aligns” with what the receiver knows about the sender. If not, DMARC includes guidance on how to handle the “non-aligned” messages. For example, assuming that a receiver deploys SPF and DKIM, plus its own spam filters, the flow may look something like this:
User Compose a message > Send it to receiver > Sending Server include DKIM header along with this email > Email sent to receiver > Receiver receive inbound email request > receiver system begins standard validation test > Retrieve verified DKIM domains > Retrieve “Envelop From” from SPF > Apply DMARC Policy eg: Passed, Quarantine, Reject.
At a high level, DMARC is designed to confirm the following things:
- Minimize false positives.
- Provide robust authentication reporting.
- Assert sender policy at receivers.
- Reduce successful phishing delivery.
- Work at Internet scale.
- Minimize complexity.
DMARC is designed to replace ADSP by adding support for:
- wildcarding or subdomain policies.
- non-existent subdomains.
- slow rollout (e.g. percent experiments).
- SPF
- quarantining mail
Anatomy of a DMARC resource record in the DNS
DMARC policies are published in the DNS as text (TXT) resource records (RR) and announce what an email receiver should do with non-aligned mail it receives.
Here is an example DMARC TXT RR for the domain “mail.expertpk.com” that reads:
In the example above, the sender expects that the receiver should reject all non-aligned messages and send a report, in a specified aggregate format, about the rejections to a specified address. If the sender was testing its configuration, it could replace “reject” with “quarantine” which would tell the receiver they shouldn’t necessarily reject the message, but consider quarantining it.
DMARC records follow the extensible “tag-value” syntax for DNS-based key records defined in DKIM. The following chart illustrates some of the available tags:
Tag Name | Purpose | Sample |
---|---|---|
v | Protocol version | v=DMARC1 |
pct | Percentage of messages subjected to filtering | pct=20 |
ruf | Reporting URI for forensic reports | ruf=mailto:authfail@example.com |
rua | Reporting URI of aggregate reports | rua=mailto:aggrep@example.com |
p | Policy for organizational domain | p=quarantine |
sp | Policy for subdomains of the OD | sp=reject |
adkim | Alignment mode for DKIM | adkim=s |
aspf | Alignment mode for SPF | aspf=r |
5-Easy Steps to Deploy DMARC
Some of the world’s largest email senders and receivers Designed DMARC (PayPal, Yahoo, Gmail etc) and they are deploying SPF and DKIM based on real-world experience.
It is a well-known fact that it is nearly impossible for an organization to flip a switch to production. There are a number of built-in methods for “throttling” the DMARC processing so that all parties can ease in deploy over time.
- Deploy DKIM & SPF. You have to cover the basics, first.
- Ensure that your mailers are correctly aligning the appropriate identifiers.
- Publish a DMARC record with the “none” flag set for the policies, which requests data reports.
- Analyze the data and modify your mail streams as appropriate.
- Modify your DMARC policy flags from “none” to “quarantine” to “reject” as you gain experience.
In my next blog, I will show you practical examples, as well as, I will teach you methods of deploying DMARC via command line, via cPanel, via Virtualmin/Webmin, via Plesk etc.
Note: All data in this post is taken from different sources eg dmarc.org
Faheem Khan