SMTP Email delivery method
計画済みThis topic is sticking around for many years. I'm personally surprised how high level of ignorance is presented by Zendesk developer.
Sending emails over authorized SMTP is only CORRECT and SAFE option for most companies that are concerned about data safety. SPF method works only to some level and then becomes a liability.
Can't understand what kind of issue Zendesk have with SMTP approach but this doesn't build trust to the whole system. Should you care more about data safety and end-user comfort??
You can be surprised but adding SPF records in many cases is far more complicated that setting up email account and password for it ;-)
Hope you can reconsider ability to sending messages over SMTP. It's biggest disadvantage I can find at the moment if I compare Zendesk to competitors. Rest pass this test with flying colors.
Best Regards
Konrad
-
正式なコメント
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!
-
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.
-
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? -
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.
-
It is not only Konrad who would like to use our own SMTP servers:
https://support.zendesk.com/hc/en-us/community/posts/203427616-Specify-external-SMTP-Servers
Lets hope it gets some attention on the future.
-
I really need this feature.
-
I'd love to have this option as well.
-
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: email@domain.com 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: noreply@domain.com (with reply-to:forwarded_email@domain.com) sends the email to recipients@domains.com, CC's forwarded_email@domain.com 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.
-
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?
-
another vote from me! There are some companies who require the email to route through them for their email compliance and archiving needs.
-
Another vote for the ability to configure email via SMTP!
-
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!
-
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.
-
I'm surprised this is not already available! Please enable it!
-
In our company it's forbidden to use SPF. Only SMPT TLS sending via our server is allowed...
-
Hi everyone -
Please share additional details about your use-case. It's really helpful for the Product Managers. Thanks!
-
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?
-
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.
-
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.
-
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
-
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.
-
We work for an NHS organisation and need this feature to integrate with our NHS wide email systems.
-
We also need SMTP Email support, since Office 365 really does not seem to like the emails coming from Zendesk via our domain and thus we are barely getting any notifications, even though all DNS records (including SPF and DKIM) are correct.
I don't understand how this has not been implemented yet, even though competing products have been offering this functionality for years.
-
@... we had the same issue and followed these steps in Exchange online to solve it. https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/create-safe-sender-lists-in-office-365?view=o365-worldwide#recommended-use-mail-flow-rules. This is dependent on you having a DMARC policy published for your domain as this is used to ensure the email is valid.
-
Since internet DMARC anti spam mechanisms use both SPF and DKIM and larger organizations and those with multiple email services quickly run into the SPF 10 record lookup limit. It is very important to allow organization to consolidate email senders. This means that we need to be able to configure the email senders/providers in the products we choose to use. PLEASE address this issue which has been open for more than 5 years!
-
Up vote from me!
-
Hi everyone,
The way we've decided to address this problem is to give customers the ability to allow for Zendesk notifications to be sent by email through your own servers. This is a problem we are planning to solve for and will keep you updated once we have more to share.
-
@... Any news on this - This is exactly what I need for one of my customers :-)
-
No further updates at this time, Carsten. The team is still in research mode on this one.
-
Hi,
Just out of curiosity, is it correct that this is supported in Zendesk Sell already?
When can we expect this in Zendesk Support as well?
Best regards
Oskar
サインインしてコメントを残してください。
56 コメント