I can answer for SP on-premises in a Windows-Claims authentication environment (fairly common for SP 2013-2019). You can't delegate permission in SharePoint to an AD distribution group - it has to be an AD security group, which can and often is email-enabled.
When users are added or removed from an AD security group, their access will be granted or revoked accordingly in SharePoint.
Be advised there has been a somewhat common yet obscure issue with this, however. If an AD group has access to a site, and a user is not in that group but tries & fails to access it, but then they are added to the AD group, they may fail to get access on the following try. The opposite is true for revoking access, where a user could have access after they've been removed from the group if they had already been using the site.
That's because SP's distributed cache creates a logon token for the user on the first try, and that token (or a subset of it) is temporarily stored in the content database where the site lives. That means the user may have access to a site that's in one content DB but no access to a different site that's in a different content DB during the time when the old token is still cached, even though the same group controls access in both sites.
Depending on the farm's distributed cache config, the token may not get refreshed for several hours or overnight. It's possible to modify the logon token cache timeouts, but in my experience, it doesn't always achieve the desired results.
Hopefully you won't run into this, but wanted to mention it, as it may influence your test results if it happens. Good luck!