DMARC is an email validation system that allows receiving mail exchangers to check if incoming mail from a domain is authorized by the domain's administrators and has not been modified during transport. It was developed by a group of organizations in 2011 to address fraudulent email on a large scale. DMARC policies published in DNS dictate what receivers should do with emails that fail DMARC alignment checks, such as passing both SPF and DKIM authentication as well as having the "From" domain match the authenticating domain. Receivers also send daily reports to senders indicating how many emails passed or failed SPF, DKIM, and alignment checks.

1. Domain-based Message Authentication, Reporting and
Conformance (DMARC)
Is an email validation system designed to detect email spoofing by providing a
mechanism to allow receiving mail exchangers to check that incoming mail from a
domain is authorized by that domain's administrators and that the email (including
attachments) has not been modified during transport.
A group of leading organizations came together in the spring of 2011 to work together
on a technique for fraudulent email at Internet-scale, based on practical experience
with DKIM and SPF. They aimed to empower senders to publish easily discoverable
strategies on unauthenticated email - and to empower recipients to provide
authentication reporting to senders to enhance and monitor their authentication
infrastructures.
A DMARC policy permits a sender's domain to indicate that their emails are secured
by SPF and/or DKIM, and advises a receiver what to do if neither of those
authentication strategies passes -, for example, junk or reject the message.
DMARC remove guesswork from the receivers handling of these fizzled messages,
constraining or eliminating the user's exposure to conceivably deceitful & harmful
messages.
DMARC is designed to fit into an organization's existing inbound email
authentication process. Beneficiary to report back to the sender's area about messages
that pass and/or fizzle DMARC assessment.
DMARC is intended to fit into an organization's existing inbound email
authentication process. The way it works is to help email receivers determine whether
the authentication message adjusts to what the receiver knows about the sender. If not,
DMARC includes guidance on the most proficient method to handle the "non-
aligned" messages.
DMARC doesn't directly address whether or not an email is spam or otherwise
deceitful, DMARC requires that a message pass DKIM or SPF approval, as well as
passes arrangement. For SPF, the message must PASS the SPF check, and the domain
in the From: header must match the domain used to approve SPF (should precisely
match for strict alignment, or must be a sub-domain for relaxed alignment).
For DKIM, the message must be validly signed and the d= domain of the valid
signature must adjust to the domain in the From: header (should precisely coordinate
for strict alignment). Under DMARC a message can fall flat regardless of the fact that
it passes SPF or DKIM, but fails alignment.
DMARC policies are published in the public Domain Name System (DNS) as text
(TXT) resource records (RR) and declare what an email beneficiary ought to do with
non-aligned mail it receives.

2. To ensure the sender trusts this procedure and knows the impact of publishing a
policy different than as p=none (monitor mode), the receiver sends daily aggregate
reports indicating to the sender how many emails have been received and if these
emails passed SPF and/or DKIM and were aligned.
DMARC might positively affect deliverability for legitimate senders; at least Google
recommends the use of DMARC for bulk email senders.
DNS support
Setting up DMARC on a domain requires creation of sub-domains beginning with an
underscore. Some DNS providers, however, such as, 1&1, don't allow the creation of
sub-domains starting with an underscore. Additionally, some registrars, such as,
Network Solutions, don't bolster underscores in cname records, which prevents the
workaround by employing CNAME redirection