Deliverability Blog Post 7: DMARC

Deliverability Blog Post 7: DMARC

A DMARC (Domain-based Message Authentication, Reporting & Conformance) policy and very important terminology in email deliverability, tells the email receivers like Microsoft (Hotmail, Live, Outlook etc), Gmail, Yahoo! and other DMARC Internet Service Providers who adopted DMARC what to do if an email fails the DMARC check. It is the latest and greatest advance in email authentication. But, like SPF (Sender Policy Framework) and DKIM (Domain Keys Identified Mail), it’s sometimes misunderstood. That’s why we’re dedicating the last post of our three-part email authentication series to explaining how it works, and why it matters.

What is it?
DMARC ensures that legitimate email is properly authenticating against established DKIM and SPF standards, and that fraudulent activity appearing to come from domains under the organization’s control (active sending domains, non-sending domains, and defensively registered domains) is blocked. Two key values of DMARC are domain alignment and reporting.

How does it work?

• DMARC’s alignment feature prevents spoofing of the “header from” address by:
• Matching the “header from” domain name with the “envelope from” domain name used during an SPF check, and matching the “header from” domain name with the “d= domain name” in the DKIM signature.

DMARC was aimed at:

• Reducing false negatives.
• Provide authentication reporting.
• Apply sender policies at the receiving end
• Reduce phishing.
• Be scalable.

In order to get started with DMARC, the sending domain needs to have an SPF and DKIM record published. Once the SPF and DKIM records are in place, you can configure DMARC by adding policies to your domain’s TXT records (the same way in which you published your SPF and DKIM records). Your TXT record name should read something similar to _dmarc.universityofemail.com. Please replace the universityofemail.com with your own domain.

As DMARC policies are published as TXT records, it defines what an email receiver should do with non-aligned mail it receives.
A DMARC record’s name when creating a TXT record is “_dmarc” which forms a TXT record such as _dmarc.universityofemail.com or _dmarc.universityofemail.net etc

An external guide/wizard on creating DMARC records: Global Cyber Alliance

Example:
v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@universityofemail.com

In this scenario, the sender defines the policy as such that the receiver outright rejects all non-aligned messages and sends a report about the rejections to a specific email address. If the sender were to use the “quarantine” setting in the policy, it would look like:

v=DMARC1;p=quarantine;pct=100;rua=mailto:postmaster@universityofemail.com

and would request the action to quarantine on the receiving end of the message. In the next example, if a message claims to be from your domain.com and fails DMARC, no action is taken. Instead, these messages will then show up in your daily aggregate report sent to

v=DMARC1; p=none; rua=mailto:postmaster@universityofemail.com

Here is a sample where the message fails DMARC, then quarantines it 5% of the time.

v=DMARC1; p=quarantine; pct=5; rua=mailto:postmaster@universityofemail.com

In this sample, the policy is set to reject the message 100% of the time and send the daily report to the specified address of dmarc@universityofemail.com.

v=DMARC1; p=reject; rua=mailto:postmaster@universityofemail.com, mailto:dmarc@universityofemail.com

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:

Only the v (version) and p (policy) tags are required. Three possible policy settings are available:

none – Take no action. Only log the affected messages in the daily report.
quarantine – Mark affected messages as spam.
reject – Cancel the message at the SMTP layer.

Alignment mode refers to the analysis of which sender records are compared to SPF and DKIM signatures. There are two possible values being presented, relaxed “r” or strict “s”. Relaxed allows for partial matches such as subdomains while strict requires an exact match.
Be sure to include an email address with the optional rua tag to have the daily reports sent to that address.

Example report
The daily reports are sent in XML format. They provide feedback informing you of the sending source IP addresses that have been sending out on your domain’s behalf. This helps in determining which sources are valid or not. As a result, this assists in more effective deployment of your SPF and DKIM records.
Here is an example of a daily aggregate report. The judgement result is shown along with the source IP addresses and the action taken.

<record>
<row>
<source_ip>208.128.154.109</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
</policy_evaluated>
</row>
<identities>
<header_from>universityofemail.com</header_from>
</identities>
<auth_results>
<dkim>
<domain>universityofemail.com</domain>
<result>pass</result>
<human_result></human_result>
</dkim>
<spf>
<domain>universityofemail.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>universityofemail.com</header_from>
</identities>
<auth_results>
<dkim>
<domain>universityofemail.com</domain>
<result>pass</result>
<human_result></human_result>
</dkim>
<spf>
<domain>stefanomail.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>

Here is an example of how to specify the optional size limit argument and set it to 10 MB.
v=DMARC1; p=none; rua=mailto:postmaster@universityofemail.com!10m

Deploy slowly
As the DMARC specification takes into consideration that scaling out the deployment may be challenging for some organizations to do at once, there are a number of built-in methods for “throttling” the DMARC processing so full deployment can be done in increments over time.

The first thing to do is monitor your traffic and reports. Assess where your vulnerabilities are (where messages are being delivered without being digitally signed or are coming from invalid source IP addresses) and address them through SPF and DKIM records.
As you monitor your daily aggregate reports and get to a place where you are comfortable with the results, you can change the action on your policies to start to quarantine. You do this by changing your TXT record using DMARC to use the “quarantine” action. Continue to monitor your daily reports
Once you have been monitoring your traffic and daily reports for some time and feel comfortable with the sources seen sending traffic on behalf of your domain and, they are all being digitally signed, you can move forward with the next step in changing the policy to use the “reject” tag to fully deploy DMARC in its entirety. Monitoring your reports and your spam-feed is an essential part of maintenance for DMARC accuracy.
Also worth noting, the optional pct tag can be used to sample your DMARC deployment in increments as well. Since 100% is the default, passing “pct=20” in your DMARC TXT record results in one-fifth of all messages affected by the policy actually receiving the disposition instead of all of them. This setting is especially useful once you elect to quarantine and reject mail. Start with a lower percent to begin with and increase it every few days.
So a conservative deployment cycle would resemble:

Monitor all.
Quarantine 1%.
Quarantine 5%.
Quarantine 10%.
Quarantine 25%.
Quarantine 50%.
Quarantine all.
Reject 1%.
Reject 5%.
Reject 10%.
Reject 25%.
Reject 50%.
Reject all.

When you are ready to complete the DMARC deployment, remove the percentages from your policies so that the full action of “quarantine” and “reject” is now functioning at 100%. As always, monitor your daily reports.
Recap DMARC deployment.

Deploy SPF and DKIM records for your domain.
Confirm that all sending MTA’s on behalf of the specified domain are aligning the appropriate identifiers appropriately.
Publish DMARC record using the “monitor” flag and specify rua value to receive daily aggregate reports.
Assess vulnerabilities from the daily reports and adjust SPF and DKIM accordingly. Make changes to your mailstreams as needed.
Change DMARC policy flags to “quarantine” and then eventually to “reject” as you see fit.

For further reference, you can go to:
http://dmarc.org/overview.html
http://dmarc.org/specification.html

About the Author

Pankaj Kumar

Pankaj Kumar is a senior professional with 6+ years of experience in CRM - Email marketing analytics | Email Deliverability | Acquisition | Retention | Strategies | Budgeting | Platform and Campaign management | Customer lifecycle and segmentation | SMS | Push | SAS | Google Analytics. He has worked with a broad range of clients to provide strategic, data-driven guidance to increase email delivery, subscriber engagement and revenue. He also helps marketers through this blogs in preparing strategies, data Analytics, deliverability, and CRM with a passion for helping email marketers exceed subscriber expectations. You may connect with him on LinkedIn at https://www.linkedin.com/in/kumarpankaj793/