Right now automatic emails sent for task notifications and other automatic emails from Nintex Workflow come from the domain workflowcloud.com or one of its subdomains. Most companies have email rules that insert a header and/or alter the subject to flag it as an external email, which can lead to people not acting on the emails they receive because they look suspicious/like a phishing attempt.
What I'm proposing is a bit different than the idea IDEA-I-2976, which is to still be using that workflowcloud.com domain, but allowing customers to "reserve" their own unique email address under that domain (e.g. CustomerA@workflowcloud.com or customer.domain.including.top.level.domain@workflowcloud.com) instead of the generic nintex@workflowcloud.com. The verification could be done via a similar mechanism as the one to verify a domain for SAML configuration, which is to add a TXT DNS record for the domain to verify ownership. That, combined with the DMARC policy for workflowcloud.com to reject spoofed emails can give customers confidence the risk is mitigated enough to add their customer-specific address to an exclusion list from inserting that kind of external email header.
ServiceNow allows something like this, so it should be feasible. I do understand there would be some other back-end work necessary to deal with the variation of the emails for customers, but that email would still meet the criteria to "process incoming express approval responses as well as ensuring all emails are reliably delivered."
I realize this may not work in all companies or circumstances, but my company's IT team added a new flag for trusted external emails, noting that the email is coming from a "[My company name] Partner" instead of the default "EXTERNAL." Our IT team announced in advance that they would be adding this flag, so that employees would know it was legitimate. Naturally, I requested that Nintex be given this flag, and it was. This is a simple solution that may work for some.