I am building a B2B SaaS platform which sends emails on behalf of it's business clients. Currently, using Sendgrid.
Assuming that Client's domain name is blabla.com
How can I send emails with field "from": noreply#blabla.com ?
According to Sendgrid's documentation, the "From" field should be either from verified domain or verified single address.
Verified domain doesn't seem like a feasible option, as it requires every customer to change their DNS records. Some of the customers just don't have easy access to their domain names.
Verified single address seems to be a better option, but according to Sendgrid the upper limit is 100 of such addresses
Additionally, they don't allow to brand a verification email being sent on adding new verified single address.
What is the best practice to send emails on behalf of your business clients?
Are there better approaches to solve this problem?
Related
Suppose I own an email 'demo#gmail.com'. Now, I create a new Microsoft account using my existing email. Thus I get another email 'demo#gmail.com', but this one is served by Microsoft.
So the situation is: one email and two providers.
If I send a hello email to 'demo#gmail.com' using my personal SMTP server, to which of the above will it send: will it send to the one hosted by Microsoft or the one hosted by Google?
How does it solve such an ambiguity? What are the factors that influence this?
This is a very common problem because many providers are giving us an option to create a new account using our existing email.
My observations:
I saw the emails inside the inboxes of both the services. I found that they had completely different emails.
There was no email which was common to both the inboxes. So there must be some mechanism to deal with it.
Let us look at the problem the other way round: If I had an email 'demo#outlook.com' initially and I created a new Google Account with this email address, then:
An email sent to this email address from another gmail account goes to the Google's server. An email sent to this email address from an Outlook also goes to the Google's servers.
There are two different ways of looking up an email. The 'normal' way:
You send an email to an server, in this example gmail.com.
Your mail delivery agent looks for mx record of gmail.comand send it to the ip-address of gmail.com.
If an email is delivered locally by the domain outlook.com it perhaps doesn't lookup the mx record, but lookups in a local database if the email-address exist there, and sends it to the ip-address of the outlook.com.
I think in the inbox of outlook.com are only microsoft emails.
More details can be found at https://www.socketlabs.com/blog/smtp-email-delivery/
In a Laravel/Symfony SaaS app I want my clients to send out mails to their customers – my clients can manage their customer information in my app.
I am looking for a way they can send emails that are from their own addresses – and not from my domain (via sendmail).
These mails should not have a on behalf of in their FROM, but also I want to make sure that my service will not get gamed by spammers.
One idea was that every client can set up her own SMTP settings which Swiftmailer will then use to deliver the mails for each individual address. Maximum daily delivery per client should by below 500, so that might work.
Another idea was to use a service such as Amazon SES, who let you verify up to 1000 addresses. Or Sendgrid, who offer something similar.
What is the most secure way to send mails from different addresses with a maximized deliverability and minimum risk of being gamed by spammers?
For safe guarding against being marked as spam you need to
Have your DKIM and SPF settings in place
Do a LITMUS spam test of your email to check your spam score against various spam check engines
Do domain throttling
It has nothing to do with email verification in SES because that is just a mandate for using a From email id while sending out emails
we are trying to automate outgoing emails for our SaaS product. Currently, each customer is required to configure their own smtp server which are used to send emails from their account (and from their domain), but we are looking at automating this in our product platform.
Each customer should be able to send emails "from" their own domain. The from address should be a domain address of the user.
We can get an account created with a transactional email provider like mailgun or sendgrid, and use that account to send email for all of our customers. However, we need to sign all emails with our domain. Due to DMARC, this can pose deliverability issues. Moreover, even if one customer mis-ueses, reputability of the sending domain (our own domain) is lost --which might affect all our customers.
It is not practical to ask each customer to verify their own domain using DNS verification.
What are the best practices while sending domains in a SaaS set up where the email should be sent from the customer's domain?
"What are the best practices while sending domains in a SaaS set up where the email should be sent from the customer's domain?"
I'm not certain if by "It is not practical to ask each customer to verify their own domain using DNS verification." you mean a) verify their domain with the ESP (Email Service Provider, i.e. SendGrid, Mailgun, etc.) or b) ensure each customer has a proper TXT SPF DNS record that allows the ESP being used to send email on the domains behalf.
Regardless, even if it seems impractical, you'll want to minimally have b) done. You'll need to stress the importance to your customers that a proper SPF record is in place. You could write a simple tool to help them get one that would work. If you have to, explain the importance of a proper SPF record for email delivery is like having a proper A or CNAME record pointing to the correct host for their website. If not setup properly and correctly people won't get their content (they won't get to their website in the CNAME/A record case and they won't get their emails delivered to their users in the SPF record case).
It sounds like you are looking for a solution similar to the company I work for has/does. We sell SaaS and utilize SendGrid for our ESP. For each of our customers we setup a separate Subuser. We set the "from" address to be that of our customers and for the most part it works. We stress to our customers that they should create a SPF record in their DNS records if possible to ensure better deliverability. Some of our customers use email addresses such as lastname.firstname#hotmail.com Unfortunately when they don't use a custom domain, particularly one of the major email providers, their mail often gets dropped by their provider or goes to SPAM since the major players have DNS records that don't allow/authorize ESP's to deliver on their behalf.
For a project I need to setup either a mail server (like Open X-change, Kolab) or I can use email service as Saas from providers like Mailgun, Sendgrid etc. But my prime requirements are:
Create new email addresses using (Rest) API or any other API programmatically.
Ability to create huge number of email ids (more than 10,000)
I have researched and found some like mailgun provides facility of sending / receiving messages through APIs. But nothing was mentioned about creating new email ids using APIs.
Does anyone know any mail server / SaaS which provides the aforementioned facilities?
To have a mail id, you need to be able to accept messages at that location, which would be a full mail service such as Gmail.
If you just need to send "as" addresses, you can use an SMTP service such as SendGrid. You'd just need to make sure the domain is legitimate and can receive mail, and that you set the Reply-To value to something that you can accept mail at.
Given multi-tenant application, How are vendors implementing email notifications from an email account setup and programming perspective:
Sending emails could come from a generic account: eg notifications#VendorName.com or noreply#VendorName.com, this seems reasonable considering reply addresses and lilnks can be contained within the email contents.
Receiving Emails: How would an application receive email, for instance; to generate support tickets or assign comments in an email to a project/task. I have seen ID's within the subject and some reply to addresses containing the account name eg: notifications#AccountName.VendorName.com
I realise one can programatically connect to a pop3 server and receive emails and look for the IDs with the subject, but is there a way of setting up and receiving email to a single pop3 account from multiple sub-host name email addresses (not sure on terminology there) eg: noreply#AccountName1.VendorName.com or noreply#AccountName2.VendorName.com and check the Account Name from the address? (similar to checking subdomains on a URL)
Any practices, experience, comments or sughestions?
(not sure its relevant, but using C# asp.net-mvc and services etc)
For sending notification emails, we have a notification send to address associated with each account and simply send from our domain to that address. Our from address is monitored and replies end up in the CSR work queue.
For inbound emails, we use FogBugz (from the makers of Stack Overflow) for case tracking. That accepts new cases via email (e.g. cases#mycompany.com). Tickets are auto-created from the email. My only complaint there is that the customer needs to check an obscure link for case updates (no "my cases" web portal, but maybe that will come out in an upcoming version of FogBugz).
We have a custom field in FogBugz to indicate the customer the ticket is from. We could theoretically write a plugin to FogBugz that auto-assigns that using the senders domain, but I guess the CSR's haven't complained loudly enough yet :-)
We (at muHive) are an inbound email/social conversations management product. If you are looking at a handling inbound email or social media conversations from customers, we have an impressive toolset.
For our own outbound needs, the simplest way is to use an Email sending API. Don't bother with SMTP sending by yourself. We use Amazon SES and have also tried Sendgrid which gave us additional benefits like delivery status and email parsing.
There are two ways in which you can handle multiple accounts to a catch all email address. If your target system can differentiate between different customers and assign tasks to the correct representatives based on either the content/sender, ask all your customers to send an email to support#company.com.
As you rightly said, you could also create *accountName_support#company.com* email addresses and use different accounts on whatever CRM/Support solution use to manage these emails.
Another approach is to have your customers send you an email to support#company.com and you use a rule based system (like muHive) to forward these mails to the appropriate account executives based on the customer/account who sent the mail.