In order to combat spam and fraudulent email it's become common practice to deploy technologies such as SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) to provide a means for receivers to verify whether a message is from who it claims to be. Unfortunately, these are not foolproof and can still allow fraudulent messages to slip through. There's also no way of knowing what a receiver will do with messages that fail these checks and no way of knowing how effective they are. DMARC (Domain-based Message Authentication, Reporting and Conformance) goes some way towards improving this.

What is DMARC?

DMARC allows domain owners to explicitly define how email messages claiming to be from their domain should be treated if they fail both SPF and DKIM checks, and to request reports of messages received from their domain and their validation results. It also imposes some additional checks such as requiring the "From" header of the message to match the domain used in the SMTP envelope.

Prerequisites

Before implementing DMARC on a domain you must first have enabled SPF and DKIM, and will need to be able to create TXT records in the DNS zone for that domain.

It's advisable that you check that all of your mail servers are capable of passing at least one of SPF or DKIM before continuing to prevent any potential delivery problems.

Enabling DMARC in reporting only mode

The first step to enabling DMARC is to configure it to send you aggregate reports of messages arriving from your domain and their verification results. This can be achieved by adding the following TXT record to your DNS zone for the subdomain "_dmarc" (replacing example.com with your domain):

v=DMARC1;p=none;pct=100;rua=mailto:dmarc@example.com

This can then be checked using the following command on linux:

$ dig TXT _dmarc.example.com

If all is correct, then you should start receiving reports from mail receivers who support DMARC by email to dmarc@example.org (so replace this with an address that you have access to). These will contain a compressed XML file which lists the sending IP addresses of all servers who have sent mail from your domain, along with how the messages checked out under SPF and DKIM.

No directions are given to receivers as to how they should handle mail which fails checks at this point, so deliverability will not be affected.

Tightening restrictions

Once you're happy that all legitimate mail from your domain is passing DMARC, you may wish to tighten the restrictions on who can send mail from it by instructing receivers supporting DMARC to either reject or quarantine messages which fail DMARC. This can break certain uses of email such as mailing lists so be sure that you want to do this before continuing. If you just want to know who's sending mail as you then there's also no requirement to follow this step.

If you'd like receivers to assume a failing message is spam and follow their own internal policy as such, then change the DNS record set earlier to the following:

v=DMARC1;p=quarantine;pct=100;rua=mailto:dmarc@example.com

If you want to be even stricter and instruct receivers to reject a failing message during the SMTP transaction, change it to:

v=DMARC1;p=reject;pct=100;rua=mailto:dmarc@example.com

Notes

It's important to note that this will not stop 100% of fraudulent mail from your domains, but will go a significant way in reducing it. Not all receivers support DMARC but most of the major ISPs and webmail providers do.

I've not gone into how to configure mail servers for DKIM signing or DMARC verification, but may post information on that in the future.