I am reaching out to the community for a help. One of the public facing website we are developing, will take an anticipated load of 2 million emails per peak hour. In order to perform load testing, I was looking to utilize API calls to create email inboxes.
I have came across some email providers like MailSlurp or Mailinator where we can use email inboxes but do you know if there are any additional providers where we can create that volume of email inboxes? Our company has security concerns on both MailSlurp and Mailinator. Preferably free of cost but with cost will also work.
Related
I'm working on a product where we use SendGrid.com so send system e-mails to our customers end users. These e-mails origniate from our own domain - let's call it ourdomain.com. This is done by going through SendGrids' authenticated domain flow to set up DNS-records to validate the domain.
Several of our customers have asked if we can send the system e-mails from their own domain. E.g. they would like if e-mails sent from the system was sent on behalf of #customerdomain.com.
The question is - how do I set this up in SendGrid so that we can deliver DNS-settings to the customers?
I really don't want this to be a manuel proces as we might have hundreds of customers who wants to use their own domain. I've tried reaching out to SendGrid support, but they basically keeps linking to this page: https://docs.sendgrid.com/ui/account-and-settings/how-to-set-up-domain-authentication. This is what we've done for our own domain, but this isn't really a viable solution if we need to handle hundreds of domains from different customers.
Does anyone know if the process can be automated via the SendGrid API? Something like this perhaps:
The customer creates an account with us (domain: customerdomain.com)
We call SendGrids API saying "create domain validation for domain customerdomain.com"
We get back the DNS entries the customer (owner of customerdomain.com) needs to enter into their DNS setup
We start sending e-mails with the FROM-address set to something#customerdomain.com
Maybe I'm looking in all the wrong places, but I simply can't figure out how to do this the right way.
Any help will be greatly appreciated!
i am planning strategy for our bulk marketing emails and bulk recruitment emails. Shall we use seperate domains for marketing and recruitment bulk emails even if we are using SMTP Relay service of providers like Critsend and Sendgrid. Reason i am asking as i have read somewhere Domain Reputation is also very important in the long run and should use main domain : abc.com for normal transactional emails and every day communication with our clients and vendors and use seperate domains for Bulk Emailing.
We do have all these 3 domains (main abc.com, others abc.net and abc.org) for several years with us so we can setup quickly and start using though other 2 new domains have never been used for sending emails till date and we have used our main abc.com for sending transactional emails till date for all these years except once a few years ago for bulk emailing but that few 100 emails only.
Or if we are using your SMTP relay of these providers then the domain reputation of providers is required hence it will not matter whether we use other domains or just use our primary domain for everything?
Please help and advise.
For the most part the from address domain is what your sending reputation is associated with, so yes, I would recommend that you separate by domain.
The sending IP also has some effect, so if you have an especially bad reputation on one domain, it may cause deliverability issues for other domains with otherwise good sending reputation that use the same IPs, so it’s a good idea to split that too.
With regards an OMS, what is the best method to send a confirmation email? The 2 options I have so far are;
A script on the order page sends an email once the record is written to the database.
A scheduled task on the server, send the email, polling the database every-so-often to find new entries.
Which method do systems currently use?
For e-commerce websites, it might be better to think about the best user experience.
Given that, you would want to send the email as soon as the order is received so the user knows that they have purchased the item. The sooner it gets into their inbox, the sooner they will be happy that they have made their purchase.
I agree with Digbyswift that sending the confirmation email once the record is written to the database is the least scalable. But I would argue that if your system has gotten to the point that you are taking so many orders that your system cannot keep up, you have a wonderful problem on your hands that you now probably have resources to handle.
At PostageApp, we handle the emails of a few e-commerce websites, so perhaps you would benefit from an arrangement with an email service provider to off-load this task so that all of your resources can be spent on keeping your site up and your databases running.
Here are some great alternatives if PostageApp is not your style:
Sendgrid
Postmark
Mailjet
This is a question of scalability. Sending a confirmation email once the record is written to the database is the least scalable. The more orders that are taken , the more emails are sent potentially tying up resources.
A scheduled task is certainly better as emails can be queued up and can be sent in a separate process.
A further option which you could consider is using neither and delegating the responsibility of sending emails to a 3rd party dedicated emailing service, i.e. via an API. This is much better since your hosting does not have to consider the load and you can utilise any reporting offered by the 3rd party. Plus many services offer a free quota up to a certain threshold. This will allow you OMS and business to scale appropriately.
If you apply a message based architecture; you could just publish an order created message and have any number of subscribers respond to that event. You could create a listener that sends the email in house (bespoke option) or another listener that called the API of a 3rd party emailer to send the email on your behalf (as per #Digbyswift)
What I've always liked about this approach is
You can have any number of listeners live at any one time.
You can create a new listener and change how you send the email without needing to change/redeploy the OMS application itself.
You can take the listener(s) off line and stop / delay the sending of the email without losing any notifications or affecting the OMS itself.
I'm trying to code a mail sender service. Previously I built a simple desktop application which uses my shared hosting mail server to send html mails. But now it's not enough and I plan switching to Gmail or Amazon SNS.
For Gmail I have to use min 15 different accounts to be able to send up to 1500 emails. Also sometimes gmail blocks the accounts and I have to login and change the passwords.
I've just signed up for Amazon SNS but it does not looks to what I need. You first have to subscribe users then send emails. Also emails are sent from no-reply#sns.amazonaws.com addres. Is this the all service or I can configure it as I wish?
I also read some suggestions to lookup the MX records for the destination mail servers How to send 1000+ emails per day using an ASP.NET Web site
I want a minimum cost solution. So which is best and is there a better solution?
We use Mailjet for 3 sites now. Initially we used the free plan (6000 / month) to test the set-up and reporting. Now the 3 sites are run on it. Very satisfied - especially since they offer dedicated IP monitoring. According to us, it's rather easy to install. SMTP very easy and one of the sites integrates with the API. I'd recommend
There are a multitude of services available for you that will allow you to send 1500+ emails per day and will get the headache of email deliverability off your plate.
PostageApp (Ours!)
SendGrid
Postmark App
Deliver
Mailjet
Take a look and see which fit your needs and have the implementation method that you are looking for. They each have a free service, so it's definitely easy to try.
(Full Disclosure: I am the Product Manager of PostageApp. Let me know if you have any questions!)
A relatively new option for transaction emails that seems pretty good from Mailchimp:
Mandrill
Looks like it has decent integration with their main service as well.
You can utilize some premium services to send 1000 emails here, daily for free
Remember, you should not spam in the services listed, just you create multiple lists in all accounts & send emails daily.
I have a large user list which is distributed in two groups. 1. Phplist 2. Vbulletin
Phplist has around 50,000 users while vbulletin has some 70,000 users. These all are double optin safe lists and completely legal.
We have a dedicated server and use phplist tos end mails but a single mails takes 3 days to process given phplist limitations. I am very keen to use Sendgrid / Amazaon SES or something so that i can shoot pur monthly newsletters much faster ( we have some 20 news letters including jobs, announcements login etc).
At present we send emailes from a different domain than the main one and its like www.mydomainnewsletter.com while main site and corporate emails are www.mydomain.com ( my main site is on drupal)
Now how do I build a process where all transaction and corporate mails go from mydomain.com while all newsletters go from mydomainnewsletters.com. users shall subscribe and unsubscribe at mydomain.com and this email list shall be synchronized with www.mydomainnewsletter.com.
My server has qmail intalled. So can somebody guide me through the process. I am not techie at all.
You have a few options, that I can think of. I definitely don't think you should do this in-house unless you want to deal with the huge mess of dealing with deliverability.
Here are some non-in-house options:
Build a scheduler, server side, to shoot out the emails to third party providers like SendGrid and Amazon SES, or make bulk email API calls using PostageApp
Use a service built for newsletters, like MailChimp, which can manage your lists for you and send out bulk emails without any problems whatsoever.
At least with these services, you're looking at a much faster delivery time. (Three days is attrocious.) They have the resources to send these emails, they worry about the deliverability, and you can focus on making an awesome newsletter and/or working on your website.
Full Disclosure: I am the Product Manager of PostageApp.