SMTP Email delivery method


58 Kommentare

  • Offizieller Kommentar
    Kristal Lam
    Zendesk Product Manager

    Hi everyone! 

    Thanks for taking the time to provide feedback around SMTP Email Delivery! This is something that we have on our roadmap, we’re going to be starting discovery for this early next year. 

    Once we start discovery, we would love to reach out to everyone who has shared feedback for requirements.You can expect us to reach out to you to gather more information in (Quarter/Year). We’ll continue to collect feedback around why this is important to our customers today and the use cases it will solve through this post as well and reach out when we’re ready to start discovery. 

    Thank you!

  • Fran - JuegosMalabares

    It is not only Konrad who would like to use our own SMTP servers:

    Lets hope it gets some attention on the future.

  • Jason Gulledge

    Throwing my hat into the ring on this one as well.  We're bumping up against the SPF dns lookup limit, so we're trying to consolidate all 3rd party systems to route through a single point for outbound emails on behalf of the domains we manage. 


    If I could route outbound emails from Zendesk through our "approved" email system via SMTP, it would greatly help us manage and track outbound emails, as well as help us out on the SPF front. 

    Please consider allowing customers to configure SMTP on a per-domain basis or per account level if that's easier. It would greatly benefit us. 


    Thank you

  • Richard Dale

    Scenario for the last week:  All Zendesk replies to users with or have been delayed then (after 5 days) bounce back to us.

    Bounce messages are coming back fro multiple Zendesk SMTP servers - with error codes relating to security/spam type of conditions.

    Our own mail server has a high reputation, dedicated IP address with no bouncing issues for years.

    If we could use our own SMTP server for outbound replies this would avoid these sorts of issues.


  • Richard Dale

    This is urgently required.

    We've had a situation twice in the last month where emails to _all_ Yahoo users were delayed due to Yahoo temporarily deferring emails due to spam complaints.

    The real problem here is that we do NOT receive any such reports until some DAYS afterwards, after it has been sitting in the queue on the Zendesk SMTP server.  So we have a situation where a) we think the support issue has been resolved and b) the user thinks that we are ignoring them.

    Using our own mail servers allows us to at least monitor any outbound mail issues - plus, being a mail server only we use on a dedicated IP address, means our IP address's reputation is not an issue.

    An example of this is below.

    Support response sent Sun, 14 Nov 2021 14:16:48 +0000
    Bounce message received: Fri, 19 Nov 2021 14:36:14 +0000

    This is the mail system at host

    I'm sorry to have to inform you that your message could not
    be delivered to one or more recipients. It's attached below.

    For further assistance, please send mail to postmaster.

    If you do so, please include this problem report. You can
    delete your own text from the attached returned message.

                       The mail system

    <>: host[] said: 421 4.7.0
        [TSS04] Messages from temporarily deferred due to unexpected
        volume or user complaints -; see (in reply to MAIL FROM command)
  • Alican Cakil

    I really need this feature.

  • Lee Burkhill

    Hi Nicole,


    Our company are currently using a service called Mimecast. We would prefer to use Mimecast as a 'middleman' via an SMTP gateway between ZD and the end-user.

    This allows us to continue our journalling for compliance reasons and remove issues we've had in the past with a separate instance of Zendesk we use for another brand.


    Is this something Zendesk would consider?

  • Phil Chamney

    We would like to see this so that sent mails are traceable when the receiver claims they didn't get the mail...

    Unless there is a way in zendesk to do this I'm not aware of.

    G Suites allows us to do an email log search where you can see the server's handshake log. If I used their servers to send zendesk email, I could do this.

  • Peter Conoulty

    We work for an NHS organisation and need this feature to integrate with our NHS wide email systems.

  • Andy Roberts

    Hello, checking in on this to see when we might see this feature.  A significant number of our messages get sent to Junk mail even with SPF and DKIM.  This has a serious impact on the reliability of our communications, and SMTP would fix this.  Hoping it can be done soon! Thanks

  • Óskar Ómarsson

    I would love to get an update on this, how is the timeline looking for this are we going to see this feature come into action this year, Q3? Q4? 2022?

  • Sebastian

    What's the status on this? Early this year should refer to the first 3 months, right?
    Setting up SPF has limits. And we have users that do not receive our answers because Gmail is ghosting the answers away because they think it's an illegitimate spam mail.
    I'm not even sure if the SMTP solution would verify the mails properly to gmail so that they don't ghost them but at least it would be a try.

  • CJ Johnson

    A full year has passed, can we please get some updates on the plan for this? 

  • Sean Cusick
    Zendesk Product Manager

    I can confirm that this feature is on our 2023 roadmap. We have no ETA at this time, though we will update this thread once we are ready to roll the feature out. 

  • Jarrad Richards

    Sean Cusick We're at the end of November now, any ETA available please? 

    Would love to see if it's possible to retain features such as CodeTwo (signature manager), to stop double handling of signatures in multiple locations (Zendesk & CodeTwo). 

  • Max McCal
    Zendesk Product Manager

    Hey, Konrad - 

    I'm not sure I understand what you're saying. Obviously one needs to be cautious when sending information using SMTP, but we do support SPF (less than perfect, as you mention) and DKIM as means of listing Zendesk as an authorized sender, and the combination is fairly trustworthy. We recommend using both if at all possible. Even a strong DMARC reject policy can be supported using both of these.

    If you have ideas on what we should be doing, I'd love to hear them.

  • Anghor

    Hi, Max -

    SPF, DKIM etc, are OK but for example our "mother" company "sending emails" policy forbidden using us such solutions... The only solution that is acceptable is sending emails trough SMTP server with authorization.

    This is kinda issue - I was asked to drop Zendesk because of that and switch to LiveAgent. My employees hate changes, especially with established workflow we've got. I also don't like LA interface that's Why I'm so frustrating about your "fear of SMTP solution". 
    Can you give me at leas one good point why you're not supporting SMTP messages delivery?

  • Max McCal
    Zendesk Product Manager

    So essentially you're looking for your Zendesk notifications to be sent by email through your own servers, essentially. I understand that concern, and I think we'd like to investigate it in the future. At the moment we have some other priorities around the stability of our system and scaling our product, but we are considering these things for future growth and improvement.

  • Maky

    I'd love to have this option as well.

  • Matt Savage

    SMTP would allow a workaround for some really obnoxious email looping logic for automated systems.  

    For example, if you have notifications sent from some other source, it'd be nice to sync via SMTP to get that content into Zendesk & allow replies to that same email (essentially, pretending that these emails originated in ZD).  This is a common email behavior: sends out a bulk mailing, responses return to that same place form the recipients.

    Instead, to avoid looping addresses that forward into ZD, you'd likely have to do something like this: (with sends the email to, CC's to ensure that the notices are sent into ZD via email processing.  You'll also need triggers to push the status to pending/solved immediately, as you need to wait for the actual customer to reply (if they do).  It adds a great deal of complexity to the simple task.  The other alternative is configuring automated systems to send the original message via the ZD API; while this is doable, it requires more dev resources & counts against your API usage, which can be hard to balance with bulk mailing events, even when attempting to distribute the load.

  • Hamish Gough

    The other problem with SPF is the limit of 10 DNS-querying lookups. This means you're limited in the number of providers that you can allow to send mail on your behalf (and some will "consume" more than 1 each).

    One option is to try "flattening" your spf records, so instead of including zendesk's spf you just all all the ip4 records from it - this gets ugly as more providers are added.

    Being able to use our own SMTP server (like a lot of other providers enable) would make life a lot easier. Is it that hard to do?

  • Amit

    another vote from me! There are some companies who require the email to route through them for their email compliance and archiving needs.

  • Jose Gonzales

    Another vote for the ability to configure email via SMTP!

  • Nicole Saunders
    Zendesk Community Manager

    Hey all - 

    Please use the voting buttons on the original post to register your votes, and use the comments to share more details about your workflow - why you need this, how you would use it, and what impact it would have (frequency, time, etc.) 

    Thanks for participating in Product Feedback! 

  • Evren Tekin

    I have used the voting buttons already but just to add to the other voices, for many of our clients routing of emails through their smtp servers is an absolute requirement when we work with them. 

  • Nancy

    I'm surprised this is not already available!  Please enable it!

  • pivovarov

    In our company it's forbidden to use SPF. Only SMPT TLS sending via our server is allowed...

  • Nicole Saunders
    Zendesk Community Manager

    Hi everyone - 

    Please share additional details about your use-case. It's really helpful for the Product Managers. Thanks!

  • Nicole Saunders
    Zendesk Community Manager

    Hi Lee - 

    If it's something that impacts a significant number of users and would be helpful for a variety of use-cases, then it's something we might consider. 

  • The Original DKNY

    There are other reasons the use of Account Holder Owned SMTP Relay or email service (think sendgrid or SES) is needed.  The way emails are sent by Zendesk currently makes meaningful email tracking virtually impossible.

    Below is my rant on another thread

    All of the current solutions in the Zendesk market place can only inject a tracking pixel at the time a ticket note is being written and submitted.  This means anyone CC'd on a ticket will trigger the pixel load and get the message marked as read, even though the service requester/recipient has not read the email. 

    Additionally, the use of unique email addresses per ticket, rather than a custom X header entry makes tracking pixels even less reliable.  In testing the current market place offerings against Google Apps and O365, each new ticket is seen as a new sender and the recipient of the email is prompted to render images.  This quickly breaks functionality. Using a Custom X header (eg; X-Zendesk-Thread-ID: <subdomain>-<ticket_id>-<some_checkable_hash_value>) to track what email is part of a given ticket would enable two things; sending unique emails to everyone on the ticket and the ability to implement native email tracking for open, bounce, etc. 

    Zendesk made a big push in moving to Aws SES, email tracking is a native feature of SES.  Many of us have our own AWS SES accounts.  I dare you to charge us a small fee (call it $500 a year per SES API instance)  to use my own AWS SES account and implement an automation step that can check SES for opens every 5-60 minutes as a definable time window.



Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.

Powered by Zendesk