I believe I looked into this for something else, and it cannot be done with DFM. DFM isn't looking at the necessary objects to determine if a port is err-disable.
However, if there is a syslog messages relating to a port going err-disable (and I believe there is one), then RME's Syslog Analyzer can trigger an email if you define an Automated Action to do so. The Automated Actions can be setup under RME > Tools > Syslog > Automated Actions.
DFM is more of an SNMP trap receiver, whereas RME is more apt at dealing with syslogs, which is the protocol Cisco OSes usually use to send err-disabled notifications.
To begin with, you need to compile a list of causes interfaces/ports can be err-disabled for. Assuming your routers/switches are adequately configured to spit out the relevant syslogs, RME's Syslog Automated Actions can be set up to email notifications upon reception of such syslogs. Here're some commonly seen err-disabled syslogs to key on:
SPANTREE-2-RX_PORTFAST:Received BPDU on PortFast enable port. Disabling [mod/port].
SPANTREE-2-RX_BPDUGUARD: Received BPDU on bpdu guard enabled port. Disabling [mod/port].
The PM-4-ERR_DISABLE message seems to be a good one for a wide variety of switches. Of course, AA doesn't require you just pick one message. You can lump a whole bunch into the same Automated Action.
One'd hope so, but unfortunately given the multitude of possible triggers and how each OS is coded to phrase the syslog differently, it almost always takes getting "bitten" at least once first, before learning there's another reason ports get err-disabled. This translates into perpetually updating the Automated Actions to catch up.