Right now, the [[domain]] tag on domain spoofing emails cannot be modified. However, there are a number of templates in existing libraries that have templates using this feature, which is problematic for those who don't want to send users domain spoofing emails.
External emails that spoof our domain are blocked automatically by our spam filtering service and we carefully monitor the email sending behavior of internal accounts in order to mitigate the impact of account takeovers. If users cannot trust internal domain emails and are forced to treat them with the same scrutiny as external emails, we risk our IT department being overwhelmed by users asking us to validate the legitimacy of perfectly valid emails, sent from other internal users. This reduces our IT department's ability to respond to real phishing threats and reduces user productivity.
We understand that internal threats are possible and users should in theory be as suspicious of internal emails as they are of external ones. Its our determination that the cost of having users act with such skepticism is not worth the potential benefits, especially given the other security measures we have in place to prevent internal domain spoofing.
There are several ways to address this:
- Move domain spoofing emails in to their own categories: This increases the number of categories, but does not reduce functionality for users and requires no development effort to implement. This is the easiest option.
- Allow users to "Enable / Disable phishing email templates based on certain attributes". This requires development work, but effectively resolves the problem, along with other potential problems users might have.
- Allow users to change the default [[domain]] value. This would be useful because we could change the domain value to a misspelling of our domain, which is a realistic type of attack we'd like to train users to recognize.
At the very least, option 1 above will resolve the issue quickly and easily, though both options 2 and 3 are better in the long-run.