11 ms·

How to prevent email spoofing, using an unholy combination of silly standards

392 points by simon360 5y ago

relax88 5y ago
The title seems a bit dramatic but I can see how this sort of stuff would throw anyone without a history of network or systems administration for a loop. This is one thing I really enjoyed about setting up ProtonMail with my personal domain. They make it really simple to validate that SPF, DKIM, and DMARC are set up properly.
- dang 5y ago
  Ok, we've changed it to the (slightly less dramatic?) subtitle. Not sure which is the better choice here...
- simon360 5y ago
  I didn't realise that ProtonMail had DMARC built in. I'm kind of surprised more email providers aren't including DMARC report analysis out-of-the-box, to be honest. If Google Workspace/G Suite started pushing admins to use DMARC, and provided tools to make it easy, so many more domains would be protected, particularly in startup world.
- Jiocus 5y ago
  I agree about Protonmail. Never used their service, helped a client straighten their records for a project. No issues. Tutanota are just as straightforward, but they're both in the security game so not much of a surprise there.
lstodd 5y ago
SPF, DKIM, DMARC... all useless. I somehow live without all those for what, since before they appeared. 2001 in fact. With my own MX. They are just ineffective bandaids.
- ttul 5y ago
  Yet without DMARC, we would be far worse off.
  - lstodd 5y ago
    I doubt that.
- Denvercoder9 5y ago
  83% of spam I received last month failed at least one of these checks, while less than 2% of ham did. They're certainly useful.
  - lstodd 5y ago
    IDK maybe it's my tendency to keep a low profile. Or some other perceptual bias. But in last 5 years levels of spam never even remotely approached levels what I remember from 2000s, when my job was actually fighting it (at an ISP). All this tech (SPF, DKIM, DMARC) came and went ... somewhere, and there was exactly zero impact in spam rates on the handful of domains I now maintain, when I did take some time to implement them. Nowadays I have a couple of my own domains, with nothing antispam-configured, and an gmail account, and you know what -- spam amounts almost exactly match. Hence the conclusion - it's not worth it to invest time into it.
    - jpcosta 5y ago
      Maybe try running a business?
- Urgo 5y ago
  As long as you don't email anyone who uses a gmail address or uses google's email hosting (which is the majority of internet users now?) then you can get away with that. I did too (also having run an MX since around 2001)... but a year or so ago google started filtering all email which didn't comply into spam.. so.. had no choice but to set it up.
jeroenhd 5y ago
I disagree with the idea that SPF, DKIM and DMARC are somehow hard. They're all one-liners in DNS config that can easily be generated with some online tools if you don't want to read the standard. In my experience, correctly configuring mail server software is a lot harder than configuring the DNS to make your email arrive as reliably as possible. Obscure configuration formats are par for the course for almost every mail server setup. I've personally had a much harder time getting DNSSEC to work than I ever had issues with the various email DNS records. Even that is manageable if you're willing to Google around for a while. My solution to getting self-hosted email right is using Mailcow. A cheap VPS (Contabo FTW) plus Docker is all you need to get it to work, and it spits out all the DNS records you might need to add. That also includes autoconfig records for tons of software, which is nice.
- imron 5y ago
  > They're all one-liners in DNS config $1 - turn the screw $9,999 - knowing which screw to turn
  - SilverRed 5y ago
    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.
  - thaumasiotes 5y 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.
    - JohannesH 5y ago
      What are the popular platforms for this?
sbuk 5y ago
The thing to remember is that these are useless unless the recipients MTA is configured to take action against failures. Another thing to understand is that very few services, commercial, public or otherwise, send DMARC reports, and many that do send very sparce reports that are as bad as not recieving anything at all. Fundamentally, catching spoofing, phishing and spam and not catching 'ham' is actually really hard.
- toast0 5y ago
  It's been years since I did it, but I added DMARC to a high volume domain and the reports were useful while I was adding it, to help make sure I didn't forget any authorized senders, but once I got that finalized, the reports were totally unactionable. I can't do anything about the attempted spoofs; I'm not going to track down everyone's open relays, and if I would, DMARC reports aren't really enough anyway. At the time, Yahoo, Google and Microsoft all sent reports, which is a good portion of email, although certainly missing a lot. I think there were a few other smaller names, which I no longer remember. Of course, it almost doesn't matter. Spam/phishing mail to our users still continued, they just stopped spoofing our address. It's not like very many people look at the domain mail claims to be from anyway; modern clients hide it, too.
  - nwallin 5y ago
    > they just stopped spoofing our address. This also means that emails from your domain is less likely to get marked as spam, which can be a significant win for smaller domains.
anyfoo 5y ago
I still run my own router at home, and my own servers of various kinds. I put a lot of thought into my packet filter configuration for example, and overall my handwritten router and server stuff comes at a maintenance cost that I am happy to pay. Not so for email. It just stopped being worth it about 10 years ago or so. Regularly fine-tuning your configuration to not only not be marked as spam in originating mails, but to also filter incoming spam, walking the thin line between filtering too much and too little, was just no fun. I looked out for an email provider that provides the flexibility that I'm used to (multiple domains, catchall for subdomains, sieve filtering etc.), pay them a few dollars per month or year, and haven't looked back. My DNS is still homegrown and I handwrite my zones, but the MX just points to my provider.
azornathogron 5y ago
Related: if you have a domain from which you never want to send email, you can also set up these records to tell receivers to reject everything. Here is a guide: https://www.gov.uk/guidance/protect-domains-that-dont-send-email https://www.gov.uk/guidance/protect-domains-that-dont-send-e...
- sk5t 5y ago
  This is worth doing, as certain "vendor security vetting" services will check these settings on vanity/convenience domains they manage to associate with your organization.
- flas9sd 5y ago
  I like that concrete mail advice is two subpath levels deep into "the" UK government website. High text contrast, loads fast. Kudos to them.
gloryless 5y ago
lol, that's cause it's mostly for mail coming from your server. You probably don't see any of it
kureikain 5y ago
When implementing spam filtering for my email forward app (https://hanami.run https://hanami.run) I was super confused at DMARC and as the author said. The DMARC keyword were all SEO-focus content by companies that aim for that keyword and didn't clearly give a definition of DMARC. Another confusion is the ARC, the acronym was alike so I though ARC has some relation to DMARC where they are totally different :). I think to help new people understand them, we should stop group DMARC with SPF/DKIM. SPF and DKIM are the thing you set up and you control. But DMARC is just a policy to tell the recipient what they should do if something failed SPF or DKIM. And it's totally up to recipient's mail server to support and follow standard of DMARC.
darkhorn 5y ago
Do you know any free email providers for custom domains that who provide DKIM?
johnklos 5y ago
Thank you. We need more of this. Too many "how-tos" are written with too many assumptions and not enough common sense, straightforward explanations. I've set up and run all of these, but that doesn't mean that it doesn't frustrate the heck out of me whenever I have to deal with them. A good, handy reference like this will be quite useful.
max1cc 5y ago
This is a really nice article! Just so you know, it says that Postmark doesn't offer a DMARC service, but they actually offer two: Free DMARC Monitoring (https://dmarc.postmarkapp.com/ https://dmarc.postmarkapp.com/) and DMARC Digests (https://dmarcdigests.com/ https://dmarcdigests.com/)
- simon360 5y ago
  Well this is embarrassing. Thanks for pointing that out - I've corrected the article and cited you.
  - max1cc 5y ago
    My pleasure! Sorry to be pedantic :)
shirro 5y ago
A controversial headline and a bit of opinion creates controversy and gains views. Once this sort of information would be written in a plain text HOWTO and posted to usenet but now we have to clickbait everything so it gets posted to HN. SMTP is hopelessly naive by the standards of today as it was designed to work in a much smaller and more trusted environment. The additional reputation protocols are well intentioned and work well if the receiver acts on them and are not at all silly or unholy. They are not difficult to configure but neither are they as simple as a redesigned protocol might be. If you don't need to setup your own mail servers or have a desire to develop and maintain skills in that area then use a pre-configured service. Otherwise I am fairly sure that configuring these things is far simpler than most trade skills. I don't think there is any comparison between the time it would take to read some docs and add a few lines to a config file and learning to become a proficient welder. If you work with servers and want to be good at your craft I think email is still one of the services people should know how to configure and secure.
agotterer 5y ago
I use a service called OnDMARC (https://ondmarc.redsift.com/)for https://ondmarc.redsift.com/)for managing email spoofing/delivery. They have a suite of tools for managing and monitoring spf/dkim/dmarc. Nothing you couldn’t do yourself, but they make it easy. They also have a couple of cool extras like “dynamic spf” which lets you expand beyond the standard spf record length.
leetrout 5y ago
> And never forget to use -all And yet even Googles docs recommend ~all. If you're using 3rd party bulk senders you probably want to consider the cost and benefit of -all vs ~all https://support.google.com/a/answer/10684623?hl=en https://support.google.com/a/answer/10684623?hl=en
- aj3 5y ago
  3rd party bulk senders likely know more about mail delivery than you do. Also DMARC aware recipients will treat ~ALL in SPF exactly like -ALl.
jchook 5y ago
DMARC basically breaks mail intermediaries and is fundamentally problematic, hence the low adoption rate. ARC is a much better alternative that builds on DKIM and allows intermediate custodians of mail.
- azinman2 5y ago
  What does intermediate custodian mean here? Something like sendgrid? Is there an issue for normal peoples email on custom domains (eg fastmail or gmail hosted)?
  - toomim 5y ago
    I think he is talking about mailing list servers. When you email mailman, it'll add a line to the bottom of the email, manipulate some to: and cc: headers, and forward it along. This changes the hash of the email which breaks some crypto signatures.
- aj3 5y ago
  No it doesn’t, unless said intermediaries are modifying contents and are not DMARC aware. Many European countries are forcing DMARC adoption for government infrastructure and it works just fine.
mmcclimon 5y ago
> Normally, this means that spf.messagingengine.com has its own SPF DNS record, which will probably list some valid IP addresses that emails can be sent from. There's also one for Mandrill, for transactional emails. You can have as many of these as you want. This isn't strictly true (that you can have as many as you want), because SPF has a (IMO) very silly hard limit of 10 DNS lookups per record. From RFC 7208: > Some mechanisms and modifiers (collectively, "terms") cause DNS queries at the time of evaluation, and some do not. The following terms cause DNS queries: the "include", "a", "mx", "ptr", and "exists" mechanisms, and the "redirect" modifier. SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return "permerror". We see this not infrequently at Fastmail, when customers report DMARC validation problems, and the answer turns out to be that they've got too many includes in their SPF records, so SPF always fails.
- technion 5y ago
  That limit of ten is extremely easy to meet when someone casually says "Hey we've started using Freshdesk for ticket tracking, setup DNS please". Ok so you include:email.freshdesk.com. That record itself includes four other freshemail.io DNS lookups, and sendgrid.net, which includes another one. So you're seven DNS lookups in just for that. Gmail's recommended include:_spf.google.com includes four more, at which point the limit is exceeded and SPF is broken.
  - mmcclimon 5y ago
    Yeah, for sure! Outlook is also very bad about this, and usually when we see it people have added include:spf.messagignengine.com (Fastmail's SPF, which is all IP addresses) and one other include, which does a bunch of recursive lookups. This is often very difficult to explain to people, and there's not even really a way to work around it, short of using different domains for different sending needs (which many people are unwilling or unequipped to do).
    - Hello71 5y ago
upofadown 5y ago
Some companies just mark incoming email with something like [external] to solve the problem used as an example. In the end you are going to know if an email came from your own server, you are the one sending them. If it is really that important, businesses should be signing their emails.
- aj3 5y ago
  Eh, DMARC is meant to solve different problem. E.g. when your accountant receives spoofed mail with a fake invoice supposedly coming from a legit supply chain provider. They might be trained to check domain that was used to send email but without DMARC non-techies won’t be able to notice well made spoofed email.
  - upofadown 5y ago
    Assuming that the email client used even shows the domain. If you can train your employee to do an obscure technical check you can for sure train them to verify invoices. After all, if you don't then the legit supply chain provider can just generate fake invoices.
johngalt 5y ago
SPF = This list of servers are authorized to send email for my domain. DKIM = This specific email can by verified/authenticated by my DNS. DMARC = What to do with email that doesn't comply with above. And how to tell me about it (if you want to). SPF is basically useless due to the centralization of email providers. It was created to be locked to a company specific email server. E.g. Only accept mail from exchangeserver.company.com, and reject everything not from that server. Now everyone authorizes Microsoft or Google to send their mail.
- judge2020 5y ago
  Technically SPF is still useful if you trust that Microsoft and Google aren't allowing arbitrary email to be sent from non-verified email addresses, which it seems both do (although neither seem to require periodic re-verification).
- aj3 5y ago
  SPF (alone) is useless because it actually does not check the sender's domain in the From header (as one might naively think). Instead it only verifies Envelop Sender which can differ (intentionally) from the mail seen in From header.
contravariant 5y ago
> nothing demonstrates this more simply than this PHP script Arguably there's nothing more clear than writing it manually over telnet. If you haven't done so yet it's kind of fun to try it out once.
deleted 5y ago
[deleted]
andrewmcwatters 5y ago
I'm less upset with SPF, DKIM, and DMARC and more irritated that you can't find any 5 minute guide on how to set it up. As this article states, it's all SEO bullshit and DNS validators that don't explicitly say, "Add this TXT record to your DNS set. This directive means X. That directive means Y." Unfortunately, as much as I sympathize with this article, I can't pass this around to colleagues as technical reference, because it's just a rant. A rant with helpful information, but a rant nonetheless. I need reference documentation that isn't going to disappear when the author decides to change blogging platforms, etc. So, below are the RFCs, with sections, that actually matter. DKIM and DMARC are not required to have a functional piece of software that sends emails today, though. Just use SPF and you should be fine. A TXT record with @ for the current origin[1] or the relevant host with the following is sufficient[2]: v=spf1 include:example.com ~all You can use multiple includes. If you're pointing to your own DNS records, though, don't use include. Use a. As far as I understand it: include[3] is others, or as RFC 7208 states it, 'independent domains.' a[4] is you (A records). In this case, it looks like this: v=spf1 a:mydomain.com ~all That's it. Now your mailer should work. So for example, you've got a domain name on Namecheap, and you're hosting on a VPS. You've pointed your A record for @ to your VPS' IP address. That's all you need there, and all you need for SPF is a TXT record pointing for the current domain, @, and the string above, with the a mechanism pointing to your domain name. SPF-compliant software will look up your TXT record containing the SPF string, see the domain, lookup its IP address, and match it to the server where your email is coming from, then allow it in transmission. Popular mailers should tell you all this these days, but they don't, and it really sucks. [1]: https://datatracker.ietf.org/doc/html/rfc1035#section-5.1 https://datatracker.ietf.org/doc/html/rfc1035#section-5.1 [2]: https://datatracker.ietf.org/doc/html/rfc7208#section-3 https://datatracker.ietf.org/doc/html/rfc7208#section-3 [3]: https://datatracker.ietf.org/doc/html/rfc7208#section-5.2 https://datatracker.ietf.org/doc/html/rfc7208#section-5.2 [4]: https://datatracker.ietf.org/doc/html/rfc7208#section-5.3 https://datatracker.ietf.org/doc/html/rfc7208#section-5.3
- vgb2k18 5y ago
  > That's it. Now your mailer should work. Work... technically... yes. If the definition of 'works' is: "I press send and sometimes my email reaches it's destination". The spirit of the article IMO implies a definition akin to "I press send and my email reaches it's destination. And... my emails have some protection against spoofing attacks". So in the spirit of the article, I would recommend your 1-liner takes a small yet significant change: v=spf1 include:example.com -all Now... let's talk about biggest barrier to entry for n00bs (myself included) in the self-hosted email game: non-blacklisted ip-address space. And blacklist here refers not just to public lists (SPAMHAUS etc) but private ones too (e.g., outlook).
na85 5y ago
>Then, I encountered a second problem: I had no idea what those were, and seemingly nobody has written about SPF, DKIM, or DMARC in a way that a human can understand, not to mention implement. Every article I found was either highly technical, trying to game SEO to sell me something, or too high level to be useful. I guess TFAuthor hasn't done a cursory google search, because if they had they'd have found the ISPmail tutorial[0] which is clear, concise, mostly correct, and approachable if you aren't a total novice to Linux. [0] https://workaround.org/ispmail https://workaround.org/ispmail
dataflow 5y ago
Can someone explain why you can assume a recipient would respect DMARC when dealing with SPF but not check your DKIM? It never made sense to me why we need anything other than DKIM honestly.
- aj3 5y ago
  Sure. Parsing DMARC requires understanding DKIM as well, so what you’re asking is a non issue. That said DKIM is not enough because that standard does not have a way to signal recipient that your domain has DKIM set up in the first place (and you promise that all your mails should always be signed). It’s kind of funny but essentially hacker does not need to spoof DKIM because they can just omit it and recipient won’t be able to know that it should have been present in the first place. Btw, there was proposal to add a feature that could be used for this signaling but it didn’t get adopted, so DMARC is the only practical solution right now.
  - dataflow 5y ago
    > Btw, there was proposal to add a feature that could be used for this signaling but it didn’t get adopted, so DMARC is the only practical solution right now. Wow, thanks. That definitely explains this mess. Do you know why it didn't get adopted? I'd have thought that in a sane world all you'd need is to literally have a DNS record that specifies the DKIM info... pretty simple. Why on earth did people find it more convenient to do it in such a convoluted fashion instead? Especially now that there's ARC too, which I'd have thought shouldn't be necessary either.
    - aj3 5y ago
      Corporate politics and death by committee. These standards were created by many parties with conflicting interests. My understanding is that they couldn't agree on an exact way From header should be checked and thus deferred all policy aspects to further standard. If you read DKIM RFC it actually only specifies how to sign and verify the email signature, but does not mandate exact checks recipient should do to figure out authenticity. E.g. technically Microsoft could send mail from @gmail.com address and use "d=outlook.com" in the signature - the signature would be valid, but obviously it wouldn't make it authentic (meaning such mail wouldn't be authorized by Google). Although common sense dictates that there should be some sort of connection between domain seen in From header and the one that's DKIM-signing the mail (and most real-world implementations will do some kind of checks), RFC deliberately does not standardize these steps. The intended standard that should have clarified these issues was ADSP, but it wasn't well received and now we have DMARC which handles both SPF and DKIM together (this is better for deliverability as mails that fail one of these checks might still pass another).
tamu_nerd 5y ago
Also infuriating: Not all email services treat DMARC in the same way, or way you'd expect (eg: O365 will by default deliver a p=reject to spam https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/use-dmarc-to-validate-email?view=o365-worldwide#how-microsoft-365-handles-inbound-email-that-fails-dmarc https://docs.microsoft.com/en-us/microsoft-365/security/offi...)
geocrasher 5y ago
I'm going to refer to this post whenever says "running your own mail server is easy!". I suppose that if you already know how to run your own mail server and are familiar enough with all the moving parts, sure, it's easy. But if you have a problem that needs to be solved, and you think the answer is running your own mail server, you now have two problems. The "unholy combination of silly standards" is an excellent way of putting it, but it goes back to the 1970's. SMTP was originally based on FTP. Anonymous FTP, at that. It was designed to send text- nothing more. And really that's all it can do still. We can thank Base64 for binary attachments that are at 30% bigger than their unattached size. Yeah, mail is a problem. And it always will be because it's a 50 year old technology that was designed for a collection of a few hundred servers ran by technologists who trusted each other. SPF, DKIM, and DMARC (and literally everything after except for "send text to so and so") is an afterthought.
- Semaphor 5y ago
  These aren’t even "run your own mail server" territory. It’s stuff that you already need to worry about when simply using your own domain.
- NorwegianDude 5y ago
  Running a mail server is very easy. Setting it up to begin with is the hardest part. Email isn't exactly moving fast, so it's basically set and forget if you don't have to deal with it on behalf of untrusted parties. That said, a technically inclined person would probably be able to set up a server in a day or three and understand the basics of how it all ties together. Just because not that many people understand how to set it up doesn't make it hard. But it's definetly showing it's age and could be much simpler to use.
  - aj3 5y ago
    It’s definitely not set and forget. In the past year alone there where multiple 0day attacks against Exim and MS Exchange servers.
- Tepix 5y ago
  Use sovereign instead of setting everything up by yourself. You should know the basics of linux system administration, however
kro 5y ago
The article is good, but misses an important point (that adds yet another confusing thing about email): the difference between Header.From and Envelope.From and how DMARC also solves this by requiring identifier alignment. Without it, generally only partial validation of the envelope address happens by i.e. SPF.
gorgoiler 5y ago
Can SPF, DKIM, and DMARC be CNAMEs? It’s a little bit easier when one can move all this stuff onto one host, away from the rest of ones infra, especially when it comes to distributing DKIM keys. I wouldn’t be surprised if there’s also a mail daemon that also did DNS for you. Everything in one simple MTA. Begone, Exim4 mega config and update-exim4.conf.conf.conf!
- teddyh 5y ago
  DKIM and DMARC can be CNAMEs, but not SPF, since SPF lives at the apex domain name, which can not be a CNAME. (Of course, if your email address is on a subdomain, then that can be a CNAME. But then the MX records will also have to be moved to the CNAME target.)
  - marcbradshaw 5y ago
    Not even then, RFCs state that a CNAME may not exist with any other RR type, and your apex domain needs at least SOA and NS records. A CNAME on the apex domain may kind of work, but it will present as broken in subtle and unexpected ways.
    - teddyh 5y ago
      Um, what? I think you misunderstood me. Or you are unaware that DMARC and DKIM records live on subdomains.
- marcbradshaw 5y ago
  DKIM and DMARC can be CNAMES, many services already use this, at Fastmail for example for DKIM you setup CNAMES, and we manage DKIM keys for you. SPF needs to be on your (root/organizational) domain, and you don't want (can't have) a CNAME there.
pabs3 5y ago
Does using SPF -all mean that if you send a mail to someone, they won't be able to resend/bounce/redirect that mail to someone else since the resending process uses their mailserver instead?
- arielm 5y ago
  That should be fine. Forwarding means you’ll become the sender so the SPF record of the original sender will no longer apply.
  - pabs3 5y ago
    I'm not talking about forwarding, but resend/bounce/redirect, which means the original sender stays in the From header and the entire email is identical to the original one.
- remram 5y ago
  It breaks forwarding services that don't use SRS [1], for example OVH's. Like you mention, the next hop (example: gmail) will see it coming from the redirecting domain which is not valid per SRF rules. A SOFTFAIL will send a lot of emails to spam, a HARDFAIL means the email might be rejected outright. [1]: https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme I need to move my domains off of OVH...
jarofgreen 5y ago
A note on the PHP script: it will only work if that PHP server has been configured to send email properly. If you just have a random Linux server that someone has run "apt-get install php" on, it probably hasn't been configured and so that command won't do anything. eg https://www.quackit.com/php/tutorial/php_mail_configuration.cfm https://www.quackit.com/php/tutorial/php_mail_configuration.... Ps. Because you can't rely on PHP built-in email functions being configured properly and because apps generally want more control over how email is sent most modern apps will use their own library that makes SMTP connections itself. For example here is Symphony - note the first section on setting up transports: https://symfony.com/doc/current/mailer.html#using-built-in-transports https://symfony.com/doc/current/mailer.html#using-built-in-t...
teddyh 5y ago
There’s a minor technical error in the description of DKIM “happy path”. Here’s what step 4-6 should be: > 3. The Fastmail SMTP server generates a signature using the secret key, and attaches it to the email, along with a ‘selector’ (a string specifying which which of many possible secret keys key it used), then sends the email to example.com's receiving server. > 4. Google email server receives this email. It's from sadl.io and has a fastmail DKIM ‘selector”, so it gets the DNS records for that selector in that domain. > 5. The email has a signature and selector embedded, and the DNS records for the selector in the sadl.io domain declares a public DKIM keys which can be used to verify that signature. > 6. That DKIM keys matches the one used to make this signature. So the DKIM test passes. Crucially, there is no way to list all existing DKIM keys for a domain without knowing all the selector strings. Of course you could do a brute-force search and find a lot of them, but you could never know you found them all without doing a full zone transfer (or if DNSSEC is used with the old NSEC records, which allows enumeration).
teddyh 5y ago
From what I understand, this is incorrect: > SPF and DKIM are used as indicators of whether an email is spoofed or not. But if you added an SPF record on your domain, and you forget to add one of your email systems - say, Postmark, which you use to send mission-critical notifications from your application to your customers - then your customers could stop getting emails. If you added DKIM keys to your domain, but one of your email services doesn't support DKIM - or you forgot to add DKIM keys for that service - your customers could stop getting emails. Setting up DKIM alone for one email service should still allow mails sent by any other email service (i.e. one not using DKIM) to be delivered. (That is, of course, if DMARC is not also set up with a strict policy.) That is to say, DKIM is not that risky to set up and use, by itself.

392 points by simon360 5y ago

The title seems a bit dramatic but I can see how this sort of stuff would throw anyone without a history of network or systems administration for a loop. This is one thing I really enjoyed about setting up ProtonMail with my personal domain. They make it really simple to validate that SPF, DKIM, and DMARC are set up properly.

dang 5y ago
Ok, we've changed it to the (slightly less dramatic?) subtitle. Not sure which is the better choice here...
simon360 5y ago
I didn't realise that ProtonMail had DMARC built in. I'm kind of surprised more email providers aren't including DMARC report analysis out-of-the-box, to be honest. If Google Workspace/G Suite started pushing admins to use DMARC, and provided tools to make it easy, so many more domains would be protected, particularly in startup world.
Jiocus 5y ago
I agree about Protonmail. Never used their service, helped a client straighten their records for a project. No issues. Tutanota are just as straightforward, but they're both in the security game so not much of a surprise there.

lstodd 5y ago

SPF, DKIM, DMARC... all useless. I somehow live without all those for what, since before they appeared. 2001 in fact. With my own MX. They are just ineffective bandaids.

ttul 5y ago
Yet without DMARC, we would be far worse off.
- lstodd 5y ago
  I doubt that.
Denvercoder9 5y ago
83% of spam I received last month failed at least one of these checks, while less than 2% of ham did. They're certainly useful.
- lstodd 5y ago
  IDK maybe it's my tendency to keep a low profile. Or some other perceptual bias. But in last 5 years levels of spam never even remotely approached levels what I remember from 2000s, when my job was actually fighting it (at an ISP). All this tech (SPF, DKIM, DMARC) came and went ... somewhere, and there was exactly zero impact in spam rates on the handful of domains I now maintain, when I did take some time to implement them. Nowadays I have a couple of my own domains, with nothing antispam-configured, and an gmail account, and you know what -- spam amounts almost exactly match. Hence the conclusion - it's not worth it to invest time into it.
  - jpcosta 5y ago
    Maybe try running a business?
Urgo 5y ago
As long as you don't email anyone who uses a gmail address or uses google's email hosting (which is the majority of internet users now?) then you can get away with that. I did too (also having run an MX since around 2001)... but a year or so ago google started filtering all email which didn't comply into spam.. so.. had no choice but to set it up.

jeroenhd 5y ago

I disagree with the idea that SPF, DKIM and DMARC are somehow hard. They're all one-liners in DNS config that can easily be generated with some online tools if you don't want to read the standard. In my experience, correctly configuring mail server software is a lot harder than configuring the DNS to make your email arrive as reliably as possible. Obscure configuration formats are par for the course for almost every mail server setup. I've personally had a much harder time getting DNSSEC to work than I ever had issues with the various email DNS records. Even that is manageable if you're willing to Google around for a while. My solution to getting self-hosted email right is using Mailcow. A cheap VPS (Contabo FTW) plus Docker is all you need to get it to work, and it spits out all the DNS records you might need to add. That also includes autoconfig records for tons of software, which is nice.

imron 5y ago
> They're all one-liners in DNS config $1 - turn the screw $9,999 - knowing which screw to turn
- SilverRed 5y ago
  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.
- thaumasiotes 5y 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.
  - JohannesH 5y ago
    What are the popular platforms for this?

sbuk 5y ago

The thing to remember is that these are useless unless the recipients MTA is configured to take action against failures. Another thing to understand is that very few services, commercial, public or otherwise, send DMARC reports, and many that do send very sparce reports that are as bad as not recieving anything at all. Fundamentally, catching spoofing, phishing and spam and not catching 'ham' is actually really hard.

toast0 5y ago
It's been years since I did it, but I added DMARC to a high volume domain and the reports were useful while I was adding it, to help make sure I didn't forget any authorized senders, but once I got that finalized, the reports were totally unactionable. I can't do anything about the attempted spoofs; I'm not going to track down everyone's open relays, and if I would, DMARC reports aren't really enough anyway. At the time, Yahoo, Google and Microsoft all sent reports, which is a good portion of email, although certainly missing a lot. I think there were a few other smaller names, which I no longer remember. Of course, it almost doesn't matter. Spam/phishing mail to our users still continued, they just stopped spoofing our address. It's not like very many people look at the domain mail claims to be from anyway; modern clients hide it, too.
- nwallin 5y ago
  > they just stopped spoofing our address. This also means that emails from your domain is less likely to get marked as spam, which can be a significant win for smaller domains.

anyfoo 5y ago

I still run my own router at home, and my own servers of various kinds. I put a lot of thought into my packet filter configuration for example, and overall my handwritten router and server stuff comes at a maintenance cost that I am happy to pay. Not so for email. It just stopped being worth it about 10 years ago or so. Regularly fine-tuning your configuration to not only not be marked as spam in originating mails, but to also filter incoming spam, walking the thin line between filtering too much and too little, was just no fun. I looked out for an email provider that provides the flexibility that I'm used to (multiple domains, catchall for subdomains, sieve filtering etc.), pay them a few dollars per month or year, and haven't looked back. My DNS is still homegrown and I handwrite my zones, but the MX just points to my provider.

azornathogron 5y ago

Related: if you have a domain from which you never want to send email, you can also set up these records to tell receivers to reject everything. Here is a guide: https://www.gov.uk/guidance/protect-domains-that-dont-send-email https://www.gov.uk/guidance/protect-domains-that-dont-send-e...

sk5t 5y ago
This is worth doing, as certain "vendor security vetting" services will check these settings on vanity/convenience domains they manage to associate with your organization.
flas9sd 5y ago
I like that concrete mail advice is two subpath levels deep into "the" UK government website. High text contrast, loads fast. Kudos to them.

gloryless 5y ago

lol, that's cause it's mostly for mail coming from your server. You probably don't see any of it

kureikain 5y ago

When implementing spam filtering for my email forward app (https://hanami.run https://hanami.run) I was super confused at DMARC and as the author said. The DMARC keyword were all SEO-focus content by companies that aim for that keyword and didn't clearly give a definition of DMARC. Another confusion is the ARC, the acronym was alike so I though ARC has some relation to DMARC where they are totally different :). I think to help new people understand them, we should stop group DMARC with SPF/DKIM. SPF and DKIM are the thing you set up and you control. But DMARC is just a policy to tell the recipient what they should do if something failed SPF or DKIM. And it's totally up to recipient's mail server to support and follow standard of DMARC.

darkhorn 5y ago

Do you know any free email providers for custom domains that who provide DKIM?

johnklos 5y ago

Thank you. We need more of this. Too many "how-tos" are written with too many assumptions and not enough common sense, straightforward explanations. I've set up and run all of these, but that doesn't mean that it doesn't frustrate the heck out of me whenever I have to deal with them. A good, handy reference like this will be quite useful.

max1cc 5y ago

This is a really nice article! Just so you know, it says that Postmark doesn't offer a DMARC service, but they actually offer two: Free DMARC Monitoring (https://dmarc.postmarkapp.com/ https://dmarc.postmarkapp.com/) and DMARC Digests (https://dmarcdigests.com/ https://dmarcdigests.com/)

simon360 5y ago
Well this is embarrassing. Thanks for pointing that out - I've corrected the article and cited you.
- max1cc 5y ago
  My pleasure! Sorry to be pedantic :)

shirro 5y ago

A controversial headline and a bit of opinion creates controversy and gains views. Once this sort of information would be written in a plain text HOWTO and posted to usenet but now we have to clickbait everything so it gets posted to HN. SMTP is hopelessly naive by the standards of today as it was designed to work in a much smaller and more trusted environment. The additional reputation protocols are well intentioned and work well if the receiver acts on them and are not at all silly or unholy. They are not difficult to configure but neither are they as simple as a redesigned protocol might be. If you don't need to setup your own mail servers or have a desire to develop and maintain skills in that area then use a pre-configured service. Otherwise I am fairly sure that configuring these things is far simpler than most trade skills. I don't think there is any comparison between the time it would take to read some docs and add a few lines to a config file and learning to become a proficient welder. If you work with servers and want to be good at your craft I think email is still one of the services people should know how to configure and secure.

agotterer 5y ago

I use a service called OnDMARC (https://ondmarc.redsift.com/)for https://ondmarc.redsift.com/)for managing email spoofing/delivery. They have a suite of tools for managing and monitoring spf/dkim/dmarc. Nothing you couldn’t do yourself, but they make it easy. They also have a couple of cool extras like “dynamic spf” which lets you expand beyond the standard spf record length.

leetrout 5y ago

> And never forget to use -all And yet even Googles docs recommend ~all. If you're using 3rd party bulk senders you probably want to consider the cost and benefit of -all vs ~all https://support.google.com/a/answer/10684623?hl=en https://support.google.com/a/answer/10684623?hl=en

aj3 5y ago
3rd party bulk senders likely know more about mail delivery than you do. Also DMARC aware recipients will treat ~ALL in SPF exactly like -ALl.

jchook 5y ago

DMARC basically breaks mail intermediaries and is fundamentally problematic, hence the low adoption rate. ARC is a much better alternative that builds on DKIM and allows intermediate custodians of mail.

azinman2 5y ago
What does intermediate custodian mean here? Something like sendgrid? Is there an issue for normal peoples email on custom domains (eg fastmail or gmail hosted)?
- toomim 5y ago
  I think he is talking about mailing list servers. When you email mailman, it'll add a line to the bottom of the email, manipulate some to: and cc: headers, and forward it along. This changes the hash of the email which breaks some crypto signatures.
aj3 5y ago
No it doesn’t, unless said intermediaries are modifying contents and are not DMARC aware. Many European countries are forcing DMARC adoption for government infrastructure and it works just fine.

mmcclimon 5y ago

> Normally, this means that spf.messagingengine.com has its own SPF DNS record, which will probably list some valid IP addresses that emails can be sent from. There's also one for Mandrill, for transactional emails. You can have as many of these as you want. This isn't strictly true (that you can have as many as you want), because SPF has a (IMO) very silly hard limit of 10 DNS lookups per record. From RFC 7208: > Some mechanisms and modifiers (collectively, "terms") cause DNS queries at the time of evaluation, and some do not. The following terms cause DNS queries: the "include", "a", "mx", "ptr", and "exists" mechanisms, and the "redirect" modifier. SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return "permerror". We see this not infrequently at Fastmail, when customers report DMARC validation problems, and the answer turns out to be that they've got too many includes in their SPF records, so SPF always fails.

technion 5y ago
That limit of ten is extremely easy to meet when someone casually says "Hey we've started using Freshdesk for ticket tracking, setup DNS please". Ok so you include:email.freshdesk.com. That record itself includes four other freshemail.io DNS lookups, and sendgrid.net, which includes another one. So you're seven DNS lookups in just for that. Gmail's recommended include:_spf.google.com includes four more, at which point the limit is exceeded and SPF is broken.
- mmcclimon 5y ago
  Yeah, for sure! Outlook is also very bad about this, and usually when we see it people have added include:spf.messagignengine.com (Fastmail's SPF, which is all IP addresses) and one other include, which does a bunch of recursive lookups. This is often very difficult to explain to people, and there's not even really a way to work around it, short of using different domains for different sending needs (which many people are unwilling or unequipped to do).
  - Hello71 5y ago

upofadown 5y ago

Some companies just mark incoming email with something like [external] to solve the problem used as an example. In the end you are going to know if an email came from your own server, you are the one sending them. If it is really that important, businesses should be signing their emails.

aj3 5y ago
Eh, DMARC is meant to solve different problem. E.g. when your accountant receives spoofed mail with a fake invoice supposedly coming from a legit supply chain provider. They might be trained to check domain that was used to send email but without DMARC non-techies won’t be able to notice well made spoofed email.
- upofadown 5y ago
  Assuming that the email client used even shows the domain. If you can train your employee to do an obscure technical check you can for sure train them to verify invoices. After all, if you don't then the legit supply chain provider can just generate fake invoices.

johngalt 5y ago

SPF = This list of servers are authorized to send email for my domain. DKIM = This specific email can by verified/authenticated by my DNS. DMARC = What to do with email that doesn't comply with above. And how to tell me about it (if you want to). SPF is basically useless due to the centralization of email providers. It was created to be locked to a company specific email server. E.g. Only accept mail from exchangeserver.company.com, and reject everything not from that server. Now everyone authorizes Microsoft or Google to send their mail.

judge2020 5y ago
Technically SPF is still useful if you trust that Microsoft and Google aren't allowing arbitrary email to be sent from non-verified email addresses, which it seems both do (although neither seem to require periodic re-verification).
aj3 5y ago
SPF (alone) is useless because it actually does not check the sender's domain in the From header (as one might naively think). Instead it only verifies Envelop Sender which can differ (intentionally) from the mail seen in From header.

contravariant 5y ago

> nothing demonstrates this more simply than this PHP script Arguably there's nothing more clear than writing it manually over telnet. If you haven't done so yet it's kind of fun to try it out once.

deleted 5y ago

[deleted]

andrewmcwatters 5y ago

I'm less upset with SPF, DKIM, and DMARC and more irritated that you can't find any 5 minute guide on how to set it up. As this article states, it's all SEO bullshit and DNS validators that don't explicitly say, "Add this TXT record to your DNS set. This directive means X. That directive means Y." Unfortunately, as much as I sympathize with this article, I can't pass this around to colleagues as technical reference, because it's just a rant. A rant with helpful information, but a rant nonetheless. I need reference documentation that isn't going to disappear when the author decides to change blogging platforms, etc. So, below are the RFCs, with sections, that actually matter. DKIM and DMARC are not required to have a functional piece of software that sends emails today, though. Just use SPF and you should be fine. A TXT record with @ for the current origin[1] or the relevant host with the following is sufficient[2]: v=spf1 include:example.com ~all You can use multiple includes. If you're pointing to your own DNS records, though, don't use include. Use a. As far as I understand it: include[3] is others, or as RFC 7208 states it, 'independent domains.' a[4] is you (A records). In this case, it looks like this: v=spf1 a:mydomain.com ~all That's it. Now your mailer should work. So for example, you've got a domain name on Namecheap, and you're hosting on a VPS. You've pointed your A record for @ to your VPS' IP address. That's all you need there, and all you need for SPF is a TXT record pointing for the current domain, @, and the string above, with the a mechanism pointing to your domain name. SPF-compliant software will look up your TXT record containing the SPF string, see the domain, lookup its IP address, and match it to the server where your email is coming from, then allow it in transmission. Popular mailers should tell you all this these days, but they don't, and it really sucks. [1]: https://datatracker.ietf.org/doc/html/rfc1035#section-5.1 https://datatracker.ietf.org/doc/html/rfc1035#section-5.1 [2]: https://datatracker.ietf.org/doc/html/rfc7208#section-3 https://datatracker.ietf.org/doc/html/rfc7208#section-3 [3]: https://datatracker.ietf.org/doc/html/rfc7208#section-5.2 https://datatracker.ietf.org/doc/html/rfc7208#section-5.2 [4]: https://datatracker.ietf.org/doc/html/rfc7208#section-5.3 https://datatracker.ietf.org/doc/html/rfc7208#section-5.3

vgb2k18 5y ago
> That's it. Now your mailer should work. Work... technically... yes. If the definition of 'works' is: "I press send and sometimes my email reaches it's destination". The spirit of the article IMO implies a definition akin to "I press send and my email reaches it's destination. And... my emails have some protection against spoofing attacks". So in the spirit of the article, I would recommend your 1-liner takes a small yet significant change: v=spf1 include:example.com -all Now... let's talk about biggest barrier to entry for n00bs (myself included) in the self-hosted email game: non-blacklisted ip-address space. And blacklist here refers not just to public lists (SPAMHAUS etc) but private ones too (e.g., outlook).

na85 5y ago

>Then, I encountered a second problem: I had no idea what those were, and seemingly nobody has written about SPF, DKIM, or DMARC in a way that a human can understand, not to mention implement. Every article I found was either highly technical, trying to game SEO to sell me something, or too high level to be useful. I guess TFAuthor hasn't done a cursory google search, because if they had they'd have found the ISPmail tutorial[0] which is clear, concise, mostly correct, and approachable if you aren't a total novice to Linux. [0] https://workaround.org/ispmail https://workaround.org/ispmail

dataflow 5y ago

Can someone explain why you can assume a recipient would respect DMARC when dealing with SPF but not check your DKIM? It never made sense to me why we need anything other than DKIM honestly.

aj3 5y ago
Sure. Parsing DMARC requires understanding DKIM as well, so what you’re asking is a non issue. That said DKIM is not enough because that standard does not have a way to signal recipient that your domain has DKIM set up in the first place (and you promise that all your mails should always be signed). It’s kind of funny but essentially hacker does not need to spoof DKIM because they can just omit it and recipient won’t be able to know that it should have been present in the first place. Btw, there was proposal to add a feature that could be used for this signaling but it didn’t get adopted, so DMARC is the only practical solution right now.
- dataflow 5y ago
  > Btw, there was proposal to add a feature that could be used for this signaling but it didn’t get adopted, so DMARC is the only practical solution right now. Wow, thanks. That definitely explains this mess. Do you know why it didn't get adopted? I'd have thought that in a sane world all you'd need is to literally have a DNS record that specifies the DKIM info... pretty simple. Why on earth did people find it more convenient to do it in such a convoluted fashion instead? Especially now that there's ARC too, which I'd have thought shouldn't be necessary either.
  - aj3 5y ago
    Corporate politics and death by committee. These standards were created by many parties with conflicting interests. My understanding is that they couldn't agree on an exact way From header should be checked and thus deferred all policy aspects to further standard. If you read DKIM RFC it actually only specifies how to sign and verify the email signature, but does not mandate exact checks recipient should do to figure out authenticity. E.g. technically Microsoft could send mail from @gmail.com address and use "d=outlook.com" in the signature - the signature would be valid, but obviously it wouldn't make it authentic (meaning such mail wouldn't be authorized by Google). Although common sense dictates that there should be some sort of connection between domain seen in From header and the one that's DKIM-signing the mail (and most real-world implementations will do some kind of checks), RFC deliberately does not standardize these steps. The intended standard that should have clarified these issues was ADSP, but it wasn't well received and now we have DMARC which handles both SPF and DKIM together (this is better for deliverability as mails that fail one of these checks might still pass another).

tamu_nerd 5y ago

Also infuriating: Not all email services treat DMARC in the same way, or way you'd expect (eg: O365 will by default deliver a p=reject to spam https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/use-dmarc-to-validate-email?view=o365-worldwide#how-microsoft-365-handles-inbound-email-that-fails-dmarc https://docs.microsoft.com/en-us/microsoft-365/security/offi...)

geocrasher 5y ago

I'm going to refer to this post whenever says "running your own mail server is easy!". I suppose that if you already know how to run your own mail server and are familiar enough with all the moving parts, sure, it's easy. But if you have a problem that needs to be solved, and you think the answer is running your own mail server, you now have two problems. The "unholy combination of silly standards" is an excellent way of putting it, but it goes back to the 1970's. SMTP was originally based on FTP. Anonymous FTP, at that. It was designed to send text- nothing more. And really that's all it can do still. We can thank Base64 for binary attachments that are at 30% bigger than their unattached size. Yeah, mail is a problem. And it always will be because it's a 50 year old technology that was designed for a collection of a few hundred servers ran by technologists who trusted each other. SPF, DKIM, and DMARC (and literally everything after except for "send text to so and so") is an afterthought.

Semaphor 5y ago
These aren’t even "run your own mail server" territory. It’s stuff that you already need to worry about when simply using your own domain.
NorwegianDude 5y ago
Running a mail server is very easy. Setting it up to begin with is the hardest part. Email isn't exactly moving fast, so it's basically set and forget if you don't have to deal with it on behalf of untrusted parties. That said, a technically inclined person would probably be able to set up a server in a day or three and understand the basics of how it all ties together. Just because not that many people understand how to set it up doesn't make it hard. But it's definetly showing it's age and could be much simpler to use.
- aj3 5y ago
  It’s definitely not set and forget. In the past year alone there where multiple 0day attacks against Exim and MS Exchange servers.
Tepix 5y ago
Use sovereign instead of setting everything up by yourself. You should know the basics of linux system administration, however

kro 5y ago

The article is good, but misses an important point (that adds yet another confusing thing about email): the difference between Header.From and Envelope.From and how DMARC also solves this by requiring identifier alignment. Without it, generally only partial validation of the envelope address happens by i.e. SPF.

gorgoiler 5y ago

Can SPF, DKIM, and DMARC be CNAMEs? It’s a little bit easier when one can move all this stuff onto one host, away from the rest of ones infra, especially when it comes to distributing DKIM keys. I wouldn’t be surprised if there’s also a mail daemon that also did DNS for you. Everything in one simple MTA. Begone, Exim4 mega config and update-exim4.conf.conf.conf!

teddyh 5y ago
DKIM and DMARC can be CNAMEs, but not SPF, since SPF lives at the apex domain name, which can not be a CNAME. (Of course, if your email address is on a subdomain, then that can be a CNAME. But then the MX records will also have to be moved to the CNAME target.)
- marcbradshaw 5y ago
  Not even then, RFCs state that a CNAME may not exist with any other RR type, and your apex domain needs at least SOA and NS records. A CNAME on the apex domain may kind of work, but it will present as broken in subtle and unexpected ways.
  - teddyh 5y ago
    Um, what? I think you misunderstood me. Or you are unaware that DMARC and DKIM records live on subdomains.
marcbradshaw 5y ago
DKIM and DMARC can be CNAMES, many services already use this, at Fastmail for example for DKIM you setup CNAMES, and we manage DKIM keys for you. SPF needs to be on your (root/organizational) domain, and you don't want (can't have) a CNAME there.

pabs3 5y ago

Does using SPF -all mean that if you send a mail to someone, they won't be able to resend/bounce/redirect that mail to someone else since the resending process uses their mailserver instead?

arielm 5y ago
That should be fine. Forwarding means you’ll become the sender so the SPF record of the original sender will no longer apply.
- pabs3 5y ago
  I'm not talking about forwarding, but resend/bounce/redirect, which means the original sender stays in the From header and the entire email is identical to the original one.
remram 5y ago
It breaks forwarding services that don't use SRS [1], for example OVH's. Like you mention, the next hop (example: gmail) will see it coming from the redirecting domain which is not valid per SRF rules. A SOFTFAIL will send a lot of emails to spam, a HARDFAIL means the email might be rejected outright. [1]: https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme I need to move my domains off of OVH...

jarofgreen 5y ago

A note on the PHP script: it will only work if that PHP server has been configured to send email properly. If you just have a random Linux server that someone has run "apt-get install php" on, it probably hasn't been configured and so that command won't do anything. eg https://www.quackit.com/php/tutorial/php_mail_configuration.cfm https://www.quackit.com/php/tutorial/php_mail_configuration.... Ps. Because you can't rely on PHP built-in email functions being configured properly and because apps generally want more control over how email is sent most modern apps will use their own library that makes SMTP connections itself. For example here is Symphony - note the first section on setting up transports: https://symfony.com/doc/current/mailer.html#using-built-in-transports https://symfony.com/doc/current/mailer.html#using-built-in-t...

teddyh 5y ago

There’s a minor technical error in the description of DKIM “happy path”. Here’s what step 4-6 should be: > 3. The Fastmail SMTP server generates a signature using the secret key, and attaches it to the email, along with a ‘selector’ (a string specifying which which of many possible secret keys key it used), then sends the email to example.com's receiving server. > 4. Google email server receives this email. It's from sadl.io and has a fastmail DKIM ‘selector”, so it gets the DNS records for that selector in that domain. > 5. The email has a signature and selector embedded, and the DNS records for the selector in the sadl.io domain declares a public DKIM keys which can be used to verify that signature. > 6. That DKIM keys matches the one used to make this signature. So the DKIM test passes. Crucially, there is no way to list all existing DKIM keys for a domain without knowing all the selector strings. Of course you could do a brute-force search and find a lot of them, but you could never know you found them all without doing a full zone transfer (or if DNSSEC is used with the old NSEC records, which allows enumeration).

teddyh 5y ago

From what I understand, this is incorrect: > SPF and DKIM are used as indicators of whether an email is spoofed or not. But if you added an SPF record on your domain, and you forget to add one of your email systems - say, Postmark, which you use to send mission-critical notifications from your application to your customers - then your customers could stop getting emails. If you added DKIM keys to your domain, but one of your email services doesn't support DKIM - or you forgot to add DKIM keys for that service - your customers could stop getting emails. Setting up DKIM alone for one email service should still allow mails sent by any other email service (i.e. one not using DKIM) to be delivered. (That is, of course, if DMARC is not also set up with a strict policy.) That is to say, DKIM is not that risky to set up and use, by itself.