(ISC)² Community users, Please be aware, the email address used to send automated notifications from the community will be changing to the following address: firstname.lastname@example.org. The purpose of this change is to conform to best practices and to ensure email deliverability. This change will occur on June 21, 2021.
Re: Community Notifications Email Address to Change
Wanted to share some background on why I suspect (ISC)² is making this change. I encourage you to check your own company to see if you can leverage the lessons that I learned and that (ISC)² is presumably learning.
First, SPF (email source validation) has a limit of 10 DNS queries per invocation. As currently written, (ISC)²'s SPF is right at this limit. I would bet money that (ISC)² has occasionally gone over this limit, resulting in customer (member) complaints that expected email was not arriving. To check your own zone check out https://dmarcian.com/spf-survey/.
Second, "@isc2.org" authorized senders has at least 6 vendors authorized to send email forged from any (ISC)² employee. By creating separate "domains" for each vendor (@notifications.isc2.org; @salesforce.isc2.org; @events.isc2.org, etc), separate accountability is maintained for each vendor. Ideally, (ISC)² will eventually whittle it down to only o365 being authorized to send email under their employees' addresses (e.g. @isc2.org). Plus, it bifurcates the SPF query-limit issue.
Third, DNS has a size limit. "Normal DNS" uses UDP which is limited to 512 byte answers. When people look up "isc2.org", the answer is 645 bytes long. Therefore, queries must be repeated using TCP. Although this is a perfectly acceptable part of the standard, it is also encountered relatively rarely. Therefore, one is using code in browsers, operating systems firewalls, etc. that is much less thoroughly tested. As a result, (ISC)² is likely involved in much more than their share of issues with customers connecting to (ISC)².
In large part, this is caused by (ISC)² having at least 9 site-verifications tied to isc2.org (e.g. isc2.org txt MS=ms94814359). Although site verification is a "good thing", it also increases (ISC)²'s risk as I now know who I need to impersonate for a good phish. The solution is to ask your vendors to support putting the domain validation on its own record (e.g. ms.isc2.org txt MS=ms94814359) and also to remove the record immediately after validation has been completed.
Please note that the above is based on my similar experiences. I do not have any particular insight into the inner workings of (ISC)².