This tidbit is part three in a series on understanding some mechanisms available to you for protecting e-mail sent from your domain. We covered this topic in last month’s Tech Talk / SYSOP meetings but for all those that missed them or those that want a refresher, I am covering this again here in this series.
Putting into practice what we share here will not only potentially help with protecting you from inbound spoofed SPAM and malware but also help ensure that your domain’s legitimate e-mail actually gets delivered. Many of the larger e-mail providers such as Google or Microsoft are becoming more suspicious of e-mails received that can’t be verified as from a legitimate sender which is exactly what these mechanisms are designed to do.
All of these methods involve setting up special DNS records in your domain’s master zone file that help tell potential recipients of mail from your domain whether or not that mail came from a location authorized by you to transmit mail on your behalf.
Over this series, we are going to look at three different mechanisms that if all employed can work in concert with each other to help protect your e-mail:
- SPF – Sender Policy Framework
- DKIM – Domain Keys Identified Mail
- DMARC – Domain-based Message Authentication, Reporting, and Conformance
ll are set up around DNS TXT records in your DNS domain's authoritative zone file
This week - DMARC records
We covered SPF and DKIM records in the last two posts so this time we talk more about DMARC which is perhaps the most complicated of the three to fully implement.
The use of DMARC establishes a method for a domain owner to:
- Publish its email authentication practices
- State what actions should be taken on mail that fails authentication checks
- Enable reporting of these actions taken on mail claiming to be from its domain
Using DMARC relies on the established SPF and DKIM standards for email authentication so both these other tools being setup and operational is a prerequisite for the use of DMARC.
With DMARC a domain administrator publishes a policy defining its email authentication practices and how they would like receiving mail servers to handle mail that violates this policy. This DMARC policy is listed as part of the domain’s overall DNS TXT records.
When an inbound mail server receives an incoming email, it uses DNS to look up the DMARC policy for the domain contained in the message “From” header. The inbound server then checks evaluates the message for three key factors:
- Does the message’s DKIM signature validate?
- Did the message come from IP addresses allowed by the sending domain’s SPF records?
- Do the headers in the message show proper “domain alignment”?
With this information, the receiving mail server is ready to apply the sending domain’s DMARC policy to decide whether to accept, reject, or otherwise flag the email message. After using DMARC policy to determine the proper disposition for the message, the receiving mail server will also report the outcome back to the sending domain owner.
The format of a typical DMARC record looks something like this:
_dmarc.mydomain.com. IN TXT "v=DMARC1\; p=none\; rua=mailto:dmarc-aggregate@mydomain.com\; ruf=mailto:dmarc-afrf@mydomain.com\; pct=100"
Looking at the individual pieces of that record:
_dmarc.mydomain.com - is simply the identifier that this is the DMARC record for your domain
IN TXT – is the record identifier in DNS that this is a TXT or “Text” record type
v=DMARC1 - specifies the DMARC version
p=none - specifies the preferred treatment or DMARC policy
rua=mailto:dmarc-aggregate@mydomain.com - is the mailbox to which aggregate reports should be sent
ruf=mailto:dmarc-afrf@mydomain.com - is the mailbox to which forensic reports should be sent
pct=100 - is the percentage of mail to which the domain owner would like to have its policy applied
The DMARC specification provides three choices for domain owners to use to specify their preferred treatment of mail that fails DMARC validation checks. These “p= policies” are:
- none: treat the mail the same as it would be without any DMARC validation
- quarantine: accept the mail but place it somewhere other than the recipient’s inbox (typically the spam folder)
- reject: reject the message outright
Remember that the domain owner can only request, not force, enforcement of its DMARC record; it’s up to the inbound mail server to decide whether or not to honor the requested policy.
Aggregate reports, which are XML documents showing statistical data about the messages received that claimed to be from a particular domain. Date reported includes authentication results and message disposition. Aggregate reports are designed to be machine-readable.
Forensic reports, which are individual copies of messages which failed authentication, each enclosed in a full email message using a special format called AFRF. The forensic report can be useful both for troubleshooting a domain’s own authentication issues and for identifying malicious domains and web sites.
If you have questions about using DMARC or want help implementing DMARC for your domain contact our support team.
Until next time…….
You must be logged in to post a comment.