Can I use an email alias, distribution list, or Google Group as a support address?

Return to top


  • 菱沼 美咲姫

    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.

  • Ronald Suplido Jr
    Hi! I would recommend that you remove the existing address first before you re-add it using the "Connect other" method.

     If you're trying to connect a distribution type of email, this article ( 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!

  • Kyler Chang

    Is it possible to add distribution list as cc as replying ticket? 

  • Audrey Ann Cipriano
    Zendesk Customer Care

    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 :) 

  • 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? 

  • Dave Dyson
    Hi Viji, welcome to the community!
    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?
  • 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. 

  • 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?

  • 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. 

  • Nara
    Zendesk Customer Care
    Hi Ian, as Zendesk does not officially support the use of email aliases per this article, while it's possible in some cases the system may recognize an incoming email as part of an alias address, ultimately subsequent business rules built on the use of an unsupported alias address is similarly not supported.
  • 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

  • Ryan Winkler
    Zendesk Product Manager

    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.

Powered by Zendesk