DMARC Email Validation System

CyberPunk System Administration
DMARC Email Validation System

Introductions

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:dmarc-aggreg@cyberpunk.rs\; ruf=mailto:dmarc-afrf@cyberpunk.rs\; pct=100"
  • v=DMARC1 : version
  • p=none : preferred treatment, DMARC policy
  • rua=mailto:dmarc-aggreg@cyberpunk.rs : mailbox for aggregate reports
  • ruf=mailto:dmarc-afrf@cyberpunk.rs : 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

DMARC_stages

Source

DMARC actions:

  • 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.

DMARC Parameters

  • 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.
    • min:0
    • max: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>

Conclusion

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:

DNSEmailMail Server