DKIM Demystified | Hacker News Reader

DKIM Demystified

20i.com

182 points20i32 comments

The interesting technology these days is not DKIM but rather DMARC. DKIM allows you to sign messages so that others know that the message originated from the owner of the domain. DMARC allows you to express what you want receivers to do when someone is spoofing your domain.

If you operate your own domain and you are worried about spoofing, implementing DMARC will put a stop to it with all the major email receivers (Gmail, Yahoo!, Microsoft, etc.), since they all respect DMARC.

But the really cool thing about DMARC is that it lets you receive feedback reports from email receivers with copies of these spoofed messages along with aggregate statistics showing you where spoofed email is originating.

Agreed. Two remarks though: mailing lists often mangle messages thus breaking signatures (bad mailing lists!) and not all providers send forensic reports (e.g. Gmail doesn't send spoofed messages). I my case most spoofed messages were... my own emails mangled by mailing lists.

Is there a guide to setting it up you could suggest?

It's pretty verbose and lengthy, but I recently read the NIST "Trustworthy Email" publication and it did a great job explaining these technologies - Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain Message Authentication, Reporting, and Conformance (DMARC) - that are used for modern email authentication.

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S... (PDF obv.)

Yes I am using sendgrid or some other provider, they do all stuff for you. I like to have control over everything but when you have to send stuff from multuple domains and you have to ask other companies to add SPF and DKIM to their dns and deal with all bs with explaining how it works to other people just pay sendgrid.

If it is for your own domain and you don't have customers for which you send emails on their domains, it is quite easy to set up on your own.

Checkout https://dmarcian.com/. You configure them as the recipient of your xml dmarc reports and they build a nice dashboard with the data. It's free for small stuff.

I’ve previously used ondmarc.com for setup suggestions, monitoring, and reporting. I was quite happy with the service and the support was good.

I've written a DMARC guide here: [0]

If you want to use DMARC, you should use an aggregation tool such as ours to process the reports. You typically start with the DMARC policy in 'none' mode, which only enables reporting. Using the reports you verify that all legitimate senders are correctly signing email with DKIM (and preferably are also SPF aligned) before you switch to a 'quarantine' or 'reject' DMARC policy.

[0] https://www.mailhardener.com/kb/dmarc

I’ve run my own mail server for about 5 years, and setting up DKIM was really the most confusing part. Lots of guides explained “how-to” but not “why”. It wasn’t really until I updated DNS that I got what it was about. This guide does a great job of explaining “why”, I wish I could have read it before I got started.

Everyone says running your own mail server is not advised. Do you find it difficult or time consuming? I'd like to try it but I'm worried it's too much work - what's your setup?

Also have been running my own postfix mail server for several years now. It does take a bit of work to grok all the moving parts, but once you do it's actually quite straightforward.

As long as you have the following configured, then you shouldn't have any problems with getting classified as spam:

- Tight authorization on your SMTP server, obviously,

- SPF, to declare what IPs your domain sends from, so people can't spoof SMTP as you,

- DKIM to let your domain name sign your messages, so you can prove that you what arrived is what you intended to send,

- DMARC to link up the From header with the above, to prove that you're not spoofing senders, and

- The right MX and PTR records in youre DNS zones, to prove you're not spoofing IP addresses.

The above essentially amounts to setting up postfix, opendkim, and DNS, but there are a lot of moving parts, so it's easy to feel overwhelmed at first. Don't hesitate to PM me if you would like to set up your server and need some help.

Not OP, but also run my own email server, using postfix, since 2012. It is sad that there is such a widespread belief it is impossible to do unless you're google. Decentralization of basic internet services helps everyone, so if you're at all interested and willing to learn, go for it!

There are plenty guides on setting up postfix. Follow them, cross reference a few, read the docs and use the various free email test sites to sanity check everything. If you've never done it before, expect to dedicate 2-3 days to this.

Ongoing maintenance is approximately nothing.

> Ongoing maintenance is approximately nothing.

But don't forget to periodically check the TLS certificate of your SMTP server. Administrators often forget to renew the certificates, and automated renewal processes may also break.

I've seen countless examples of SMTP servers with expired certs. The problem is that you won't notice it, as SMTP will fall back to plain-text communication if the certificate is invalid. So the server will still work with an expired cert.

But if you want to do it right, or if you want to adopt MTA-STS, you usually need to do a bit of regular maintenance on the TLS part.

We've also had some of our users report that an expired cert was hurting their domain reputation for spam algorithms. We have not been able to verify that, but it sounds plausible.

Let's Encrypt makes this easy to automate and get notified of any problems on renewal.

Nearly every time someone suggests against this it's not about issues in setting up the server or receiving emails. It's that many popular providers don't trust random IP addresses sending emails, especially those that 'look like' common spam (such as order invoices from common e-commerce sites like Woocommerce or Shopify).

From an inbox perspective these often look like cold outreach (you've never emailed this company before and the first email they send to you is after you order something) so it's suspicious, and being from a trusted platform helps pass the test.

Running your own mail server is not advised if you are trying to handle mail for your friends, family or company when you are not paid for that.

If it is for yourself or for your single person company and YOU handle all the things and you know what is important and when emails are not delivered it is not that much of a problem.

No. You need a clean IP. Preferrably one that hasn't been used for emails before.

Whenever I send mail to a Debian mailing list, I receive notifications of DKIM policy violations. I've never figured out whether the problem is on my side or theirs...

[edit] having done a bit more research, I think the problem lies with the BTS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754809

The mailing list probably appends a footer that breaks the DKIM signature. This has been a known issue for basically all mailing lists for quite some time.

Isn't that easily solved by rewriting the From header and re-signing the email? Send it from:

Some List on behalf of John Sender <list@example.com>

... instead of ...

John Sender <john@other-example.com>

And now the list software can generate its own (valid) DKIM signature.

EDIT: Nevermind, listen to dbqpdb[0] instead. ARC sounds like a better way to go.

[0] https://news.ycombinator.com/item?id=21420732#21422328

But you are right. This is what lists have been doing. They may also set the X-Original-From or X-Original-Sender headers. Google Groups does it anyway. ARC will be better than that though, of course.

It's almost certainly not your problem. DKIM is a cryptographic signature of various parts of the email, which is very commonly broken in all sorts of legitimate ways by mailing lists. This has been a known failing of DKIM & DMARC for quite some time.

However the issue is fixed by the new ARC protocol though, which is supported by most major email providers & in most mailing list software as of like this year. Theoretically, just a matter of time until they update their software & the issue is resolved.

ARC = Authenticated Received Chain?

* https://en.wikipedia.org/wiki/Authenticated_Received_Chain

* https://tools.ietf.org/html/rfc8617

Yes.

Take a look at http://arc-spec.org/ that fixes this

how do you send emails ?

via Exim. I think the problem is not in my setup, as I only receive the notifications after I send mail to the BTS or to a mailing list, but since I have p=none in my DMARC record I haven't put much effort into figuring out exactly where the problem is.

In Gmail open an email you have received. At right upper site there is a button. From there click "show source". The headers will have:

SPF: passed or failed

DKIM: passed or failed

DMARC: passed or failed

I don't use gmail. Regardless, the notifications aren't emails. I have configured my DMARC record to request that policy violations are reported to Postmark and every few weeks I get an email from them summarizing the reports they have received.

There are basically 0 violations, until I mail the Debian BTS or a mailing list, whereupon there are dozens. So it could be a problem at my end, Debian's end, or maybe downstream of Debian (e.g., if mail for foo@debian.org is forwarded on to someone else who has a misconfigured email setup...)

Regardless, my DMARC record has p=none so these reports are informational only. On the other hand, it's basically the reason I've never gotten around to changing it to p=reject...

If you have your DMARC set up right, anyone else who tries to send email using your domain as the "from" address will trigger a DMARC violation. It may be that having your address on a public mailing list triggers spammers to try using your domain.

Many mailing list software returns header information (including, most importantly, From header) while making some modifications to the message (e.g., adding a footer or prepending some text to the Subject header).

A lot of owners reconfigured said software to rewrite the From header since Yahoo changed their DMARC policy to a hard fail and broke quite a lot of mailing lists in doing so, as the resulting backscatter caused the software to unsubscribe people from the mailing list when delivery failed if someone sent a message from their Yahoo account.

I don't think this article mentions it, but you should probably rotate your DKIM keys on a periodic schedule. Consequences for not doing so range from possible key compromise to losing the United States Presidency.[1]

[1] https://blog.erratasec.com/2016/10/yes-we-can-validate-wikil...

Reply on news.ycombinator.com