DMARC extends two existing mechanisms, Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). It allows the administrative owner of a domain to publish a policy in their DNS records to specify which mechanism (DKIM, SPF or both) is employed when sending email from that domain; how to check the From: field presented to end users; how the receiver should deal with failures - and a reporting mechanism for actions performed under those policies.
Once the DMARC DNS entry is published, any receiving email server can authenticate the incoming email based on the instructions published by the domain owner within the DNS entry. If the email passes the authentication it will be delivered and can be trusted. If the email fails the check, depending on the instructions held within the DMARC record the email could be delivered, quarantined or rejected.
DMARC doesn't directly address whether or not an email is spam or otherwise fraudulent. Instead, DMARC requires that a message not only pass DKIM or SPF validation, but that it also pass alignment. Under DMARC a message can fail even if it passes SPF or DKIM, but fails alignment.
Domain alignment” is a concept in DMARC that expands the domain validation intrinsic to SPF and DKIM. DMARC domain alignment matches a message’s From: domain with information relevant to these other standards:
The alignment can be relaxed (matching base domains, but allowing different subdomains) or strict (precisely matching the entire domain). This choice is specified in the published DMARC policy of the sending domain.
Strict alignment means that the Return-Path domain or the signing domain "d=" must be an exact match with the domain in the "From:" address.
Relaxed alignment means that the Return-Path domain or the signing domain "d=" can be a subdomain of the "From:" address and vice versa.
MAIL-FROM/RETURN-PATH: email@example.com # SMTP envelope From: firstname.lastname@example.org # email header
In the above example, if DMARC was set to strict SPF mode then an email coming from subdomain.example.com would DMARC fail as the domains do not match exactly ie. they are not aligned. However, in relaxed alignment mode DMARC would pass.
d="example.com" # DKIM in email header From: email@example.com # email header
In the above example, if DMARC was set to strict DKIM mode then an email coming from subdomain.example.com would DMARC fail as the domains do not match exactly ie. they are not aligned. However, in relaxed alignment mode DMARC would pass.
The Overall DMARC LogicIf SPF PASSED and ALIGNED with the "From:" domain = DMARC PASS or if DKIM PASSED and ALIGNED with the "From:" domain = DMARC PASS. If both SPF and DKIM FAILED = DMARC FAIL
DMARC records are published in DNS with a subdomain label _dmarc, for example _dmarc.example.com. The content of the TXT resource record consists of name=value tags, separated by semicolons, similar to SPF and DKIM. For example:
_dmarc.example.com TXT "v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:firstname.lastname@example.org;"
Here, v is the version, p is the policy, sp the subdomain policy, pct is the percent of "bad" emails on which to apply the policy, and rua is the URI to send aggregate reports to. In this example, the entity controlling the example.com DNS domain intends to monitor SPF and/or DKIM failure rates and doesn't expect emails to be sent from subdomains of example.com.
The following chart illustrates some of the available tags:
|pct||Percentage of messages subjected to filtering||pct=20|
|ruf||Reporting URI for forensic reports||ruf=mailto:email@example.com|
|rua||Reporting URI of aggregate reports||rua=mailto:firstname.lastname@example.org|
|p||Policy for organizational domain||p=quarantine|
|sp||Policy for subdomains||sp=reject|
|adkim||Alignment mode for DKIM||adkim=s/adkim=r|
|aspf||Alignment mode for SPF||aspf=r/aspf=s|
sp, the subdomains inherit the policy specifie d in
DMARC is capable of producing two separate types of reports. Aggregate reports are sent to the address specified following the rua. Forensic reports are emailed to the address following the ruf tag. These mail addresses must be specified in URI mailto format (e.g. mailto:email@example.com ). Multiple reporting addresses are valid and must each be in full URI format, separated by a comma.