Rather than repeat everything again, please see this closed issue for more context. 

The TL;DR is that SendGrid is apparently returning some bounced email due to TEMPORARY reasons as a "Hard Bounce", which Rock then reacts-to by inactivating the email on the person.

Historically this hasn't been a huge problem because the vast majority of these temporarily-can't-deliver bounces were due to "mailbox over quota" situations, which are pretty easy to handle and mitigate manually due to their low volume... even though they also should not be causing an email inactivation (again, because we can assume at some point the mailbox will be under quota and deliverable again.)

But recently a much more "severe" problem has surfaced that revolves around having DMARC set up per industry standards where email sent from your domain that doesn't pass DMARC evaluation gets rejected. The problem is that if there's a TEMPORARY DNS glitch when the recipient system tries to verify DMARC for your domain, SendGrid sends a "Hard Bounce" back to Rock, which again dutifully inactivates the email for that recipient. 

This is a huge problem because if the DNS glitch happens right when a large communication is sending from Rock, hundreds or even thousands of people can have their email disabled on the profile all at once, just from a temporary problem that likely resolved itself minutes later. This has actually happened to us, and it was a huge pain to fix. This likely isn't being seen by a lot of Rock orgs using SendGrid today simply because they're not following industry best practice with their DMARC setup (yet).

Per the issue above, it sounds like SendGrid is somewhat less robust vs. Mailgun in the way it sends back status codes, though there may be some improvement that could be made in Rock to tease out better statuses so that Rock would NOT inactivate email for such temporary delivery problems. Simply abandoning SendGrid for Mailgun is not realistic, especially when you have a dedicated IP with a 99.9% reputation that's been around 15 years. No sane org is gonna give that deliverability up.

I would be fine if there were a mechanism (Global attribute?) that let the Rock Admin/Org define a list of keywords that Rock would consult and BYPASS inactivation if such a keyword were found in the "Email Note", regardless of the status code... eg, if I entered "DMARC" in the list then any undeliverable mail with DMARC in the status would not inactivate, because I know they shouldn't be, regardless of what status SendGrid actually attached to that bounce.

That would give us ultimate control over how Rock does or does not inactivate emails based on (in the case of SendGrid) hard-to-decipher-and-unreliable status codes... but if there's an elegant way to get better statuses out of Rock so it doesn't react to these temporary bounces, I'm all for it.