DMARC, which stands for “Domain-based Message Authentication, Reporting & Conformance”, is an email authentication, policy and reporting protocol.
DMARC builds upon the widely deployed SPF and DKIM protocols, ensuring that legitimate email is appropriately authenticated. Fraudulent activity, such as phishing and email spam, appearing to come from domains controlled by the organization, is blocked.
Two critical aspects of DMARC are domain alignment and reporting.
Why DMARC?
There are four main reasons to implement DMARC:
- Security: With DMARC you can monitor your email flow for possible threats and unknown senders, and tighten your DMARC policy to prevent spoofing and phishing emails from being sent from your domain.
- Visibility: DMARC will provide you with detailed insight on all emails sent on behalf of your domain.
- Deliverability: Using DMARC technology will help ensure your emails are delivered. Use the same modern plumbing that mega companies use to deliver email.
- Identity: Make your email easy to identify across the huge and growing footprint of DMARC capable receivers.
In other words, DMARC is the first and only widely-used technology able to certify as a reliable header “from” address. This not only helps protect customers and the brand but also discourages cybercriminals who are less likely to be able to deliver illegitimate mail at the expense of the brand.
How does it work?
A DMARC policy allows a sender to indicate that their messages are protected by SPF and/or DKIM and tells the recipient what to do if none of these authentication methods is verified, such as junk mail or denial of the message.
DMARC removes the responsibility of the management of these messages, thus limiting the user’s exposure to potentially fraudulent or malicious messages. DMARC also provides a way for the email receiver (like Italiaonline, Google and Microsoft) to report back to the sender about messages that pass and/or fail DMARC evaluation.
Senders can either:
- Monitoring (p=none), no impact on mail flows.
- Quarantine (p=quarantine) messages that fail DMARC (e.g., move to the spam folder);
- Reject (p=reject) messages that fail DMARC (e.g., don’t deliver the mail at all).
For an email message to be considered DMARC-compliant, the domain found in the “From:” header must match the domain validated by SPF or the source domain found in a valid DKIM signature. If the domains match and at least one of the two mechanisms is valid, receivers can safely say that the email effectively comes from the specified domain.
| DMARC CHECK | FROM: DOMAIN (DMARC) | DKIM DOMAIN (DKIM) | RETURN PATH DOMAIN (SPF) | |
| Fail | DMARC FAIL | @client.net | @sample.net | @sample.net |
| SPF Only | DMARC PASS | @client.net | @sample.net | @client.net |
| DKIM Only | DMARC PASS | @client.net | @client.net | @sample.net |
| Full Allignment | DMARC PASS | @client.net | @client.net | @client.net |
Anatomy of a DMARC resource record in the DNS
DMARC policies are published in the DNS as text (TXT) resource records (RR) and specify what an email receiver should do with non-aligned mail it receives.
Consider an example DMARC TXT RR for the domain “sender.testdomain.com” that reads:
"v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@testdomain.com"
In the above example, the sender requires that the receiver reject all non-aligned messages and sends a report, in a specified aggregate format, to the specified address. If the sender was testing its configuration, it could replace “reject” with “none” to tell the recipient that they did not have to reject the message, but they are still wanted to report the error to him.
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 organisational 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 |
EmailSuccess makes you DMARC complaint
Takes care of email security and authentication aspects, so there is no problem setting up a DMARC record for the domains configured for sending.
As seen previously, DMARC is a technology that does not require changes to the messages sent, one just needs to activate the SPF and DKIM: the important thing is that these are aligned on the domain and on the envelope sender.
This is an example of DMARC strict alignment:
Return-Path: <foe@CLIENT.net>
Delivered-To: friend@example.org
Authentication-Results: mail.example.org; spf=pass (example.org: domain
of foe@sample.net designates 1.2.3.4 as permitted sender)
smtp.mail=foe@client.net; dkim=pass header.i=@client.net
Received: from ..
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=CLIENT.net;
s=february_2014; i=@sample.net; q=dns/txt; h= .. ; bh= .. ; b= ..
Date: Wed, 19 Feb 2014 12:39:06 -0500
From: “Fred“ <foe@CLIENT.net>
To: “Frank Riend” <friend@example.org>
Subject: REMINDER – don’t mess this up, Frank!
Hi, please don’t forget about the meeting. It’s very important!
Your friend,
Fred
SPF
EmailSuccess can automatically verify if your sending domain (Return-Path domain) comply with SPF rules.
To view this information, you can open the SPF Monitor page by going to Monitoring -> SPF.
In the example above, we need to set the DNS record for the SPF on the client.net domain:
client.net. IN TXT "v=spf1 ip4:10.168.0.0/24 include:_spf.testdomain.net a -all"
DKIM
If your messages source is not able to sign your emails with a DKIM signature, EmailSuccess’ advanced features can help you.
Indeed, EmailSuccess can sign the emails that pass through it managing all the requires stages:
- Creating the signature.
- Verify signature. This command checks the configuration as well as remote DNS records for matches with the signature’s private-key.
- Switching signatures. Signatures need to be changed over time: EmailSuccess helps you avoid errors while managing this process.
You can find all information for managing the DKIM signature in the help section Advanced topics -> DKIM.
In the example above, the DKIM record, as with the SPF, is needed on the domain client.net.
Roadmap
Furthermore, in future releases, we will work on the SPF monitoring page, improving information on DKIM and DMARC as well.
Why dmarcian?
EmailSuccess and dmarcian can work together to implement SFP, DKIM and, finally, DMARC protocols.
Since 2012 dmarcian is servicing clients on using DMARC. Dmarcian is a strong advocate of DMARC with a vision of supporting DMARC interoperability across the email ecosystem; brands, senders, receivers and users of email. Dmarcian is the only provider of easy to use self- service tools to support DMARC compliance to senders and receivers. Customers range from banks, top internet properties, marketing agencies, telecoms and commercial enterprises of all sizes. Dmarcian collects DMARC data on about 20.000 companies and organizations and more than 2.000.000 domains.
CEO and founder Tim Draegen is a primary author of the DMARC technical specification and currently one of the chairs of the IETF DMARC working group (https://datatracker.ietf.org/wg/dmarc/charter). Scott Kitterman is one of the primary authors of the SPF technical specification.
Dmarcian is the leading “Full Service” provider of DMARC Services. Key components of the service include:
- Expert consulting and implementation support via a tested Deployment Framework Process;
- DMARC reporting, monitoring and analysis via a web-based portal for received XML reports that focus on ease of use and source identification;
- Post DMARC implementation and advisement support that also includes ongoing best practice policy recommendations.
If you want to know more about DMARC, please contact EmailSuccess or create a 14-day dmarcian trial account at https://dmarcian-eu.com/get-started/.