Lawrence Sheed // 25 Dec 2012 // Comments Off on DMARC support implementation for Computer Solutions

As we’re a pro-active sort of ISP, we often take a look at ways to improve things for clients under the hood.

One of those improvements, was our recent DMARC implementation for our mail servers.

DMARC is a newish standard which adds to our existing SPF setup, by allowing us to publish methods that tell other providers how mail from us should be processed. It also allows us to receive reports from other providers as to how they’re processing our mail.

Thats good for us, but how does it help you as a client?
Providers that publish valid DMARC records should get brownie points at the larger providers. Gmail says that they’ll give us a gold star* (next to our email address), as its verified.
*Current implementation shows our email addresses in green in gmail as we’re SPF and DMARC verified, but its the thought that counts.

This should improve delivery for problematic providers once they get onboard the DMARC train. Cough Yahoo, cough hotmail…

The official party line regarding pro’s and con’s is below:
A DMARC policy allows a sender to indicate within its DNS record that its email is protected by SPF and/or DKIM and then specify to a receiver what to do if neither of those authentication methods passes, such as quarantine or reject the message. Referencing a sender’s DMARC policy removes the guesswork from the receiver’s handling of these failed messages, limiting or eliminating domain spoofing and the end-user’s exposure to potentially fraudulent and harmful messages.

Additional benefits:

• Block unauthenticated emails at the gateway to decrease phishing attacks.
• Eliminate guesswork on how to handle non-authenticated email.
• Provide feedback (aggregated and forensic reports) to domain owners on email that fails authentication.
• Decrease spam and improve your ability to deliver legitimate email.

 

 

Back to normal people speak;
DMARC uses 2 existing standards – SPF, and DKIM.
(For various technical reasons, we’ve steered clear of DKIM signing emails, we use the SPF mechanisms)

Quick DMARC process overview
An email provider publishes a valid SPF record and / or DKIM signed email.
The same provider sets up a special TXT DNS record (_dmarc.provider_domainname) which says how to process the mail.

When a mail is sent from a provider, to a remote recipient, the remote server will first check the DMARC record, then process the SPF or DKIM records as per their DMARC settings.

The graphic below shows the flow

Image courtesy of DMARC.org

How does our implementation work?

computersolutions.cn publishes SPF records in our DNS setup.
Our current SPF record is below:

dig txt computersolutions.cn

; <<>> DiG 9.7.3 <<>> txt computersolutions.cn
;; global options: +cmd
;; Got answer:
;; ->>HEADER< ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;computersolutions.cn. IN TXT

;; ANSWER SECTION:
computersolutions.cn. 600 IN TXT “v=spf1 redirect=_spf.computersolutions.cn”

If you take a look at the return value, we say that we support SPF version 1, and that you’ll need to go to _spf.computersolutions.cn for the actual record.

v=spf1 redirect=_spf.computersolutions.cn

Lets look at _spf.computersolutions.cn

dig txt _spf.computersolutions.cn

; <<>> DiG 9.7.3 <<>> txt _spf.computersolutions.cn
;; global options: +cmd
;; Got answer:
;; ->>HEADER< ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;_spf.computersolutions.cn. IN TXT

;; ANSWER SECTION:
_spf.computersolutions.cn. 600 IN TXT “v=spf1 mx:computersolutions.cn ~all exp=badsender.computersolutions.cn”

 

v=spf1 mx:computersolutions.cn ~all exp=badsender.computersolutions.cn

Again, we say we’re using SPF version 1.
v=spf1

But this time, we say that only mail servers for computersolutions.cn are allowed to send mail as someone@computersolutions.cn.
mx:computersolutions.cn

As we’re still in testing mode, we’ve said our checks should be made with ~all (which means soft fail if it doesn’t pass the SPF check).
~all

Lastly, we have an explanation record. This is yet another DNS record which says what should be passed back to a client in case of SPF lookup failure.
exp=badsender.computersolutions.cn

Lets take a look at that record

dig txt badsender.computersolutions.cn

; <<>> DiG 9.7.3 <<>> txt badsender.computersolutions.cn
;; global options: +cmd
;; Got answer:
;; ->>HEADER< ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;badsender.computersolutions.cn. IN TXT

;; ANSWER SECTION:
badsender.computersolutions.cn. 600 IN TXT “%{i} is not one of %{d}’s designated mail servers. Please follow this link for assistance – %{d}/why.php?s=%{S}&i=%{I}&h=%{H}&d=%{d}”

It looks complicated, but essentially it expands into a more user friendly message for senders who get rejected mail claiming to be from our server.

%{i} is not one of %{d}’s designated mail servers. Please follow this link for assistance – %{d}/why.php?s=%{S}&i=%{I}&h=%{H}&d=%{d}

So far so good.

 

 

How does DMARC fit in?

DMARC as you may have already guessed, works as yet another DNS record.

Who would have guessed!
Lets look at our DMARC record.

dig txt _dmarc.computersolutions.cn

; <<>> DiG 9.7.3 <<>> txt _dmarc.computersolutions.cn
;; global options: +cmd
;; Got answer:
;; ->>HEADER< ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;_dmarc.computersolutions.cn. IN TXT

;; ANSWER SECTION:
_dmarc.computersolutions.cn. 600 IN TXT “v=DMARC1\; p=none\; pct=100\; rua=mailto:dmarc at computersolutions dot cn”

I’ll break it down below:

We’re compliant to DMARC version 1
v=DMARC1;
We say don’t do anything special to mail that fails checks. We could also say quarantine or reject mail (which we’ll probably do once we’re finished testing the DMARC rollout).
p=none;
100% of mail processed should have this rule applied
pct=100;
Send error reports to our dmarc address.
rua=mailto:dmarc at computersolutions dot cn (this has been changed from our actual address to deter evil spammers).

Our DMARC report address is already receiving reports from other providers, and we’ll soon be rolling out a reporting function for internal use to use that for troubleshooting in detail with other providers when there are SPF related delivery failures.

Refs:
http://www.dmarc.org/faq.html
http://www.dmarc.org/specification.html
http://www.returnpath.com/wp-content/uploads/resource/what-you-need-to-know-about-dmarc/Return-Path-WP-What-You-Need-To-Know-DMARC.pdf