According to its web site, DMARC, (Domain-based Message Authentication, Reporting and Conformance), is “a technical specification created by a group of organizations that want to help reduce the potential for email-based abuse by solving a couple of long-standing operational, deployment, and reporting issues related to email authentication protocols.” Anything that helps to eliminate spam is clearly a very good thing and deserves some attention, which was the premise of RunAs Radio’s Richard Campbell when he called me up to invite me to debate the topic for a program that you can download from the RunAs web site.

RunAs Radio is an interesting venture (Richard is also an interesting person, but that’s another story) that attempts to capture the thoughts of technologists about topics of interest as they arise. I’ve been interviewed several times (before the DMARC program, the most recent covered Office 365) and enjoyed the process because the conversation is never stilted and Richard adds as much to the debate as the interviewee, which is not always the case when discussing technology. The nature of the discussion often starts with a defined topic and then meanders to cover other material in a very natural way. See what you think.

Of course, plans have been made, recast, relaunched, and remade to stop spam for many years now. The block lists maintained by organizations such as Spamhaus are well respected and serve as a method to stop email sent by well-known spammers. We’ve used block lists for years and they form an essential part of the defenses erected by most large companies to protect their email systems. Deployed alongside other spam checks such as validating message recipients against internal directories, block lists are effective in preventing identifiable spam reaching its destination.

Unfortunately those who sent spam aren’t stupid. At least, those who continually evolve new spam techniques are not stupid – those who simply rehash the work done by others in the hope of convincing others that mail really is from their bank, contains an offer to help someone release millions of dollars from a blocked bank account, or save someone from a fate worse than death are not in this category. Spammers set up and tear down email domains all the time, change the formatting and contents of messages, and work hard to make their messages to seem as innocuous and believable as possible to the recipient.

Techniques like DMARC and its SPF (Sender Policy Framework) predecessor both aim to assist receiving email domains to identify incoming messages from authentic senders by checking details contained in DNS records. Essentially, a receiving server can check DNS to establish whether messages purporting to come from a domain were transmitted by an authorized server. If messages are proved to come from an authorized server all is well and the messages can be accepted. If not, the message becomes a candidate for more extensive testing to determine whether it is authentic or contains spam.

DMARC builds on the framework used by SPF to add features such as providing direction as to what action to take if messages arrive from an unauthorized server. For example, this DMARC record provides the following instructions:

contoso.com TXT v=DMARC1\;p=reject\;pct=100\;rua=mailto:administrator@contoso.com

• p=reject: States the policy for the domain “contoso.com”. In this case the policy is to “reject” incoming messages from unauthorized servers. It could also be “quarantine”
• pct=100: States the percentage of messages from contoso.com that are subject to filtering. In most cases it makes sense to filter all messages.
• rua=address: States a reporting URI for aggregate results. In this case, an email address is provided so that the administrator of the domain is informed of any problems caused by messages coming from the domain. In other words, they can find out whether spam is detected!

SPF has been around for a while and is reasonably widely deployed by large organizations. I suspect that the results reported in this interesting blog showing that nearly half of the messages that pass through Microsoft’s Forefront Online service originate from sending domains without SPF records might be influenced by the customer base who uses this service. In other words, the traffic between large companies who are more likely to have dedicated email administrators who have the time and interest to deploy SPF records might produce different results compared to traffic between many smaller companies whose email is not managed with as much attention to detail.

I note that Office 365 creates DNS TXT records to provide SPF data for the tenant domains that it hosts. This seems like a very intelligent step to increase the amount of SPF-authenticated mail in the network. The format of the record defined by Office 365 is as follows:

contoso.com TXT v=spf1 include:outlook.com ~all

This means is that any mail sent on behalf of the domain by an outlook.com (Office 365) mail server is OK. Interestingly, when I examine the DNS information for my domain (a service such as http://www.dnswatch.info/ makes this very easy), I see a second TXT record has been added:

"mscid=gn+/B+3OqZTqN469IjS37t7msXGgPJlp+/ZCsoh0G6cXONpsOn8Du4SPouE1a9vUTLROlqFbQJdM/TSiogCKfA=="

I have no idea what is the meaning of this record and there’s precious little to be discovered about what it might be used for through Internet searches. Perhaps it’s another piece of authentication data.

In any case, the point is that the global email infrastructure is gradually tightening its controls to enforce authentication between domains in an effort to eliminate spam. I doubt that we shall ever fully eliminate spam, at least not in the foreseeable future, but it’s good that these efforts are proceeding (albeit slowly).

– Tony