The original Japanese version is available here.
Something wonderful happened today. The Japanese national soccer team did it! After defeating the powerful Germany, they defeated the unbeatable Spain fleet and passed the group stage as first place. They showed us an amazing game that made us think what happened in that Costa Rica match. I was planning to wake up at 4 in the morning for the Spain game, but a 2-hour countdown program started at 2 o’clock, and I ended up staying up all night. I thought Japan was shaking with excitement when Japan won, but my wife who was watching TV in her room seemed to be making noise 🙂 Anyway, congratulations!
In the previous session, we looked at the configuration of sendmail for email sending. We unified the email header for outgoing emails, enabled encryption, allowed SMTP AUTH to pass, added DKIM signatures, and performed virus checks. Now, if someone tries to send an email from somewhere else by claiming an email address, the DKIM header will not be present or the DKIM check will fail. But is that all? When the DKIM check fails or the email doesn’t pass the DKIM check, can’t it still look normal? Yes, that’s right. The recipient side needs to know what to do in case DKIM and/or SPF checks fail from the sender side via DNS. This is called DMARC. Therefore, there is no need to do anything on the sending server side. All you need to do is add a TXT record for DMARC in the public DNS, just like for DKIM. Conversely, DMARC is the only way to avoid a DKIM fail. The DNS configuration for DMARC looks like this.
What DMARC is looking at is the results of the DKIM and SPF verification. As long as both are pass, it’s fine, but if a value other than pass is recorded in either or both, the recipient will process it according to the instructions in the DMARC DNS. Of course, this only applies to email platforms that support DMARC. If it doesn’t, the email will arrive in the mailbox normally. So, DMARC is a technique for preventing email spoofing that can only be realized by cooperation between the sender and the recipient. However, neither party’s administrators need to coordinate to do anything. It is realized by publishing information in the DNS and processing based on the published information. In the example above, it is quarantine, so the recipient will receive the email but be isolated in a different folder for spam, etc. Of course, if DMARC is supported. DMARC will perform processing to block emails that have been received until now, so by setting this DNS record, it is possible to gradually and strictly process it. There is nothing to be done on the server side, so I would like to write a little about DMARC options
DMARC is standardized as RFC7489, which is a RFC and can be referenced by anyone. If you refer to this RFC, you will understand the details. I will introduce some options. Valid keys are written in the DMARC Tag Registry in Section 11.4 of RFC7489, and the values each key can take are written in Section 6.3 of General Record Format. The most important key is ‘p’. If this is ‘none’, it means that regardless of the results of DKIM or SPF, nothing is done. In this state, you can continue to test and gradually become more confident, then specify stricter processing such as quarantine or reject. With ‘rua’ and ‘ruf’, you can receive reports from the recipient side to the domain owner or administrator by email about the DMARC status. And ‘v’ allows you to specify the DMARC version. This default does not exist, but it is a necessary option, so currently it must be DMARC1, but in the future if there is a change in the standard, DMARC2 or DMARC3 may appear.
Next, the SPF DNS is set up like this.
SPF is also standardized as an RFC, which can be viewed by anyone as RFC7208. In the above example, it is very simple, ‘v’ is the version of SPF and currently, only ‘spf1’ exists. In the future, new standards may emerge such as ‘spf2.’ ‘a’ means that the IP address of this machine name is OK. If you want to specify using the IP address instead of the machine name, use ‘ip4’ or ‘ip6.’ If you especially want to specify using a network address range, this is your only option. ‘mx’ means that the IP address registered in the DNS MX record of this domain is OK. Finally, ‘all’ means anything else. So, ‘all’ always appears at the end. The ‘~’ before ‘all’ means Soft Fail. So, if it’s an address of xxx.bbb.ne.jp or an address registered in mx, the SPF check will pass. In the case of a large organization with many mail servers, this DNS record may be nested with include statements. The mail server we are setting up for testing this time will always send mail via the ISP mail server, so there is no need for the SPF record to contain the IP address.
If you haven’t yet implemented DMARC, I believe the first thing you should do is set up the DMARC DNS. Of course, the ‘p’ and ‘sp’ should be ‘none’ and you can write your own email address in ‘rua’ or ‘ruf’. This will allow you to receive reports on how much fraudulent mail using your domain is circulating in the world. You may not be aware that fake emails are being sent from your site, but by setting this up, you will receive reports of fake emails from all sites that support DMARC. You may be shocked, but if someone tries to send an email by pretending to be you, they will definitely check whether there is any DMARC DNS information first. In fact, even if there is no setting, just having DMARC configuration may exclude fake email addresses from the candidate list.
Although the adoption rate of DMARC has been gradually increasing, it still has a long way to go. If you search for keywords such as “DMARC situation” in the past month, you will find many articles. I think the adoption rate is about 50% for large domestic companies and about 20% if you include small and medium-sized companies. Nothing is difficult to understand if you read what is written, so why not spread its adoption to eliminate unnecessary traffic and restore fast internet?
Advertisement below
コメント