Genesys Cloud - Main

Hi everyone,

I'm reaching out to see if anyone else has encountered an email suppression issue related to Genesys Cloud.

Specifically, we are unable to receive any emails sent from the parent-level domain @us-gov-genesys.cloud and emails sent from that domain never reach our corporate inboxes. Interestingly, emails from our own Genesys Cloud FedRAMP Org (our email subdomain) come through without any problems, and we also successfully receive emails sent via other AWS SES sources. This issue does not appear to be global suppression. The problem appears strictly isolated to messages originating from the parent domain mentioned above. 

Examples of the top level domain sending addresses that we cannot receive emails from include: 
no-reply@us-gov-genesys.cloud
genesyscloudalerting@us-gov-genesys.cloud
voicemail-noreply@us-gov-genesys.cloud
reporting-export-noreply@us-gov-genesys.cloud

As many of you know, not receiving any emails from these sending email addresses above are preventing many of us from receiving report/analytic exports, voicemail notifications, supervisor alert threshold emails and basically any other platform level type notification. 

Has anyone ran into a similar situation or found a solution?

We have opened a ticket with support and thus far we've simply not made a lot of progress identifying the root cause. Hoping the folks here may have some info that could be helpful. 

Any advice, experiences, or tips would be greatly appreciated. Thank you in advance for your help!

Hello Shane, 

Based on the issue described, this appears to be related to email filtering at your organization's gateway rather than a Genesys Cloud configuration problem. Since emails from your FedRAMP subdomain and other AWS SES sources are being delivered successfully, but messages from the parent domain @us-gov-genesys.cloud are not, it strongly suggests that your organization's email security tools are blocking or filtering that specific domain. The most effective first step is to work with your IT or security team to allowlist the relevant sender addresses or the entire domain, and to confirm that SPF, DKIM, and DMARC authentication checks are being handled correctly. Misalignment or strict enforcement of these authentication policies can cause legitimate emails to be rejected or routed to spam.

Additionally, your team should review any suppression or quarantine lists to ensure the domain or its senders have not been previously flagged due to bounces or spam reports. Checking email gateway logs, firewall rules, and security policies will help identify whether messages from the domain are being actively blocked. It's also helpful to continue working with Genesys Support by providing any available rejection logs, bounce-back messages, or error codes to assist with deeper analysis. Overall, the behavior points to an internal filtering rule, and your email administrators should be able to resolve it by identifying and updating the appropriate policies.

Hope this helps!

Hi Cameron,

Thanks for the great reply!

My apologies, I totally failed to mention that this issue is only impacting specific users / email accounts in our FedRAMP Org. Thankfully some of our users are having no issues receiving these emails. Also, support has stated they see us getting suppressed within AWS, but I guess since it isn't being suppressed within our own FedRAMP Org subdomain, it is much more challenging to determine how to get our accounts "unsuppressed" for lack of a better word.

It seems to be something directly related to the parent email domain that all platform level email notifications come from (to which of course we cannot adjust configuration or change anything on our end)

We have also checked internally with our email team and when we look at a user that is successfully receiving these notifications, we can clearly see email traffic being sent from the FedRAMP region (us-east-2). When we check other accounts that are not receiving these emails, we see no attempted traffic to those users from that same region. So it really seems that the outbound email traffic isn't making it out of Amazon SES to us. 

Sorry for not mentioning this before, the info above probably changes the potential root cause. Does the above info possibly trigger any new ideas or suggestions for us to look at? :)

------------------------------
Shane Jenkins
IT Sys Admin Mgr
------------------------------