The handwriting is on the wall. Sending email using your own domain name is about to get more complicated, but also more reliable – if you take the right steps. If you don’t, you will find that more and more of your email fails to get delivered, filtered out as spam. The reason is DMARC.
The acronym stands for, “Domain-based Message Authentication, Reporting & Conformance”. What that means is giving recipient email servers much more information. You can get the details from the DMARC website, but basically it’s a much more reliable way of separating legitimate email from mail sent by scam operators. It’s important to you because it is gaining traction with all the large email service providers.
DMARC expands on 2 older email authentication techniques, SPF and DKIM. SPF stands for, “Sender Policy Framework”. It gives recipient mail servers some clues about where email should come from. It enumerates the email servers which send your email and (among many other things) lets you specify what to do with email not from those servers.
DKIM is the technique of signing outbound emails with a key value which the recipient server can independently verify as belonging to your domain. Both have been in use for many years and are routinely considered when evaluating whether an email is spam or not. Both suffer from the shortcomings of the way email works and is used. They help with, but come no where close to solving the spam problem.
For example, if you were to put in place an SPF record which says that all email from you originates from a specific email server, about 1/3 of your email would bounce. Roughly that much email is handled in one way or another by forwarders and there is no acceptable way to trace a specific email back to the source. DKIM was invented to address the shortcomings of SPF, but has shortcomings of its own. When you factor in forwarders, auto responders, list servers, catch-all email addresses, spammer tactics and counter measures, what you find is that the number of special cases is huge.
Efforts to retrofit the system with standards and methods which solve the problems have generally met with resistance, low acceptance and sparse implementation. People want their email to “just work” without having to understand anything about it and without having to deal with spam and in any way they can imagine and it had better be reliable and fast as well. Accommodating complex and conflicting demands has created a complex and conflicting environment.
Thousands of email servers are are misconfigured, compounding the problem. That includes mail servers at many large companies, government agencies, service providers and especially at universities. Email was designed for an environment very different from what the Internet has become. It’s reasonable to call the entire system as it exists now, a mess.
What is different about DMARC is that many large service providers are finally willing to step on some toes. The threat from phishing scams, large networks of compromised computers, espionage and criminal enterprises has become too great to ignore. Among the service providers to implement and enforce DMARC policies are: PayPal, Yahoo, AOL, Google, Microsoft, Hotmail, Comcast, Facebook and Twitter. Some 80,000 domains are protected with DMARC policies. Enforcement has meant breaking certain kinds of email use. For example, you can no longer set the from address to [someaddress]@aol.com on an email which will be sent from a non-AOL mail server. It will bounce when sent anywhere which considers DMARC. Although somewhat apologetic about it, AOL is now enforcing DMARC policies. AOL is just one of many. And this example is just one of many things DMARC will change.
We are often asked what can be done to prevent spammers from hijacking email addresses. We mask how common this is by refusing returns of emails not sent by our servers. Spammers always forge from, reply-to, and return-to addresses. It’s a good question because anti-spam measures are turning more and more to reputation based metrics. Because there are so many uninformed email users and mail server operators, these forgeries can and do damage reputations. DMARC nearly eliminates this problem.
DMARC is a golden opportunity for reputation based spam filtering. It’s presence allows immediate and unequivocal rejection of a lot of spam. Since its presence on a particular domain implies “not spam”, what is the effect of its absence? In our spam filtering process the vast majority of spam is easily identified, but that still leaves a huge amount for evaluation. As DMARC becomes more widely used, its absence is a more clear indication that any given email is from an unreliable source and is spam.
The bottom line is that deploying DMARC on your domain is something you need to get done. And as time passes it will get more important.
We are available to answer questions and help you get this done.
Paul Roger says
I am grateful that you know too much. My brain is now full. You said: “deploying DMARC on your domain is something you need to get done” and that you are ready to help. So, what you did not say was just how “I” am supposed to do this?
Dennis Mathiasen says
The short answer is that you can’t do it without help. Both DKIM and SPF are available to be implemented in cPanel and that should be done as a start. Unfortunately the cPanel implementation does not understand using a separate email server and the SPF settings by default will be set incorrectly. There is no provision in cPanel for DMARC (it’s a new feature request with them) so that is something I will have to manually add as well.
I jumped the gun a bit with this posting. There are some parts of this which can be automated, but the scripts to do so are not in place yet. It’s not a big deal to manually do a few domains, but we handle email for more than 30,000 domains. Getting them all done will need as much help as we can get.