I'm trying to understand a few concepts around sendgrid, whitelabeling and different servers that I plan to deploy the same sendgrid account in.
So my questions are:
1) Is whitelabelling purely for masking the via sendgrid.me and will I have any issues if I dont use it with my current setup(i.e. same account on several domains)
2) How does sendgrid deal with messages that have a "From" email that doesnt match the domain the email is sent from? Cause I read that it would silently drop them but instead I see that emails do get delivered however the statistics in sendgrid's dashboard are not being updated.
3) Upon creating a demo account I was asked to provide the domain from which the emails will be triggered but since I want to deploy this in several different domains will I need multiple accounts or is there an alternative option when you go for a paid plan?
Mike
Yes - whitelabelling will replace the sendgrid.me with your own domain.
You can also setup multiple domains inside SendGrid and assign each to a subuser. That will get you one SendGrid account, with multiple whitelabelled domains and separate sender reputation for each.
SendGrid will attempt delivery of whatever you ask it to send -- if you send an email with a different from domain than the signed sending domain, it's up to the receiving mail server to decide whether to block, flag as spam, or allow the email. Different receiving domains will behave differently.
It's generally best practice to always have your from domain match your signed sender domain.
Once you have one domain setup, you can setup additional domains using SendGrid subusers -- more info here.
If you have a complicated multi-domain setup, you might want to check out a templating API, like sendwithus, for making things easier to manage. They'll integrate directly with your SendGrid subusers on your behalf.
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 have a web application that utilizes several CRM types of emails for notifications, appointment reminders, attachments for digital sales and such. My clients can use my own admin domain email account to send these emails (no-reply email), or they can provide credentials for using their own SMTP server or relay service so that any emails that are replied to are sent to them (vs a no-reply admin email).
However, I'd like to try for a 3rd option where I can create an email mailbox on my a domain like so:
client1#mydomain.com
client2#mydomain.com
...
And then I would apply a forwarding rule on each one to send any replies to their personal email accounts so they wouldn't have to have their own SMTP service.
Now I can do this using providers' interfaces, but I'd rather do it with an API so I'm not having to manually create mailboxes and setting forwarding rules.
Currently I'm using AWS SES for my domain emailing, but I've searched for hours and the "solution" to create mailboxes and create rules to forward are ridiculous.
Are there any other email providers out there that make this easier? I don't need anything fancy except the ability to create a bunch of email mailboxes via API (preferably with a high limit of mailboxes) and the ability to create the forwarding rules via API.
Or can anyone recommend a good email provider that allows for a lot of mailboxes and makes forwarding really easy (and of course cheap).
Like "cringe" GoDaddy Email or something similar??
After a lot of research, this procedure doesn't really make sense these days. There are a lot of relay email providers that make it easy to set up "Senders" so that emails can appear to come from any kind of email account (personal or domain based) for ease of use with applications
I'm currently running a SAAS application and mails are being sent from our application using Mailjet.
Some of the larger customers have been asking to allow the emails to be sent from their domain (e.g. info#largehotel.com) instead of our system (notifications#saasapp.com).
Are there any initial pointers I will need to look at? I'm guessing they will need to add our SPF records to their SPF records too and that they will need add a DKIM key that we generate for them to add to their records too? Then do some validation on them on the DNS level and mark them as validated?
I have some understanding to have customers run their own domain against our SAAS domain but a bit lost on the sending from their email domain requirement.
First, for the record, my SaaS platform does this (vía option 2b). It’s an e-commerce marketplace and I need the receipts to be sent from the email address of the product seller, not from me (the marketplace)
You have two(ish) options
Send email through your client’s mail servers (instead of mailjet)
Verify the client’s domain on your Mailjet (or similar email) service
option 1
With option 1, you’ll need to ask your client’s IT team to setup a username and password for you to access their SMTP server. This is essentially just like them creating an email account for you to use. This may seem like the easiest path available for you, but there are potential pitfalls and disadvantages:
Doing this, you will lose the mail open/click/bounce tracking functionality you get with mailjet; because you’ll be using the company’s SMTP server instead.
If you’re sending out as a fairly common email address (eg info#your-client.com) the client may already have that account active on their mail servers. That would allow them to receive replies into the existing infrastructure but make them wary of the security issues with sharing a password to their mail server with you.
You might find that they don’t even have the ability to give you a username and password. Modern mail services don’t allow for SMTP access (which is what your web app will need); and security conscious companies require 2 factor authentication on mail accounts (which your web app can’t answer)
Option 2
For this, you will need to ask their IT team to configure some DNS records to prove to mailjet, and to the email recipient, that you’re allowed to send on behalf of your client.
You did this for your own domain when you first setup mailjet. See https://app.mailjet.com/support/how-to-add-a-sender-address,96.htm for what this involves, but it’s a case of asking the client to configure a DNS record.
That tells mailjet that you’re allowed to send on behalf of that domain; but you’ll also want the client to adjust their SPF and DKIM records so as the recipient of the emails knows to trust Mailjet’s servers with emails sent from your client’s domain name. Normally, recipients only trust email sent from your client’s mail server (which you have as option 1) and distrust email sent from SAAS providers.
You will (or should) have done this on mailjet for your own domain already as well. https://app.mailjet.com/docs/spf-dkim-guide
So for this, you’ll need your client to setup 3 DNS records.
If you go this way, you could setup a separate Mailjet account which they and you have access to. That way they ca see their dashboard directly and feel a sense of ownership and security around it. But you won’t be able to markup the price of it 😜
Conclusion
How important is the tracking? If you can’t lose that you need to go with option 2.
How technically savvy is the client? Are they going to be able to have those DNS records changed? Are they going to be (rightly) security conscious around giving you an account on their main mail sever.
Option 2 would be my preference. You might need to hold their hand through the DNS setup so get it configured on Mailjet (And ask about SPF in here to make sure you get it right) so you can provide them with clear instructions of the specific 3 DNS records to create/update.
Whatever approach you take make sure you’re talking to the right people at your clients side soon. Their marketing team may be keen to do this with you, but if their IT feels left out of the conversation they will be difficult to get on board when you need them to make the changes. Us IT folk can be grumpy and obstinate 😀
your web app
This is going to need some adjustment. You probably already store your Mailjet credentials in a file or environment variables; these might need to move these to a dB table so you can relate credentials with specific accounts. But we’d need more info on the web app to be able to speak more to that side of the challenge.
option 2b
just as a note instead of a real suggestion. Be aware that some email service provers allow the sending verification part to be done by sending an email to someone on that domain (eg admin#yourclient.com) and then allowing sending vía the API if the recipient clicks on the approve link on that email. But, even with that setup you still need the client to configure SPF and DKIM on their DNS, so the extra one record isn’t a big ask. AWS’s SES allows for this. This works for me; but I have different requirements around deliver ability, and a large number of non-tech users (as opposed to your one or two big clients)
you can ask your client to generate programmatic(app key/password) user for email need to use for example info#largehotel.com and some other info like (host:gmail, protocol: smtp,...) all basic info needed then in your saas retrieve all this info to create object with client info that you stored before to send email for the target (from developer prospective non network engineering )
The SPF is the most important think to do. In most cases you have to be very careful about the IP reputation, but since you are using Mailjet it's up to them to manage this part.
Be attentive to the overall quality of the email, text/image ratio... Also offers a text body version of the content and dont forget the unsubscribe link. Since you already send emails with your service, I guess it's points are already correct.
For an application we are building, it is required to give certain registered accounts the ability to send emails to other registered accounts.
As part of the registration, we obviously collect the real email address of every user.
I do not want to expose any of my users' email addresses so I would like to have the ability to proxy them through fake email address that basically forward to the real email address.
For example, if someone want's to email John Doe, they would send an email to abcdefg12345#mysite.com which would then forward the email to john#johndoe.com.
In case its not obvious, the purpose of this is to protect the end user from spam and keeps their real email address private. Since my application acts as the proxy, I could easily block certain email's from going through.
The most famous example of this is Facebook's email proxy for Facebook Apps.
My Question: Are there any patterns, servers, 3rd party services, or libraries that provide such a feature? Does anyone have any suggestions for how this could be built?
I've never seen a service that offers this directly. The hardest part here is the receiving of the emails and wiring things up to your app for the authentication. You could use a service like http://cloudmailin.com in order to receive the email and then forward it on or even use some sort of custom install. Another option would be to create a script that modifies a server such as postfix's configuration.
Finally although I wouldn't recommend it you could try and create your own mail server to do this. I would read up a little more on SMTP/IMAP and see what options you have.
It looks like there is no 3rd party service or tool\library to accomplish this. It is going to be a bigger task than I was hoping for so I will be putting it off until I have the time to implement it.
I think the solution is to use a mail daemon that has an API or at least allows you to manipulate the users\emails\aliases in it such that you can create new mailboxes on demand and set them to forward from someuser#proxy.mysite.com to user#theirdomain.com
I found out that there are services that provide this type of functionality as part of their offerings:
http://mailgun.net/
http://www.sendgrid.com
Both of these services are very cool and offer quite a bit for sending and analyzing emails including the ability to create forwarding\proxy emails.
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.