Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a standard that helps protect email senders and recipients from spoofing, spam and phishing. With this, mail server owners can define a policy related to email authentication practices, which receiving email servers can then use as an instruction set on how to enforce it.
- SPF enables mail server owner to define which IP addresses are allowed to send mail for a specific domain.
- DKIM provides an encryption key (digital signature) that verifies that an email message was not faked or altered.
- DMARC ties the first two protocols (SPF and DKIM authentication mechanisms) into a common framework and allows domain owners to define how they would like email from that domain to be handled if it fails an authorization test.
So, DMARC email validation system is built on top of the two existing mechanisms, it’s not an authentication protocol. For more details checks formal DMARC project page.
DMARC – Domain-based Message Authentication, Reporting & Conformance
DMARC email validation system verifies that the email is being tested against DKIM and SPF correctly, provides a way to define what happen if an email does fail DKIM or SPF checks. An example of DMARC record:
_dmarc.cyberpunk.rs. IN TXT "v=DMARC1\; p=none\; rua=mailto:[email protected]\; ruf=mailto:[email protected]\; pct=100"
p=none: preferred treatment, DMARC policy
rua=mailto:[email protected]: mailbox for aggregate reports
ruf=mailto:[email protected]: mailbox for forensic reports
pct=100: percentage of mail to which domain owner would like to have its policy applied
DMARC also makes some alignment checks, verifying that:
- “header from” domain in SPF matches with “envelope form” domain (From domain and Return-Path).
- “header from” domain matches DKIM singature “d=domain” header.
Alignment can be relaxed or strict:
- relaxed : matching base domains (excluding subdomains)
- strict : matching entire domain
quarantine– will deliver email into the spam folder
reject– full rejection. End user will never see the email
none– only for data collection & monitoring
What is a DMARC report?
DMARC reports are generated by inbound mail servers as part of the DMARC validation process. Two formats:
Aggregate reports, a XML documents (designed to be machine-readable) show statistical info on the messages received that claimed to be from a particular domain. Date reported includes authentication results and message disposition.
Forensic reports, individual copies of messages which failed authentication, each enclosed in a full email message using a special format called AFRF. Forensic report can be useful both for troubleshooting a domain’s own authentication issues and for identifying malicious domains and web sites.
rua: contains an address to which the DMARC aggregate report should be submitted (optional). You can specify web addresses here. Without this, you will not receive DMARC reports.
ruf: address(es) for DMARC forensic reports. These reports contain detailed info on failed DMARC verifications of email claiming to be from your domain.
fo: reporting options for the failure reports. Generate a report if:
- 0: both SPF and DKIM tests failed
- 1: either the SPF or the DKIM test failed
- s: the SPF test failed
- d: the DKIM test failed
adkim: this controls how strict is the interpretation of the DKIM verification (optional). Default: relaxed.
- s: strict
- r: relaxed
aspf: controls how strict the result of the SPF check should be interpreted (optional). Default: relaxed.
- s: strict
- r: relaxed
pct: Specifies how many percent of the messages from your domain should have the DMARC verification done by other email providers (optional). Default: 100.
rf: This fields specify your preferred reporting format for forensic reports (optional). Default: afrf
- afrf: Authentication Failure Reporting Format
- aodef: Accident Object Description Exchange Format
ri: Interval at which you want to receive DMARC reports in seconds (optional). Default: 86400 (one day). Based on DMARC specification, every participating organization should be able to send reports at least once every day. Intervals as small as one hour are within the specification (provided on a best effort basis).
sp: subdomain policy (optional). Used to differentiate policy applied to subdomains. Default behaviour: the policy will apply to your subdomains. If you’re not using subdomains to send mails, you can use this to set reject (subdomain policy).
To check domain’s DMARC record:
nslookup -type=txt _dmarc.<domain>
If you already have SPF and DKIM set, it can’t hurt to include DMARC too. It is also a nice gesture towards fellow admins on receiving end (mail servers).
To work on: