> 2021年08月18日信息消化 ### Email Authenticity 101: DKIM, DMARC, and SPF origin: [Email Authenticity 101: DKIM, DMARC, and SPF](https://news.ycombinator.com/item?id=28194477) If you use email with your own domain, a lot of the burden of authenticity has suddenly shifted from your service provider to you. This guide will hopefully give you the information and practices you need to keep your domain's email authentic and less vulnerable to spoofing. 如果你用你自己的域名使用电子邮件，很多真实性的责任突然从你的服务提供商转移到你身上。本指南希望能给你提供你所需要的信息和做法，以保持你的域名的电子邮件的真实性，减少被欺骗的可能性。 We'll cover the three major components of modern email domain security: **DKIM** for signing, **SPF** for sender verification, and **DMARC** for stricter enforcement of the other two. It is assumed the reader has a basic understanding of DNS and has experience using email with their own domain. 我们将涵盖现代电子邮件域名安全的三个主要组成部分。**DKIM**用于签名，**SPF**用于发件人验证，以及**DMARC**用于更严格地执行其他两项。假设读者对DNS有基本的了解，并且有使用自己域名的电子邮件的经验。 #### 1. SPF SPF, or **Sender Policy Framework**, is one of the most basic email verification technologies, and is the easiest and more common protection. Often service providers will give you the DNS record contents you need to simply copy-paste during setup. It takes the form of a DNS `TXT` record on whatever domain you are sending email from. It looks something like this: ``` "v=spf1 include:spf.messagingengine.com -all" ``` At its core, SPF is just a list of IP addresses that are authorized to send email from your domain. This can be of a few different forms: - Most commonly, `include:` which does a recursive lookup to include all the IPs from a different hostname. - Also common is `ip4:` and `ip6:` for referencing IP addresses directly. - Finally we have the special `all` mechanism, which is a wildcard catch-all that matches, well, all IP addresses. This is primarily used to blocklist everything by default, which we'll explain more below. For our example above, `spf.messagingengine.com` has a couple dozen `A` records on it which are included for this SPF policy via the `include:` mechanism. And that is all there is to it. SPF is a very simple tool, but provides the very base level of email verification ("what IPs are allowed to send my email") necessary to do basic spam filtering. Even just setting up SPF alone should help significantly with your delivery success. #### 2. DKIM DKIM, or **Domain Keys Identified Mail**, is another security mechanism that uses asymmetric keys to cryptographically verify the server sending email for your domain is authorized to do so. With DKIM configured, the server receiving your mail can look up the public key in DNS and validate the email was legitimately sent from your domain. DKIM，即域名密钥识别邮件，是另一种安全机制，它使用非对称密钥来加密验证为你的域名发送电子邮件的服务器是否被授权这样做。在配置了DKIM之后，收到你的邮件的服务器可以在DNS中查找公钥，并验证该邮件是由你的域合法发送的。 DKIM protects against IP's changing hands, or large service providers sharing IP space between customers. If you say, "Google IPs can send my email", what's stopping someone else from spoofing email from your domain and sending it from their own Google account? Since those IPs are shared, it will still pass SPF checks, but it *will not* pass DKIM. DKIM可以防止IP的易手，或大型服务提供商在客户之间共享IP空间。如果你说，"谷歌的IP可以发送我的电子邮件"，那么有什么可以阻止别人从你的域名欺骗电子邮件并从他们自己的谷歌账户发送呢？由于这些IP是共享的，它仍然会通过SPF检查，但它不会通过DKIM。 There are two main pieces to DKIM: a DNS record with the public key, and a header added to every sent email with cryptographic signatures and details on how to find the aforementioned DNS record. DKIM有两个主要部分：一个是带有公钥的DNS记录，另一个是添加到每封发送的邮件中的标题，其中包含加密签名和如何找到上述DNS记录的细节。 The DNS record is just a normal `TXT` record, but under a special name. The generic format is: DNS记录只是一个普通的TXT记录，但有一个特殊的名称。通用的格式是。 ``` <selector>._domainkey.<domain> ``` The "selector" is generally set by your email service provider and will be provided to you when you enable DKIM with them. Some providers, like Fastmail and Microsoft 365, even provide multiple selectors for you to set. For example, for Google it's just one, "`google`": ``` google._domainkey.example.com ``` Lately these domain key records have been moving to `CNAME`'s to a service provider domain to make configuration easier, and allow the service provider to rotate keys without making you update your DNS. For example, both Fastmail and Microsoft 365 have switched to `CNAME`, though Google is still providing keys directly. These selectors and DNS records don't mean much unless the receiving server knows how to find them, though. Which brings us to the DKIM headers. DKIM headers are added to every email you send, and contain [a few important details](https://datatracker.ietf.org/doc/html/rfc6376#section-3.5). The two major ones we're interested in here are: 1. `**d=<domain>**` lists the sender's domain name for verification. 2. `**s=<selector>**` is the "selector", matching the DNS subdomain. With these two pieces of metadata, the receiving server can rebuild the subdomain containing the DKIM key and resolve it. Taking this key, they can then cryptographically verify the DKIM signature and validate if the message is authentic or not. DKIM is a much stronger signal than SPF for detecting spam, as there is actual maths involved and not just an IP list. If all you do is configure SPF and DKIM, you're in a pretty good place, however we can take it a step further. #### 3. DMARC You may have noticed that DKIM only applies if there is a header in the message. This means that illegitimate messages will not have the header, and thus no DKIM validation will happen. This results in the DKIM validation being "neutral" instead of a "failure", as it was simply omitted. Adding a DMARC policy allows us to - enforce SPF and DKIM checks on *all* emails claiming to be from our domain; - give hints to the receiving server on how to handle failed checks; - provide a reporting address so we can receive reports about these checks in the wild from email providers. A DMARC record is the same format as the other two, and is also pretty simple. Here's an example of a very basic, permissive policy: ``` v=DMARC1; p=none; adkim=r; aspf=r; ``` Please don't actually use this policy, it won't do anything for you. But it gives us a place to start explaining all the bits. - **`p=none`** sets our "global policy" for handling emails that fail authentication checks. This can be `none`, `quarantine`, or `reject`. - **`adkim=r`** sets our policy for enforcing DKIM checks. This can be `r` ("relaxed") or `s` ("strict"). - **`aspf=r`** sets our policy for enforcing SPF checks. This takes the same values as `adkim`. ``` v=DMARC1; p=quarantine; adkim=s; aspf=s; rua=mailto:re+someidentifier@dmarc.postmarkapp.com; ``` At this point, you have a very strong policy, and this is a perfectly fine place to leave it. If you are particularly paranoid, you can move up to `p=reject` which will instruct the receiving servers to throw out all email that fails authenticity checks, keeping it out of the recipient's mailbox entirely. This can be a bit dangerous, as there is no recourse if legitimate email accidentally fails a check, it's just gone forever, but is technically the most secure policy. 在这一点上，你有一个非常强大的策略，这是一个完全可以留下的地方。如果你特别偏执，你可以提高到p=reject，这将指示接收服务器扔掉所有不能通过真实性检查的邮件，把它完全留在收件人的邮箱之外。这可能有点危险，因为如果合法的邮件不小心没有通过检查，它就会永远消失，但从技术上来说，这是最安全的政策。 DMARC is the most powerful piece of modern email security, and its reporting can be incredibly insightful into what spam is out there pretending to be you. If you take anything from this guide, I hope it is that you should take the time and care to set a strict DMARC policy. DMARC是现代电子邮件安全中最强大的一环，它的报告可以令人难以置信地深入了解哪些垃圾邮件在那里假装是你。如果你从本指南中得到什么，我希望是你应该花时间和精力来制定一个严格的DMARC政策。 #### Bonus: domains without email SPF and DMARC don't just apply to domains with email configured. A good practice is to configure highly-restrictive blocking policies for any domains you have that do not send email. This will ensure anyone trying to spoof email as that domain gets blocked immediately. For all of my non-email domains I set this "block all" SPF record: ``` v=spf1 -all ``` And I set a DMARC policy that hard-rejects all email that fails SPF or DKIM (which will be everything): ``` v=DMARC1; p=reject; adkim=s; aspf=s; ``` Just these two empty-looking records are enough to prevent any spam being sent in your name from a domain you didn't even expect to send email. ---- 一直很奇怪为什么b-monster.jp的sengrid可以直接设置用户的邮件为发件人... SPF: PASS with IP x.x.x.x. 'PASS' with domain b-monster-jp.20150623.gappssmtp.com 还有个比较可疑的是 b-monster.jp的一个TXT记录 ``` "google-site-verification=xxxxxxxxxxxxxxxxxxxxxxxxxxx" "v=spf1 include:_spf.google.com ~all" "facebook-domain-verification=xxxxxxxxxxxxxxxxxx" ``` 而toyvox的则是 ``` "google-site-verification=xxxxxxxxxxxxxxxxxx" ``` 没有spf1的部分 > HN Comment: Another tip for domains that don't send email: set a null mx record. This explicitly tells sending servers that your domain does not receive mail, and isn't just broken. Create an mx record priority 0, with a dot (.) for the value. ### Work backward from the vision -- Ed Gandia Most of us solve problems by mapping out small, incremental steps to get from where we are to where we want to be.But this model doesn’t work well when it comes to making really huge improvements.Why? Because those kinds of improvements can’t be mapped out so cleanly. So, when you’re facing a massive challenge—such as making BIG changes in your business—it’s better to start with your vision and work backward.It’s a counterintuitive approach.You have to have faith—faith that the best solutions will unfold as you move in the direction of your dream.But if you look around, you’ll see that this is how super-successful business founders (and leaders of major societal movements, for that matter) often work to effect serious change. 我们大多数人解决问题的方法是制定小的、渐进的步骤，从我们所在的地方到我们想去的地方。但是，当涉及到做出真正巨大的改进时，这种模式并不能很好地发挥作用。为什么？因为这类改进不可能如此简单地被规划出来。 因此，当你面临一个巨大的挑战时--比如在你的业务中做出巨大的改变--最好从你的愿景开始，然后向后努力。这是一个反直觉的方法。你必须要有信心，相信在你朝着梦想的方向前进时，最好的解决方案会展现出来。但是，如果你环顾四周，你会发现这就是超级成功的企业创始人（以及主要社会运动的领导人）经常致力于实现严重的变化。 ### 一点收获 - [The Best Thing You Can Do After You Eat Too Much](https://kokumura.medium.com/the-best-thing-you-can-do-after-you-eat-too-much-d0db6265609) - “I love to tell people, if you get a flat tire you don’t get out of the car and slash the other three tires. You patch the tire and get back on the road.” — Jillian Michaels, American personal trainer Sometimes laughing about it and moving on is the best thing you can do after eating a bit too much. - [A future for SQL on the web](https://news.ycombinator.com/item?id=28156831) - sql.js + IndexedDB + [absurd-sql](https://github.com/jlongster/absurd-sql) - web’s storage APIs