Is using an email alias, distribution list, shared mailbox, or Google group as a support address supported?
Zendesk doesn't support the use of aliases, distribution lists, shared mailboxes, Google groups, or any non-standard email clients or services due to added complexities of routing and issues troubleshooting. For more information, see this comment on this article. Zendesk highly recommends the use of standard emails over these options to ensure the maximum deliverability of your emails.
However, you can still connect them if necessary.
To connect them
- Ensure your email forwarding is set up correctly.
- In Admin Center, select Channels in the sidebar, then select Talk and email > Email.
- In the Support addresses section, select Add address > Connect other.
- Type the email address in the text field.
- Select the Yes, I have forwarded this address... checkbox.
- Click Next.
Note: If you choose to use these options, Zendesk cannot assist in troubleshooting any issues due to being unsupported.
If you want to connect to a Google Group, see the article: How do I use Google Groups as a support address?
I plan to set it according to this article, but I accidentally set the distribution list that should be registered from "Connect Others" as an external support address.
In this case, when I add it from “Connect Others”, will it be automatically removed from the external support address? Do I have to delete it before adding it as another connection?
I would appreciate it if you could teach me. Thank you very much.
If you're trying to connect a distribution type of email, this article (https://support.zendesk.com/hc/en-us/articles/4408833816218) gives you an overview of how it's supposed to be configured in your email host side. Essentially, the distribution email should only contain Zendesk-owned support address and nothing else. If your mail host supports removal of the footer in Group emails, I suggest that you do that too. Cheers!
Hi, Ronald! Thank you for your kind response. I will try it that way. Have a good day!
Is it possible to add distribution list as cc as replying ticket?
HI Kyler, it is possible to add distribution lists as CC to your tickets as we send them the same way we would send to any other address. We just don't recommend using them in conjunction with Zendesk :)
Can I add a Google group/distribution list as a Requester? If CC works, I'd assume it'd work for Requester too for the outbound email. What happens to incoming responses?
Using a Google Group as a support address is not officially supported, but there are some instructions (and a caveat) here: How do I use Google Groups as a support address?
Hi @..., thank you! I looked at the article- it speaks to using GG as a support email address. I wanted to know if I can create a new ticket and send it to a google address instead of an individual mail ID.
Hi, we use a Google Group to forward emails to our support site and that group address has an alias. When I send emails to the alias, they get forwarded to Zendesk and Zendesk clearly recognizes that the email came from the alias address in the ticket events. Is there any way then to create a trigger etc that recognizes that an email was sent to the alias and not to the original email?
There appears to be a glitch with the introduction of simplified messaging and/or the new SPAM filtering that has broken google groups seamlessly working with zendesk.
Thank you for updating, but just want to point email aliases were in fact defined as SHOULD BE SUPPORTED by SMTP services, servers, and clients. Please read RFC5321 Section 3.9. That was adopted for ratification in 2008.
This has been an open and often requested feature. I guess your feature request notices from the Community are an email alias or google group and that is why this functionality does not exist. (Sarcasm is still free).
Just say you don't support it, rather than say it's not part of a defined IETF Standard, as it clearly is part of the defined SMTP standard. While it may not be a MUST be implemented to meet the standard, it is a SHOULD which often becomes a de-facto MUST based on best practices relating to the standard.
If email aliases are so outside the norm, why do Google, Microsoft, Zoho, Lotus, MajorDOMO, and LSoft ListServ all support and have documentation stating they support Aliases as part of the normal and defined function of SMTP services for clients and servers?
The top: 3 most common aliases are directly related to the main use cases for Zendesk Suite and Sell https://blog.101domain.com/google-workspace/most-common-email-aliases
Hey The Original DKNY,
It looks like the intent here may have been "lost in translation", so I figured hearing from me directly might help pepper some additional context.
My original intent of this article is to provide a way to "thread a needle of support" so you aren't left finding out about this after you go through setting your services up, as stated. We do not block them and if you are able to set them up and maintain them yourself, you will have no issue, as many companies do so without issue.
I meant this as an acknowledgement and "heads up" that we've seen the woes of using them, and we can't troubleshoot a system outside of our products (such as your google group, or otherwise) and consequently will cause you frustration and confusion when troubles arise.
We figured it's better to mention it more explicitly and provide additional context, instead of setting you up for failure or frustration without it, while also suggesting use of a non alias or distribution group to circumnavigate issues in the first place.
I took a look at your article and it looks like how they describe aliases serve a similar purpose (and overlapping functionality) as External support addresses. Setting up each address in the way that article suggests let's you take advantage of functionality such as brands, business rules and more.
Using both in conjunction can also add another layer of complexity (and additional relay/processing "jump") which, depending on context and configuration could end up negatively affecting your deliveribility either due to spam filtering or being "lost" in one of the layers. We've also seen on numerous occasions where a relay can malform email headers, causing SPF/DKIM/DMARC issues.
Email can be more fickle depending on who is processing it (and what parameters are used), so we'll always advocate using the most direct and simple pathway possible, in addition to using the features we build that we CAN help you out with and support on our end.
So while aliases are definitely "not out of the norm", they can add some "gotchas" and some behavior which have thrown people off if you're unaware, and could result advocacy having to "turn you away" without solving your problem if you hit one of them (since many times the configuration issue occurs outside of our products).
Regarding feedback and requests --
Our product teams immensely value and actively review feedback requests, and works to provide solutions broadly based on them, and problems surrounding them. We're a passionate bunch and definitely don't want you to walk away feeling unheard or ignored or worse, so let me be the first to cheerlead and advocate for you to keep the feedback rolling! We love them, and want to hear more, sarcasm or not! The best avenue would be within our Ticketing feedback community, although we do our best to see them everywhere.
I hope this helps add more context, but if I missed something, let me know and I will be glad to jump back in and chat a bit more.
Please sign in to leave a comment.