In the past I have looked at, adding Sender Policy Framework (SPF) which looks at the bounce address of an email, I have also looked at SenderID which looks at the FROM address part of the email header, and then there was Domain Keys Identified Mail (DKIM) which signs your emails to confirm that they were indeed sent from an authorised email server (which has a published public key via DNS).
Now the final piece in the email puzzle is DMARC.
What is DMARC?
Very briefly it stands for Domain Message Authorisation Reporting and Conformance.
What does it do?
- Via DNS you (the sender) publish under your domain record an instruction that states whether or not a receiving email server should trust your SPF, SenderID and DKIM. All three are also published under your domain DNS zone. You can say whether or not they should reject or quarantine emails that purport to come from your email server but don’t (or do nothing).
- Receiving information in XML format about how your domain reputation is fairing from a given receiving email server, as and when your users send emails to third parties.
What does the DNS record look like?
It looks like the following;
_dmarc IN TXT "v=DMARC1; p=none; rua=mailto:email@example.com"
OK, so if we break this down a little we have the following components;
- “_dmarc” – This is the name of the TXT record, which recipient email servers will try to retrieve from your DNS when configured to use DMARC.
- “IN” – Standard part of a BIND DNS record. Means Internet, nothing more, nothing less.
- “TXT” – This is the record type. DMARC utilises the bog standard TXT record type as this was seen as the quickest method to adoption, rather than treading the lengthy path towards a new DNS record type.
- Now we have the actual payload (note they are separated by semicolons);
- “v=DMARC1” this is the version of DMARC
- “p=none” – We are effectively saying do nothing and we don’t want to confirm or deny that the emails are from us or that the SPF, SenderID or DKIM information should be trusted
- “firstname.lastname@example.org” – Doesn’t need to be included but if you do include this part, then you can expect to receive emails from the 3rd party email servers who have received email(s) from your domain, confirming what they thought of it
Are there other options?
Yes, though I am only going to focus on a couple here;
The “p=” option has three values that you can use;
- none – Effectively do nothing, this should be set initially whilst you get things set up. Once you have confirmed things look good, then you can start to be a bit more forceful in what you would like other email providers to do with messages which do not come from your email server.
- “quarantine” – This is were they would potentially pass the email on for further screening or simply decide to put it into the spam/junk folder.
- “reject” – This is you saying that if a 3rd party receives an email, supposedly from you, but that wasn’t sent from one of the list of approved email servers (SPF or SenderID) or if it doesn’t pass the DKIM test then it should be rejected and not even delivered.
You set your _dmarc record, now what?
We will assume that you DNS zone has replicated to all of your DNS servers and that you have correctly configured the you email server to sign your outbound emails with your DKIM private key.
At this point I would highly advise going to https:///www.mail-tester.com and send a test email (with a realistic subject and a paragraph or two of readable text) to the email address they provide.
Once mail-tester.com has received your test email, they will process the email headers to confirm whether or not SPF, SenderID, DKIM and DMARC are all correctly configured and working.
It is possible that if your DNS servers are not completely aligned and up-to-date, mail-tester.com may be unable to provide an accurate report. If that happens give it 12 hours and repeat the test again.
Credit: Thanks to Mr Darkroom for making the featured image called Checkpoint available on Flickr.