Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a defined email validation protocol that uses SPF and DKIM to determine the authenticity and identity of email messages. It helps domain admin to detect and prevent email spoofing based on how right the DMARC policy has is implemented. DMARC only acts on when both SPF and DKIM verifications are failed.
DMARC record is also created in your DNS system alongside other DNS records (A records, MX, SPF, DKIM, CNAME etc.) By implemented DMARC policy, sender domain admin tells receiving server whether or not to accept an email from a particular sender source system. Not all the receiving servers perform a DMARC policy check but the majority of ISPs seeking a right DMARC policy.
Advantages of DMARC
Publishing a DMARC policy helps you to prevent your brand from unauthenticated people sending forge, spoofing emails from your sending domain. Also publishing a DMARC record also demonstrate good impression to ISP (Such as Gmail, Yahoo, Hotmail etc) as how concern you are about your sending reputation.
There are two kinds of DMARC reports senders are mostly like to review Aggregator Report and Forensics Report.
Reviewing DMARC reports regularly helps to get visibility into your email program by analyzing who is sending mail from your domain.
How does a DMARC record look like?
You can see what a DMARC record looks like by checking on following links https://mxtoolbox.com/dmarc.aspx / https://dmarcian.com/dmarc-inspector/ or typing “dig txt _dmarc.domain.com from the command line terminal.
Here is an example of DMARC record–this is a sample DMARC record:
Let’s break down each syntax of a DMARC record
“v=DMARC1” This is the identifier string that the receiver’s email system looks when it is scanning the DNS record for the sending domain it received the message from. If the sending domain does not have a txt record in DNS that begins with v=DMARC1, the receiving system will not perform a DMARC check.
“p=none” This part tells the receiving system about what to do with messages that failing DMARC policy. When the policy is set to “none.” This means that the receiving system won’t take any action if a message fails DMARC. However, this information will still be valuable for a sender, because DMARC sends reports that alert to the domain administrator of any DMARC failures.
“p=none” is a recommended first step on the way to implementing a policy that will drop the unauthorized mail. Most people are surprised to find out how many different people/groups/organizations are sending mail (legitimate or otherwise) on behalf of their domain. Other options for the p= field are “quarantine” and “reject.” “Quarantine” will set messages aside for further processing; in most cases, this means it will be sent to the spam folder. “Reject” will stop the messages outright.
“rua=mailto:firstname.lastname@example.org” This part says the receiving system where to send aggregate reports of DMARC failures. These aggregate reports are submitted daily to the domain administrator DMARC record belongs. DMARC report provides high-level information about DMARC failures but do not provide the detailed report about each incident.
“ruf=mailto:email@example.com” This part says the receiving system where to send the forensic reports of DMARC failures. These forensic reports are sent in real time to the domain administrator that the DMARC record belongs. These forensic reports provide details about each individual failure. This email address must be from the domain that the DMARC record is created for.
“rf=afrf” This part says the receiving server what kind of reporting the policyholder wants. rf stands for reporting format. In this case, rf=afrf means aggregate failure reporting format.
“pct=50” This part says the receiving server how much of their mail is subjected to the DMARC policy’s check. In this case, if the p= was set to reject, 50% of the mail that fails DMARC would be rejected.
Other mechanisms can also be included in a DMARC record. A few notable ones include:
“sp=” This part would say the receiving server whether or not to apply the DMARC policy to the subdomain level.
“adkim=” This makes the DKIM alignment. It can either be set to “s” as strict or “r” as relaxed. Strict means the DKIM portion of DMARC authentication will only pass if the d= field in the DKIM signature exactly matches the from the domain. If it is set as relaxed, messages will pass the DKIM portion of the DMARC authentication if the DKIM d= field matches the root domain of the from address.
“ri=” This sets the interval for how often you want to receive aggregate reports of DMARC failures.
A DMARC report will let you investigate email you’re sending out as well as the email from anyone pretending to be you, in other words, if someone is abusing your sending domain name it will become visible in the DMARC reports you receive.