We are new in Sendgrid and we want to use it to track our system email but it did not seems to work with the new API key. The system are using do-not-reply email to track on the user activity.Can I know how can we authenticate this email to keep track on the activity in the SendGrid?
If you want to receive emails with SendGrid you need to do a few things. Here's an overview of what you'll need to do:
Get a domain that you want to receive emails on.
Set up MX records for a hostname on that domain to receive emails via SendGrid. Note that the hostname you choose (it can be a subdomain) should be used exclusively to parse your incoming email. The MX record should point to mx.sendgrid.net with a priority of 10.
Set up the webhook URL. In your SendGrid dashboard, click settings, then Inbound Parse and then Add Host & URL
Specify the receiving domain or hostname and a URL that will receive the webhooks when an email is received.
Save
The process of setting up the Inbound Parse Webhook is documented in detail here.
What you do with the webhook from then is up to you.
Related
All I have is an email client (emClient) and a working sendgrid account. When prompted to enter an email address, I can happily put anything#mydomain.com and it will confirm that it works with SMTP. I can also send emails using this client. I authenticate with the username apikey and my api key.
However, these emails are permanently stuck in the "outbox" and are constantly sent over and over again, presumably because the client has no confirmation that they were sent. When trying to set up a new account under this domain, I setup my "incoming server" as smtp.sendgrid.net and provide my credentials and it sort-of works (after prompting me for my authentication?).
As you can see, SMTP authenticates just fine and this makes sense as I am seemingly able to send email. However, both IMAP and POP3 when I select them in the "incoming server" are stuck on this "testing" stage until they fail.
Now, if we skip ahead to me sending something out - basically, it works. I receive the email on the destination, it does not get marked as spam and it comes from my domain and my name.
However, when I attempt to receive an email on the anything#mydomain.com one, it just doesn't do anything. I don't get an error from gmail that it wasn't delivered, it simply just doesn't get delivered.
For my domain settings, I have the following configured:
Twilio SendGrid developer evangelist here.
While SendGrid allows you to send emails over SMTP or via the API, SendGrid is not a full mailbox that you can connect to over POP3 or IMAP. You cannot connect to SendGrid using an email client, that is not what it is intended for. SendGrid is not a mailbox, but a way to programmatically send and receive emails and other email based events.
The way to receive incoming emails is via the inbound parse webhook. When you have set that up, incoming emails to your configured domain will cause a webhook, an HTTP request, to be sent to a URL you configured, with all the information about the email.
Background: I was handed the reins for our company's AWS account to implement a process to make sure our SES delivery report notifications can get acted on instead of just being filed away or deleted.
That said, the first hurdle is that the email address associated with our company's helpdesk keeps receiving all Amazon SES notifications for bounces, complaints and delivery failures. This creates a mess for our support staff in having to wade through these emails individually, and our ticketing system doesn't have the capability of auto-forwarding emails even though I can categorize them based on rules when they arrive.
I have read through all the knowledge base articles for SES notifications as well as ~380 forum topics relating to email notifications, but I didn't see an answer posted this question even though it had been asked a handful of times.
What we've done:
Set up a dedicated email inbox for these requests so we can then process them correctly (that we want to divert these messages to).
Created an SNS topic with the new email address as its endpoint and applied it to all categories, but the emails still kept going to support, so that clearly wasn't the solution.
Removed all hard-coded references to these emails from our software code, but we still get individual Amazon SES notifications to the helpdesk (~30 a day).
Simple idea, but AWS is pretty intimidating especially for our small company where no one has taken the time to learn through the ins and outs after first setting it up (fire and forget).
Edit for clarity, the emails I'm trying to redirect are "Delivery Status Notification (Failure/Delay)" and "Undeliverable:..."
Here's how i got this to work:
Under "AWS SNS"
Create an SNS Topic
Create a subscription to the topic that sends an email to your desired "catch address"
Confirm this subscription by clicking the link sent by AWS to this address
Under "SES Management - Identity Mangement"
Verify a domain or email address
At the domain/email address go to Notification and DISABLE Email Feedback Forwarding
Same place select your SNS topic for Bounces and Complaints
Under "SES Managment - Email Receiving"
Create a Rule set and then create a rule with the domain or email address above
Make the action the SNS rule above
When sending mail be sure that the From address is using the domain/email address above. All bounces and complaints should now end up in the catch address inbox. ALL OF THIS must be setup in the same region.
These notifications are configured either at a verified Domain level or at a verified email address level. This page has info on it. At the bottom, it talks about how you can confirgue to have messages sent to email or a SNS topic. You probably have a notification setup on your domain or the specific email address you are using.
You'll find all this in the SES section of the AWS Console under the Identity Management section. Make sure you check both the Domains area and the Email Addresses area.
You make the feedback address differ from the sender by setting the Return-Path header in your message (subject to a few other rules):
From the developer guide:
If you used the SMTP interface to send the message, then notifications go to the address specified in the MAIL FROM command.
If you used the SendEmail API operation to send the message, then the notifications are delivered according to the following rules:
If you specified the optional ReturnPath parameter in your call to the SendEmail API, then notifications go to that address.
Otherwise, notifications go to the address specified in the required Source parameter of SendEmail.
If you used the SendRawEmail API operation to send the message, then the notifications are delivered according to the following rules:
If you specified a Source parameter in your call to the SendRawEmail API, then notifications go to that address. This is true even if you specified a Return-Path header in the body of the email.
Otherwise, if you specified a Return-Path header in the raw message, then notifications go to that address.
Otherwise, notifications go to the address in the From header of the raw message.
I'm building an app to allow my users to send email. I want the email to originate from their domain. Currently, email is sent on behalf of my Mandrill account with their name/email used for the From header. It "works" but most of the mail is not delivering as best as I think it could.
The way I see it, one option is to use a service like Mandrill, Mailgun, Sendgrid, etc and have my users update there TXT records to verify their domains, thus allowing me to send on behalf of my users. Is that correct?
I'm wondering if another option would be to collect SMTP credentials, and then send the message via SMTP for my user, thereby preventing my user from having to log in and update their TXT records before using my app to send messages. I think it would be far easier to simply add SMTP credentials. Is this possible?
"The way I see it, one option is to use a service like Mandrill, Mailgun, Sendgrid, etc and have my users update there TXT records to verify their domains, thus allowing me to send on behalf of my users. Is that correct?"
Correct you'll want them to minimally have an SPF record that says the service you use is allowed to send email for the domain. I.e. TXT v=spf1 +a +mx inlcude:sendgrid.net ~all
"I'm wondering if another option would be to collect SMTP credentials, and then send the message via SMTP for my user, thereby preventing my user from having to log in and update their TXT records before using my app to send messages. I think it would be far easier to simply add SMTP credentials. Is this possible?"
Not really. They'll need to make sure their DNS records minimally have a valid SPF (TXT) record, otherwise the major email providers and players will either drop their messages or mark them as SPAM/junk.
I have a use case for an email flow that looks something like this:
1) User sends an email to a specified address
2) Service receives the email and pings a webhook with the email in json format
3) My webhook/backend runs a quick check on the sender's email address and either:
4a) Creates an email and sends it as a reply to the original user, or
4b) Forwards the original email to another destination (it's important that the forward email retains the original senders address/reply-to etc.
Ok, I can easily get as far as 4a) using one of a few services (PostmarkApp, Mailgun, etc), but I'm struggling with 4b) - forwarding using an API.
The closest I can get is to receive the email into my Mailgun account and set a route that both stores it, and pings a webhook URL.
It then seems like I should be able to instruct Mailgun to forward the stored email to the final destination - but I just can't figure it out.
Anyone been here before?
I'm asking here before trying Mailgun support.
Thanks.
I want to use Mailgun to send/receive messages programatically via API.
BUT I need to have also some mailboxes available using Thunderbird or other mail client.
For example I want to have user mailboxes at:
support#
sales#
admin#
And all other e-mails will be for API send/receive.
I can not forward my mail to GMail because I need to reply from the same address (sales#mydomain.com).
Please help.
There is a limitation to using the routing feature and that is that if you delegate a domain to be used by Mailgun you cannot use it with an email client.
That means that, for example, if you want to route emails to user#domain.com and then still use that email address with your favourite email client (be it Thunderbird, Outlook or Gmail) you can't do it. That is because of the way you've configured your MX records (email records in your DNS).
When you use Mailgun's routing functionality you delegate MX records to mailgun, which receives your emails, parses them and routes them according to your preferences.
So how do we solve your problem?
What you can do instead is set up your MX record on a subdomain.
Using subdomain.mydomain.com and pointing its MX records to mailgun will allow you to receive and parse emails through Mailgun.
This way you can have:
admin#subdomain.mydomain.com
sales#subdomain.mydomain.com
etc
will be handled by mailgun
while
admin#mydomain.com
sales#mydomain.com
will be handled normally with your email client.
Please do not hesitate in asking more details!
You need to configure your MX record settings for your subdomains in your DNS control panel.