SMTP Email delivery method
PlaneadaThis 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
-
Comentario oficial
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!
-
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.
-
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
-
Scenario for the last week: All Zendesk replies to users with @yahoo.com or @ymail.com 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.
-
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.
Timeline:
Support response sent Sun, 14 Nov 2021 14:16:48 +0000
Bounce message received: Fri, 19 Nov 2021 14:36:14 +0000This is the mail system at host deferred3.pod25.apne1.zdsys.com.
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
<XXXXXXX@ymail.com>: host mta7.am0.yahoodns.net[67.195.228.94] said: 421 4.7.0
[TSS04] Messages from 103.151.192.18 temporarily deferred due to unexpected
volume or user complaints - 4.16.55.1; see
https://postmaster.yahooinc.com/error-codes (in reply to MAIL FROM command) -
I really need this feature.
-
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?
-
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.
-
We work for an NHS organisation and need this feature to integrate with our NHS wide email systems.
-
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
-
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?
-
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. -
A full year has passed, can we please get some updates on the plan for this?
-
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.
-
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). -
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.
-
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 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.
-
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.
Iniciar sesión para dejar un comentario.
56 Comentarios