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.
Related
I am working on a project where I want to allow my clients send a large amount of emails at any given time.
The issue I am having is that usually hosts have a very limited amount of emails allowed to send.
At the moment I am using third party service called Mailgun and it works fine but it is rather expensive since I have to send up to 300 000 emails per months and the number is growing.
Even if I rent a virtual server for example on scaleway where I have to set everything up myself, they have limitations.
Or are those limitations if I use their smtp?
Can anyone clear this one for me?
So my questions are:
Can I create my own smtp or any other way to send emails?
Is it possible to set up my own server and email server and send emails without any limitations?
If yes can you give me a tutorial or a course on that?
Or is it too much of a headache to do it myself and I should stick to third party services?
Thank you!
SMTP is not and headache but IP reputation management is. That's why most hosting providers limit SMTP usage and third party service florish.
As for the question "should I stick to third party ?", there is no right answer possible, only opinions:
If your emails are information requested by users (like forgot my password stuff, or notifications) you could use your own servers, because your IP reputation is going to be good.
If you send marketing stuff, all I can say is that my biggest customers all rely on third party services. Probably for good reasons
I registered G-Suite free long ago for my domain. We use Google Drive for file sharing and emails under that domain. Recently Google seems forcing me to upgrade to their pay plan. They list some of our key emails to spam list so that those email can't send mail to group. It also list some of our partners emails to spam list so that they can't send mail to email group under our domain.
Google suggests that in order to manage spam list sending to a group under domain, we have to upgrade to a pay plan.
As we have many users, the pay plan will be too expensive. So I'm thinking to run my own mail server, however still want to use google drive for file sharing within users in domains.
I would like to ask if there will be any issue if I change MX records to my own email server and keep using G-Suite free for file sharing with google drive ?!
Thanks,
Klab
The answer to your question is "it depends". Your split brain approach absolutely does work. We have exactly that configuration where we have some MX records going to on-prem, some going to gmail AND THEN to on-prem and some going only to gmail. The mails flow well and users get their email. The reason that I say "it depends" is that it depends on what you mean by issue. There's no issue with mail delivery, but there are issues with management. For example ideally you will have domainA.com for your email and domainB.com for your Gsuite and keep them separate: you don't have to do this obviously, but I wish we had. If you must have only domainA.com with domainA registered as your GoogleID but not with your MX record it will work, but it will probably end up with a headache when you get a problem in two years when userX's emails don't arrive and you have to track through where they go. That may not be an issue for you, but if you end up with 100 sub domains and 100K users then it's irritating to say the least.
You have other options with GSuite Enterprise and I assume Free, you can route all your inbound emails from a mail gateway see the docs so you can have both. Your inbound mails hit your Exchange server which then forwards to GSuite, or you can set up mail routes doc to forward all your inbound emails to your Exchange server, so you keep your MX record as Google and then your forward those mails to Exchange, then you reply from Exchange and the recipient replies back to Google. We do that too. It does work, insofar that the mail is delivered but it gets confusing to debug issues. But if you must have only one domain and you have to split up users then it's one approach.
You also configure a non-Gmail mailbox see doc which routes all your messages to, say, Exchange.
However, before you do, I'd look more into the Gsuite anti-spam features. You can customise some of the Google spam filtering. See doc . You can't customise all of it: we have had hangouts with the Google spam team who (eventually) explained some of their internal workings and there are some spam messages that you simply can't get delivered because the spam filter is applied before the GSuite level. Most business-type spam, rather than the nasty malware or "adult" spam, though is managed at the Gsuite level and you can disable it by domain if you wish. Differentiating between what Google thinks is spam and what the business thinks is spam still crops up for us from time-to-time.
To address your core issue of spam emails not being delivered to your group, I do not know about the free tier: we have the Enterprise tier, but on the assumption that the Groups configuration is the same (which it may not be but if it is) you can configure message moderation docs for a group. You can set "spam messages" to "skip the moderation queues". We have done that where, as with you, legitimate mails get classed as spam because they come from, say, automated services. We have also in cases removed the "archive" ability so the group is really only a mail distribution list and that bypassed the moderation for us.
I enclose a screenshot of the Enterprise Groups moderation options page from the control panel so you can see what we get in Enterprise and if it's different from what you get in Free Tier
We have a powerful VPS currently having various websites. This websites although they do not spam have had their i.p. emails blacklisted in the past? we keep fighting against getting the i.p.. delisted because it otherwise affects all websites email deliverability. It seems too vulnerable that if the I.P. gets blacklisted then everybody loses business not being able to contact their clients. I know large websites have strategies to avoid this, not sure how they do it. I would like to know an experts advice on how to deal with this problem. In summary what are recommended best practices for business email deliverability when depending on one I.P.? or is there such thing as dynamic I.P.s? Open to any options to solve this critical problem for us.
There are many steps you can take to insure that your IP does not get blacklisted in RBL's.
You can assign a unique IP for each website and you can assign same unique IP for outgoing mails so all the domains will not be affected if IP gets blacklisted.
Make sure you have enabled SMTP authentication for all the domains.
You can set SPF records for all the websites. You can create an SPF record from below URL.
http://www.spfwizard.net/
Create Domainkey (DKIM)
Use strong password for email accounts as weak password are more prone to get compromised.
Hope this helps.
Let's say I have a couple of ec2 instances with an elastic load balancer, and I want to run an email server on them so I can send and receive emails from multiple addresses. What is the best practice to do that?
It's sort of a broad question, but I can give you a (hopefully) helpful, specific answer. Email is a topic that doesn't get talked about much with AWS. In fact, this is where the benefits of the cloud can get a little... cloudy.
In my view, the key issue is email deliverability -- making sure that the emails sent from the cloud are reliably received by the intended recipients. Because of anti-spam measures employed by email providers, that means using IP addresses that have a good reputation. Unfortunately, that's not a big benefit of AWS. In fact, many spam filters simply drop emails sent from AWS IP's, and this is true for other cloud service providers as well.
So whenever I send any email from AWS, I always use a forwarding service such as SendGrid. Such companies offer SMTP forwarding in a secure way, and give you all the tools you need to reliably deliver both bulk and transactional emails.
At entry level, you use shared IP's and get the benefit of DKIM, open- and click-tracking, and bounce/block reporting. SendGrid helps to take care of managing your domain's reputation with the big providers. At higher service levels, they can help you warm up and maintain your own dedicated email-sending IP address to ensure that you are not impacted negatively by other SendGrid customers.
Of course, Amazon also sells Simple Email Service, and there are also other options such as sending through Gmail. I am in no way affiliated with any of these companies, but my main piece of advice to people wanting to send any kind of email from a cloud provider is to always use a third party service to maximise deliverability.
As to receiving emails, an Elastic Load Balancer isn't helpful for SMTP, though if you are providing webmail then it can help balance your port 80 traffic. For SMTP, use multiple MX records with the same weight, pointing to a set of hosts that can receive the email.
For your Mail Transport Agent, I recommend Postfix, but that's a matter of preference. You will find many people also recommending Qmail and Sendmail.
I agree with most of #platforms' answer in regards to receiving email in the "cloud", i.e., AWS. Especially the note about balancing port 80 traffic and the inability to balance SMTP (using multiple MX records instead). Just to give a different view on this matter, I had always set up a single MS Exchange Edge Transport Server for those tasks. In a Microsoft TechNet post they mention that a farm of 6 of these servers is able to safely handle around 13 million messages a day (even under peak load).
On the sending email from the "cloud", i.e. AWS, matter, I must disagree, though. I highly recommend using Amazon Simple Email Service (SES). It is fully integrated with the rest of your infrastructure, and the AWS SDKs have all the bindings you need for the majority of programming languages/platforms. As long as you correctly set up your Domain Records, DKIM, etc, you will have no trouble with deliverability. You also have the same reports about bounces, blocks, complaints, etc. Source: I have been using SES for years with no single complaint in regards to deliverability.
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.