01 Aug

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.

Actually, DMARC system is used to build a collaborating system of senders and receivers to improve mail authentication practices of senders and enable receivers to reject unauthenticated messages.

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.

It is important to note that DMARC builds upon both the DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF) specifications that are currently being developed within the IETF.

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:

“v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@expertpk.com”

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 NamePurposeSample
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.

  1. Deploy DKIM & SPF. You have to cover the basics, first.
  2. Ensure that your mailers are correctly aligning the appropriate identifiers.
  3. Publish a DMARC record with the “none” flag set for the policies, which requests data reports.
  4. Analyze the data and modify your mail streams as appropriate.
  5. 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
Share this

Leave a reply