Ummm... DKIM is NOT a one-liner in DNS. It requires actually setting up, well, DKIM. The DNS part is simple, yes, but the DKIM isn't, and equating it to a one-liner in DNS is just simply not true.

It’s not trivial, but it’s definitely something I’d expect to be within the grasp of most visitors to this forum.

Importantly you can also verify the correctness of the configuration, which isn’t the case for all anti-spam and anti-spoofing measures.

For most services it is. But you’re right, if it’s self-hosting it’s a real pain in the d**.

would agree..It can also be hard finding selectors down the line that you had already set up because they can often be anything and largely depends on the service and how well they document their standards (and assume they dont change).

I have had to revisit these a few times for companies that change their setup standards and then dont tell their customers (same has happened to SPF but that is much easier to audit/fix).

Opendkim as a daemon as something added to an existing smtpd with postfix is not that complicated.

This feels like shifting the goalposts. From "one line in DNS" to "just install extension into your email daemon and configure it."

Your e-mail daemon should already have configuration for DKIM, and the same tool that generates that key should also print out the complete DNS entry you need. Configuring DKIM in your daemon is a bit of work; The DNS portion of it is simple.

If a person is trying to self-host their own MX and doesn't want to get into the details of configuring SPF, DKIM and DMARC, I would highly recomment they go with something like gsuite or office365 instead. Or some other managed email hosting provider that will do the DKIM setup for them.

> They're all one-liners in DNS config

$1 - turn the screw

$9,999 - knowing which screw to turn

Exactly that. Plus, if you have to configure it, you're already doing more with e-mails and custom domains than 99% of average people who just use an address from a free provider or their ISP.

It's nontrivial to move away from e-mail-as-a-service. It shouldn't be, but we're stuck with decades of legacy and abuse. Years ago there was a statistic doing the rounds that either 80% or 99% of e-mail traffic was spam; I'm confident that is still the case, but thanks to technologies and big providers, end-users only see a fraction of it ending up even in their spam box, and even less in their actual mail. There was one in my non-spam gmail inbox the other day, the first one in years.

I run a wordpress blog with comments enabled as well, Akismet has stopped a million spam comments (99% of comments attempted to be poasted).

This is the exact reason I keep my hotmail account. Which now seems to get me this 'you still you thhhhhhaaaat?'. 'would it make you feel better if I gave you an outlook one or a gmail?'

They filter like 99.99% of the junk. Usually 200-1000 a week (had a low of 20 a few weeks ago). They even show me what they are filtering. That is just 1 account. I have toyed with the idea of setting up my own domain and having my family have all their own emails. But that would mean managing it. Not terribly hard but just one more thing I do not want to mess with. 30 years ago I would have done it. Now I would rather it 'just work'.

Managing spam is a pain. I have been using the 'unsubscribe' links recently. You say then you are just verifying it is real. Well yeah, not like they are going to stop anyway. Worth a shot, but many times they actually respect it, unlike 15 years ago.

Email-spoofing-related records will be checked for you probably dozens of times a week if you offer a public bug bounty through any of the popular platforms. You can get all the advice on them you want for under $100 in payouts. They are among the lowest of low-hanging fruit.

What are the popular platforms for this?

Off the top of my head, HackerOne and BugCrowd.

If you're thinking of setting up a program, it's worth your time to read over some existing program policies - those policies encapsulate a lot of experience that the existing programs have had on their platforms. Your ideal policy will probably differ, but it's worth thinking about why the other program policies are the way they are.

https://hackerone.com/twitter?type=team

Thats why you use one of the all in one email software packages like mailinabox. They will configure all of this for you and show a dashboard telling you everything is good or if something is wrong.

DNSSEC is in a whole different league. But I'd be very skeptical of putting a one-liner from a generator into my DNS without understanding, at least at a basic level, _what_ it was doing. Understanding that also means you can do some manual verification - take a look at email headers to see how mail servers are responding to your configuration, etc. etc.

As for configuring a mail server, yes, that's definitely way harder. But these days, most companies outsource that to the likes of Google or Microsoft, until they get large enough to justify administering their own. There's exceptions to every rule, etc. etc., but every company I've worked at has either used G Suite or Office 365.

The result being: many companies have email services running, but don't have anybody whose day-to-day is understanding how it works and how it's secured.

> But I'd be very skeptical of putting a one-liner from a generator into my DNS without understanding, at least at a basic level, _what_ it was doing

You're completely right, of course. In my experience, these generators usually explain what the generated code means, though. These records are a lot easier to read than they are to write if all you've got is a manual and a technical specification.

I haven't used any hosted mailing services myself, but I can't imagine their control panels don't have either an option to generate the necessarily policies for you or an extensive guide on how you should configure these records and why. These records are the only part of the mail ecosystem these hosted platforms can't manage (unless you also let them do DNS) so they're a crucial step of the onboarding process.

For SPF and DKIM, yes, you're right - most hosted services will generate those DNS records for you, and validate that they're set correctly in your DNS. But in my experience, they often don't mention DMARC at all, present DKIM as a "hey just do this don't worry about it" (which, given that it's cryptography... yeah, I don't necessarily disagree with that approach, don't scare people off), and often don't provide good SPF practices (~all vs. ?all vs. -all).

On generators, a lot of them left me in an uncanny valley. They were supposed to make everything easier, but didn't explain the basic concepts, so I didn't know the values to even put into the generator. After I nailed down some of the basics, the generators just started making sense.

YMMV. There's an infinite combination of mail hosts/servers, DNS providers, and record generators. Collating all that information the first time can be overwhelming, if DNS or email aren't an area of expertise, but I'm sure there's a low-friction path out there. A Northwest Passage of email security. I'd love to find it.

Did … did you just write a blurb followed by pushing a service to do it for you exactly as the author lamented?

You're right - they're not really hard. Dealing with their consequences can be though. The real problem is that they are tacked on solutions...and that's why you end up with things like ARC (https://en.wikipedia.org/wiki/Authenticated_Received_Chain) which as far as I can see is a way of getting around the problems that DMARC creates for so many setups.

ARC addresses a very specific subset of DMARC problems, and in doing so introduces another set of problems.

They are not too hard in principle, but w.r.t implementation, even Google fails in some respects today with DMARC and its own Google Calendar (invite notifications bouncing within the same GSuite):

https://www.reddit.com/r/sysadmin/comments/c5p7e8/dmarc_bloc...

Calendar (and some other stuff) can be fixed by telling google to use the g suite domain for DKIM at https://admin.google.com/ac/apps/gmail/authenticateemail

There's a vast majority of users who struggle even with simple things like setting up an email account in Outlook. Those users will struggle with simple things like deliverability, and for them, an article like this is a godsend.

If you're capable of running your own mail server then you know more about this stuff than most people who use e-mail do, and the article isn't for you.

https://www.iredmail.org/ is another longstanding mailserver-in-a-box if you want to do self-hosting.

And yet still many many many business have SPF records that do not pass validation which IMO is worse than not having them at all

GSUITE wraps it up all nicely so they're really just a option toggle.

I wonder if any other domain providers do this?

Gandi and OVH.

Can someone suggest a Node.js mail server thay does everything for you?

Why does your mail server need to be written in node?

Because that is the ecosystem we write our code in

i use mailinabox for almost a year now and the process has been pretty painless. i did have problems with gmail for the first 2-3 months but that is mostly gone now.

+1 for Contabo. I've been a happy customer for years.

These guys wanted a passport scan and utility bill to open a tiny VPS with them. No thank you.

Actually that is a sign of a provider that takes responsibility for people abusing its service.