DMARC – The Complete Reference
DMARC is a reporting protocol for email authentication. It stands for Domain-based Message Authentication, Reporting & Conformance. DMARC uses the Sender Policy Framework (SPF) and Domain Keys Identified Mail (DKIM) to check email authentication.
In this blog, you’ll learn in detail about DMARC, its importance and how it works as a technical standard for an organization; a policy published to define best email practices and the required steps for receiving mail servers for enforcing the published policies accurately.
Importance of DMARC for a domain owner.
DMARC record helps a domain owner in the following ways:
- Protection from Email Spoofing, phishing, and brand abuse by preventing domain impersonification.
- When properly configured, DMARC lays down the steps for the receiving servers to make DMARC checks for SPF and DKIM authentication and the subsequent actions to be taken in case of authentication failures.
- Policies applied to messages that fail authentication include reports, quarantine and rejects.
- A great enhancement in email sender reputation.
What does a DMARC record look like?
You can find out the DMARC record at DMARC Inspector.
It gives you the above DMARC record.
Let’s break it down into the components so as to have a better understanding.
|p||none||Policy to apply to email that fails the DMARC check. It can be “none”, “quarantine”, or “reject”. “none” is used to collect feedback and gain visibility into email streams without impacting existing flows.|
|rua||mailto:firstname.lastname@example.org||The list of URIs for receivers to send XML feedback to. NOTE: this is not a list of email addresses, as DMARC requires a list of URIs of the form “mailto:email@example.com”. External destination verification is tested if applicable (Know More)|
Implicit Tags defaults if not declared
|adkim||r||Specifies “Alignment Mode” for DKIM signatures. “r” is for Relaxed, “s” is for Strict. Relaxed mode allows Authenticated DKIM d= domains that share a common Organizational Domain with an email’s header-From: domain to pass the DMARC check. Strict mode requires exact matching between the DKIM d= domain and an email’s header-From: domain.|
|aspf||r||Specifies “Alignment Mode” for SPF. “r” is for Relaxed, “s” is for Strict. Relaxed mode allows SPF Authenticated domains that share a common Organizational Domain with an email’s header-From: domain to pass the DMARC check. Strict mode requires exact matching between the SPF domain and an email’s header-From: domain.|
|sp||p= value||Policy to apply to email from a sub-domain of this DMARC record that fails the DMARC check. This tag allows domain owners to explicitly publish a “wildcard” sub-domain policy.|
|fo||0||Forensic reporting options. Possible values: “0” to generate reports if all underlying authentication mechanisms fail to produce a DMARC pass result, “1” to generate reports if any mechanisms fail, “d” to generate a report if DKIM signature failed to verify, “s” if SPF failed.|
|ruf||none||The list of URIs for receivers to send Forensic reports to. NOTE: this is not a list of email addresses, as DMARC requires a list of URIs of the form “mailto:firstname.lastname@example.org”.|
|rf||afrf||The reporting format for individual Forensic reports. It can be either “afrf” or “iodef”.|
|pct||100||The percentage tag tells receivers to only apply policy against email that fails the DMARC check X amount of the time. For example, “pct=25” tells receivers to apply the “p=” policy 25% of the time against email that fails the DMARC check. NOTE: you must have a policy of “quarantine” or “reject” for the percentage tag to do anything.|
|ri||86400||The reporting interval for how often you’d like to receive aggregate XML reports. You’ll likely receive reports once a day regardless of this setting.|
No DMARC record found? Here’s the solution.
Below is the list of popular DMARC record generators available on the web.
- MXToolbox DMARC record generator
- DMARCAnalyzer DMARC record generator
- DMARCian DMARC record generator.
DMARC explained – how it works?
DMARC makes use of SPF and DKIM standards for email authentication. Domain Name System (DNS) is essentially bonded with DMARC. Simply, DMARC has the following working process.
- A domain admin establishes the policy defining its email authentication and other best email practices and how receiving mail servers should respond to any mail that violates this system. The published DMARC policy is hence available in the DNS records of the registered domain.
- Now, when the receiving mail server interacts with an inbound email, it peeks into DNS to check the DMARC policy for the specific domain enclosed in the email’s “FROM” (RFC 5322) header. The inbound server then examines the message for three key determinants:
- Is the email’s DKIM signature valid?
- Did the message come from IP addresses listed and approved by the sending domain’s SPF records?
- Do the headers in the email message exhibit the right “domain alignment”?
Using this data, the receiving server is set to apply the sending domain’s DMARC policy to determine whether to accept, reject, or otherwise flag the email message.
DMARC policy to determine the proper disposition for the email message, the receiving mail server will notify the upshot to the sending domain owner.
In case you are going to sign up for Pepipost Email Delivery Service, you must read this blog to add and verify your domain.
What is Domain Alignment?
It is imperative to know the concept of ‘Domain Alignment’ so as to develop a better understanding of DMARC. “Domain alignment” is a concept in DMARC that expands the domain validation central to SPF and DKIM.
DMARC domain alignment equals a message’s “from” domain with data relevant to these standards:
- For DMARC SPF, the message’s From domain and its Return-Path domain must match
- For DMARC DKIM, the message’s From domain and its DKIM d= domain must match
Domain alignment can be pretty loose (matching base domains, but conceding different subdomains) or strict (precisely matching the entire domain).
What is there in a DMARC Report?
During the DMARC validation process, two kinds of reports are generated by the inbound mail server.
- Aggregate or Consolidated DMARC report, which documents in XML format shows analytical and statistical data about the email messages received that claimed to be from a distinct domain. The date reported incorporates authentication results and message distribution. These reports are intended to be machine-readable.
- Forensic DMARC report, which are unique copies of email messages which failed the authentication standards, each embedded in a full email message using a format called AFRF. The forensic report can be beneficial both for troubleshooting a domain’s own DMARC authentication issues and for recognizing malicious domains and web sites.
Gmail DMARC policy update
A couple of months ago, we had posted an article about Gmail’s Red Lock policy, which was mostly around email data security. This time, it is about Gmail’s upcoming DMARC policy, about which you might have heard already. As an ESP, we like to keep you updated with the new changes coming up in the industry, and also brace you for the emerging trends.
Gmail’s new DMARC policy will not affect the day to day email sending for most senders. It will have an impact on the ones who use @gmail.com and not their corporate domain, as their sender email address. Such senders will have to make major changes to avoid serious interruption in email delivery.
Either way, it’s worth understanding exactly what changes are being made and what the implications are for the email ecosystem.
What is Gmail’s DMARC policy all about?
From 1st June 2016, Gmail has changed its DMARC policy from p=”none” to p=”reject.” This means, any message sent using @gmail.com in the from/sender address, will have to originate from Gmail’s infrastructure only.
This implies, all messages sent from a @gmail.com address outside the Gmail infrastructure (via an email marketing or transactional email platform) will be rejected by recipients’ inboxes and will not be delivered.
Is it only about Gmail?
No. Yahoo already has this DMARC policy in place, and since Mar 28, 2016, they have expanded the same to their lower-volume Yahoo international domains below:
This means, along with @yahoo.com, any email message using any of the above domains as the ‘from’ address, which is not sent from Yahoo’s infrastructure, is most likely filtered or is blocked completely.
Are my emails affected because of this change?
If you have any mail stream that sends emails using @gmail.com in the ‘from’ address, you will have to make changes immediately, because, from 1st June 2016 onwards, Gmail stopped allowing the delivery of such emails. There is a big chance of having those messages filtered, or blocked outright by Gmail Anti-spam filters.
If you send emails using your own domain, or any domain that you control, you have nothing to worry about.
There are many applications, portals and social websites that send messages using their users’ email addresses that can be @gmail.com, @yahoo.com, etc. If their email address happens to be a @gmail.com or any of the yahoo addresses, those messages will no longer be delivered.
What is the solution then?
A good workaround is this: Instead of using users’ @gmail.com email address as the ‘from’ address, use their name in the from/sender name.
A “Sender Name” is when you use a name to appear as the ‘from/sender’ address, instead of the email address.
For instance, email@example.com can be sent as “User’s First Name” <firstname.lastname@example.org>
By adopting this alternative, you are not violating Gmail’s DMARC policy, while your recipients still recognize the individual who sent the email.
What do our experts say about this trend?
Over the last few years, Gmail has been improving its algorithms to improve the way a user peruses an email or a mailbox. Off late, Gmail has begun adopting stricter policies to control spam.
Ideally, a mailbox should not be considered a dump to drop any email – irrespective of the need or use the recipient. Entry into a mailbox should be completely permission-based, such that no one can enter without permission.
For a Mail Service Provider (MSP), it is quite impossible to validate whether the user subscribed for an email or not. Hence, MSP’s are working on complex algorithms to identify the emails that are being read and the engagement rate.
Based on the engagement metrics, the reputation of a sender domain is built and the priority/categorization of an email is decided.
While every other sender and ESP is fighting to get the best of the shared or dedicated IP for the delivery of their emails, our research says that:
“Over a period of time, the importance of IP reputation will slowly fade away, and domain reputation will gradually acquire more weightage. In near future, all email anti-spams will start measuring the sender domain reputation to decide what to do with an email.”
All global MSPs are joining hands to achieve the collective goal of cleaning the spam-ridden email eco-system. And, we here at Pepipost, are proud to be a part of this global movement. With our unique philosophy and unique pricing model, we strive to provide the best of services will keeping pace with the newest trends in the industry.
Also, for more information on our cloud-based e-mail delivery platform, shoot us at email@example.com