What is DMARC for – why is this so complicated?
DMARC tells mailbox providers (like Google and Yahoo) what you want them to do with messages that don’t pass authentication checks. Unless you’re me, you probably configured authentication when you set up an application and never thought about it again. In this case, we’re talking about the email authentication protocols DKIM and SPF.
This is necessary as malicious actors can simulate your domain to send fraudulent emails in a process called “Spoofing.” Spoofing is a term for emailing from a domain you do not own or control. I demonstrate this in my internal training program by sending emails from [email protected] asking for a donation to a campaign fund. Most commonly, fraudsters spoof your domain to send YOU emails that trick you into providing sensitive information, like your password or account number.
Because this is so easy to do, all major applications require email protocols DKIM and SPF. Thus, spoofed messages usually go to the spam folder. DMARC is designed to take that to the next level and give you control. Unfortunately, it generates new .xml reports that, for many people, that make no sense.
The Basics: How do I open an XML file?
Usually, these will open in a browser. Sometimes, the file name or format isn’t compatible, so they don’t. In that case, you’ll need to open it in a text editor. On a PC, right-click and open it with Notepad. On a Mac, use Text-Edit.
“Oh, **** – it opened code.”
Don’t panic. I know it can be intimidating, but a little breakdown will help.
Section 1 – Report Metadata
This section contains information about the website and the time range in the data. It’s part of the standard formatting and should be very consistent. Unless you are getting reports from multiple domains, you can ignore this.
Section 2 – DMARC configuration
This section tells you how the current policy for the domain is configured. Remember, there are only three options. None, do nothing; Quarentine, send it to spam; Reject, do not accept the message.
The policy tells Gmail et al. what to do with a message that fails DMARC. (read more on policies here)
Section 3 – The “Records”
The “records” are the useful part of the DMARC report. Each record counts how many times this IP/Domain sent messages as your domain.
This is the complete list of messages that were sent in the time frame and, most importantly, whether or not they passed the DMARC test. It may be hundreds or thousands of messages long and can be completely overwhelming. Without learning to read code, it’s straightforward to find what needs to be cared about in this jumble.
How to make sense of Records.
Many records exist in the records section. If you are viewing this in a browser, you will be able to collapse these as sections. This helps when reviewing, but only if you know what to look for. While there is a lot of information here, you are specifically looking for two things.
1. Did it fail?
You only care if something fails. Most records will look like this:
<dkim>pass</dkim>
<spf>pass</spf>
However, if either of these says “fail”, we want to investigate:
<dkim>fail</dkim>
<spf>fail</spf>
Finding failures is easy – with the document open, CTRL+F, and search “fail.” This word appears in the report only when it is associated with a record to evaluate.
2. If so, what failed?
Either DKIM or SPF will have failed. Evaluating what went wrong may be somewhat easy if you understand these two subjects. However, if you don’t, the process can get really scary.
Let’s simplify this to an objective:
We need to understand what service is sending mail. If it’s ours, we need to fix its configuration so it will pass DMARC. If we can’t fix it, we must understand it so it doesn’t trigger a false alarm. However, if it’s not ours, we may have a security problem that requires escalation.
Most likely, any failures will be our own services. The DMARC policy of “None” tells Google et al. to treat failures normally. However, if we set the policy to ‘Reject”, the emails will be blocked from delivery.
How do we know what the failing service or application is?
Two methods are used to identify the service that is sending the mail.
Information in the Record:
The first is the specific failure list in the report. Either DKIM or SPF will provide the domain configured in the envelope header. This will likely be enough information to identify the service.
If it was a DKIM failure, then about nine lines below “fail” will be the specific domain that failed DKIM. This is the domain configured in the email header and email application.
<dkim>
<domain>b2b-mail.net</domain>
<result>fail</result>
<selector>selector1</selector>
</dkim>
If it was an SPF failure, then about 13 lines below “fail” will be the specific domain that failed SPF. This is the SPF “mail from” domain configured in the email header and email application.
<spf>
<domain>nam04-bn8-obe.outbound.protection.outlook.com</domain>
<result>pass</result>
</spf>
Using the IP Address:
It’s easy to get lost in XML, so I often grab the IP Address from the first row of the record, go to MXToolbox, and do a Reverse Lookup on the IP address.
This IP address will be associated with a product, service, or other environment. Based on this, you can generally identify what service requires configuration to pass DMARC.
What if It Isn’t Clear?
After the obvious has been identified, you’ll have to put your Sherlock hat on because everything from this point forward is a deduction. In this example, we see it’s outlook.com, so I can infer that this is something from my Office 365 configuration. With a bit of extra research, we determined that auto-replies in O365 don’t send via the Tacticalma.com mail header, so they fail SPF.
If we cannot identify a service and see it consistently in our data, then we may be the victims of spoofing attempts. While we can’t stop spoofing, this is a good indicator you should increase the policy level of your DMARC policy. Remember:
None: The mailbox does whatever it wants with the message.
Quarantine: The mailbox puts the message in the spam folder.
Reject: The mailbox rejects the message and does not deliver it at all.
You must not set your policy to REJECT if your services or applications are also failing DMARC because you will not receive your own messages.
As always, if you’d like help, please feel free to contact us!
