Who is this for?
If you use a free email service like GMail, Yahoo, Outlook, etc. then this doesn’t apply to you – DMARC configuration only applies to those with their own domain and access to its associated DNS records.
DMARC is something I was first introduced to at my last job and, to be entirely honest, I never quite wrapped my head around the concept. However, a recent personal experience forced me to revisit it and I managed to unlock its secrets!
Honestly, DMARC isn’t really all that complicated. Basically, it’s primarily a reporting protocol that actually monitors two other authentication processes – SPF and DKIM – and then takes the next step by proactively recommending an action based on those results.
The main idea behind all three of these acronyms is to set up your mail server to ensure that bad actors out there are unable to spoof your domain and send spam/phishing messages that appear to come from you.
The easiest way to illustrate this is to briefly explain each of the three acronyms (and their function):
Sender Policy Framework is a method where a receiving e-mail server will check back with the source domain and confirm that the message was sent through one of a list of “verified SMTP servers.”
SPF isn’t foolproof, as spammers have learned how to tweak message header info to make the receiving server believe that the source IP matches the real SPF record. But it’s a start.
An example of a SPF record added to a domain’s DNS could be:
v=spf1 include:_spf.google.com ~all
Domain Keys Identified Message involves the generation of a key for inclusion in the sending domain’s DNS records. The sending domain then “digitally signs” each message sent – any receiving server will verify this signature with the key of the sending server.
Generating a valid DKIM record for your domain involves digging into your domain provider’s admin console, but a simple example of a DKIM record added to a domain’s DNS could be:
v=DKIM1; k=rsa; p=<uniqueHash>
Domain-based Message Authentication, Reporting and Conformance is a protocol designed to provide you with reporting feedback from receiving servers and to tell those servers what they should do when they receive a message (supposedly) from your domain that fails one or more authentication tests (like SPF or DKIM!).
An example of a DMARC record would be:
v=DMARC1; p=reject; rua=mailto:firstname.lastname@example.org; ruf=mailto:email@example.com;
where “p=” indicates the desired action (options are none, quarantine or reject), “rua=” indicates an email address to send aggregate reports about received messages to and “ruf=” indicates an email address to send forensic reports to.
Now that we’ve explained the basics, stay tuned for Part Two of “The Dummy’s Guide to DMARC” where we’ll cover how to implement this in your own environment!