Question
Is using an email alias, distribution list, shared mailbox, or Google Group as a support address supported?
Answer
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 with troubleshooting. However, Zendesk recognizes that many companies successfully set up and maintain these configurations without issue. Zendesk doesn't block their use.
To connect these configurations
- 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.
While aliases, distribution lists, shared mailboxes, and Google Groups are common, they can introduce unique challenges and complications:
- Complex routing and troubleshooting: Adding another layer of processing increases deliverability risks due to spam filters or lost emails.
- Malformation of email headers: Relays can alter email headers, causing SPF, DKIM, or DMARC issues.
- Fickle nature of email processing: Email behavior can vary based on the processor and parameters, highlighting the need for a direct and simple pathway.
Note: Zendesk highly recommends the use of standard email addresses for maximum deliverability. Unsupported configurations like this can cause issues that Zendesk can't troubleshoot. If you use these options, Zendesk won't be able to help with any problems that arise.
If you want to connect to a Google Group, see the article: How do I use Google Groups as a support address?
13 comments
菱沼 美咲姫
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.
0
Ronald Suplido Jr
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!
1
菱沼 美咲姫
Hi, Ronald! Thank you for your kind response. I will try it that way. Have a good day!
0
Kyler Chang
Is it possible to add distribution list as cc as replying ticket?
0
Audrey Ann Cipriano
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 :)
0
Viji Hari
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?
0
Dave Dyson
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?
0
Viji Hari
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.
0
Ian Pylvainen
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?
0
Sean Morrissey
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.
0
Nara
0
The Original DKNY
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
0
Ryan Winkler
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.
2