Hey all thanks in advance for the look.
We are attempting to develop a drip campaign email platform. For each "drip"we need to detect if the recipient replied to the email.
If so we would like discontinue the following drips.
For this we need some sort of reply detection but everything I have seen about tracking email metrics online is related to bounce rate and open rate.
Not much available on reply rate in terms of how to build such functionality.
Preferably we would like to do this on Amazon SES but if there is no such option we are willing to look at other smtp providers.
Perhaps there is some unique header we can save with the outbound email, then check against all the inbox emails. I guess this relates to how do email clients know to thread emails - perhaps it's a similar process.
Yes, you can fetch/read the email replies.
For that you will have to create 'Rule Sets' within the 'Email Receiving section' of SES.
The replies can be redirected to services like S3, SNS,Lambda, workmail to name a few and then you can read those from that redirected service
Related
I'd like to send emails programmatically via SendGrid (from admin#mydomain.example.com), but have replies to that email come to my Google Workspaces inbox for admin#mydomain.example.com). I would then like to reply to the customer from Google Workspaces.
The closest question related to this I could find is Setup | G Suite + Sendgrid for transactional email, but that was a fairly different use-case.
So in my usecase, emails to the customer would come from admin#mydomain.example.com via EITHER SendGrid or Google Workspaces.
Here's a article from MailGun that talks about a similiar pattern
My questions:
Will this result in deliverability issues, having emails sometimes come with different signing keys/domains? I don't understand email signing particularly well.
Is there anyway to have replies to the email address go to BOTH SendGrid and Google Workspaces, so I'll have it in my inbox but can also get it posted to a webhook by SendGrid? I think the answer is no, but figured I'd ask.
Any other considerations I should keep in mind for this strategy? Is this a poor idea for some reason?
Thanks!
Yes, this will result in deliverability issues. You should use the same domain for both sending and receiving.
No, you can't have replies go to both. You can have replies go to a webhook, but you can't have them go to both a webhook and a mailbox.
Final consideration: This is a poor idea. You should use the same domain for both sending and receiving. If you want to use SendGrid, you should use SendGrid for both sending and receiving. If you want to use Google Workspaces, you should use Google Workspaces for both sending and receiving. You can't use both at the same time.
Another consideration: If you're sending a lot of emails, you might get flagged as a spammer if you're sending from multiple domains.
The company I work for does something similar that might be helpful for your scenario.
We have a number of systems that send emails via SendGrid e.g. Auth0, Salesforce, various bespoke systems, etc. Some of these use native integrations to SendGrid, some use SMTP relaying, and others send emails programatically via the SendGrid API.
We've implemented sender auth (i.e. DKIM) in SendGrid for our domain e.g. mydomain.example.com, but we don't handle replies in SendGrid as we want replies to go to a different system - specifically our contact center system (which is the main systems our help desk staff use). Help desk staff would then reply to emails from within the contact center system. Note: we needed to configure DKIM for both SendGrid as well as the contact center system (as both currently send emails from mydomain.example.com), but in the future the intent was to implement a SMTP relay in the contact center system (to SendGrid) so that all sending goes through SendGrid.
I'm a bit fuzzy on the fine-grained implementation details of how we handle replies, but essentially we point the (single) MX record for mydomain.example.com to a third-party email protection system which scans the emails and forwards them to Office 365 mailboxes which subsequently forwards them to our contact centre system. I believe Office 365 is really only there for email posterity. AFAIK you should be able to point the MX record to anything that can handle SMTP.
In your scenario you should be able to configure the MX record for the mydomain.example.com domain to point at your Google Workspaces. This will allow you to send emails from SendGrid and use Google Workspaces to handle the sending and receiving of replies.
Not sure if you can configure SMTP relaying in Google Workspaces (i.e. to relay through SendGrid), but this would mean you'd only need to configure DKIM for SendGrid. All emails would be sent by SendGrid and replies would be go to Google Workspaces.
SendGrid is able to track if an email "... was accepted by the receiving server".
How would one go about doing this in an application that uses Gmail SMTP servers rather than SendGrid? (For example, a NodeJS application that uses nodemailer, or a Ruby-on-Rails app that uses Action Mailer, to send email through Gmail SMTP)
Google's different levels of paid G Suite offerings have logging you can use: Track message delivery with Email Log Search (google.com).
If you're not paying for G Suite and you're trying to build a way to collect statistics yourself, that becomes more tricky. Email service providers will generally count an "open" using something like a click-through on a link in the email (linked back to a property you control), or the loading of an image in the email (again, loaded from a property you control). You can read more about how ESP email open rates work here: The Science Behind Email Open Rates (and How to Get More People to Read Your Emails) (superoffice.com)
Gmail's SMTP servers don't report email delivery, only if there's a bounce. Google is somewhat closed with that, only paid users in G Suite can actually see the detailed delivery status using the Email Log Search tool.
Hope this helps.
in a recent project I integrated a custom Contact Form which uses the silverstripe Email Class. Unfortunately the sent E-Mails do not arrive at the client. It seems to depend on the host/domain of the target E-Mail Address. E.g. gmx does work (but spam), but receiving the mails on the E-Mail Address of the client does not work at all (hosted at united domains). Thanks,
Florian
The Email class in SilverStripe is admittedly not the greatest ;) But apart from potential lowlevel encoding errors, email delivery mainly depends on factors outside of SilverStripe.
You can start debugging mailservers, DNS records, spam headers, bounce emails, etc - but in the end its probably far easier to leave email delivery to a SaaS-provider like SendGrid or MailChimp. Both have offerings where you can just point your PHP configuration to their SMTP servers. SendGrid has a nice best practice collection on what to watch out for when sending emails in general.
I'm using my Google Apps account (Standard version) to send single emails (automatically) to real interested customers.
The problem is that my sender email account has been suspended, because it's been considered as a "spammer" by Google.
What can I do in order to send that kind of emails from now on? I use MailChimp to send massive emails, and I've seen it has an API, called STS, for sending single emails, but it also required an Amazon SES account, so I don't know whether to invest on those services or doing something else.
What do you recommend for this case?
You should try a service that specializes in sending "transactional" emails, such as Sendgrid, Postmarkapp and Mailjet.
They have APIs and libraries for most programming languages, but in your case you just need to configure the SMTP server they rovide in your email client and you're good to go. They help you not get into the spam folder of your recipients, and help make sure you don't get flagged as a spammer
With most of them you should get some prettty powerfull analytics as well, which is a nice bonus.
I have a PHP web app that is going to send out about 1,000 emails. I would love to test the performance beforehand. Is there any kind of service that provides dummy email addresses to send to, for this kind of testing? I can't find anything that's not just a general bulk-email service. The key here is I just want dummy addresses to send to.
If you have the ability to just purchase a domain name from a hosting service, I know at least 1&1 gives you like 2500 email addresses per domain so you could literally spam yourself to death and not worry about any other 3rd party. You can pick up a domain name for like
When you say "test the performance", do you mean you want to know about your deliverability rates, or how your emails look?
Deliverability Rates
This is entirely dependent on your SMTP server and the reputation of the IP that it will be sending from along with your domain's SPF records and the content of your email. To maximize this, I would recommend using a marketing email service such as MailChimp or MadMimi.
Appearance of Emails
You could always just send yourself a test email to see how it looks. An alternative is to use a service like PostageApp that has a built in template designer that has both an easy email preview function and a test send email function.
(Full Disclosure: I am the Product Manager of PostageApp.)
If you use "Post Hoc" you can send email to an unlimited number of email addresses. Post Hoc acts like an SMTP server, and receives the email messages that you are sending, but it does not forward them on anywhere. You do not need to set up any email inboxes ahead of time, so there is no problem if you have 1000 different unique email addresses. They do not need to be from a single domain -- you can use any email address you want. It stores the email messages received so that you can inspect them if necessary. You would run it locally so that there is no concern about network problems, and it is very low overhead since it does almost no processing of the email. This way, the performance measure will be mostly the sending side processing. Best of all, it is open source and freely available:
Find it on GitHub: GitHub for Post Hoc
Also see the blog post: PostHoc: Testing Apps that Send Email