I am trying to use sendGrid with Google Cloud Composer and providing SENDGRID_MAIL_FROM value noreply-composer#domain (noreply-composer#gmail.com), while running the airflow dag receiving error 403: Forbidden
. I did some research and got to know that from should be verified in the sender list. But if I just want to send alert mail with noreply user, this username physically doesn't exist and can not be verified.
Does anybody know workaround for the same, so I can send the mail with noreply username?
Elaborating more to my comment, according to SendGrid documentation pages, each sender identity should be verified using either Domain Authentication or Single Sender Verification. Based on the intro of Single Sender Verification as of most common use case restriction:
You can send only from the address you verify rather than any address
on an authenticated domain.
With said this, you might have to validate email account ownership for each FROM email address entry.
Domain Authentication will probably help to overcome the above mentioned limitation, however it requires to edit DNS records of the domain provider name resolution service:
You can send from any email address on your authenticated domain.
After adding CNAME, TEXT or MX particular records to your DNS service, they need to be validated in SendGrid UI.
I encourage you to check out the relevant tutorial to give more essential outcome.
I keep getting these bounce backs, works on any other domain gmail, yahoo but not outlook/hotmail. is it me or them? I am using Smartermail with all possible settings setup ie DKIM SPF ii basically get a perfect score on https://www.mail-tester.com/web-zorml
Could not deliver message to the following recipient(s):
Failed Recipient: xxxxxxxxxxxxxxxxxxxxxx
Reason: Remote host said: 501 5.5.4 Invalid domain name [DB5EUR03FT018.eop-
EUR03.prod.protection.outlook.com]
prod.protection.outlook.com is Outlook/Microsoft's anti-snooping service. In case you didn't know, by viewing an email header, you can see the sender's IP. In order to circumvent this, Microsoft/Outlook sends your emails to prod.protection.outlook.com and then to the recipient, so if someone views the header, they get prod.protection.outlook.com's IP instead of yours. My guess is that your email provider doesn't recognise prod.protection.outlook.com as a valid domain name and thus can't send the email.
I am developing the application that receives emails from the different users and processes them in some way.
For this purpose, I started to use Amazon SES service. According to the documentation, I verified my domain (set up MX record, added email-smtp.us-east-1.amazonaws.com and so on). Also, I set up the rule for processing received an email (it is lambda function). I didn't add any IP Address Filter so it has to receive emails from all sources.
Now, I trying to send the email to a random address on my domain (for example, admin#mydomain.com) from my Gmail account. But my message isn't delivered and response from the remote server is 530 Authentication required.
I googled my error and saw only issues related to sending emails.
What have I missed with receiving email on AWS SES?
EDIT:
This how my records look. Name fields are mostly empty because system skip my domain name (for example: change _AMAZONSES.mydomain.ext to _AMAZONSES).
I'm trying to get the basic "hello world" of sendgrid working, but have so far been unsuccessful. The response returns code 202, suggesting that it will send the email, but the email never sends out. Does anyone know what's going on?
import sendgrid
sg = sendgrid.SendGridAPIClient(apikey='**my-api-key**')
data = {
"personalizations": [
{
"to": [
{
"email": "me#gmail.com"
}
],
"subject": "Hello World from the SendGrid Python Library!"
}
],
"from": {
"email": "me#gmail.com"
},
"content": [
{
"type": "text/plain",
"value": "Hello, Email!"
}
]
}
response = sg.client.mail.send.post(request_body=data)
print(response.status_code)
I just had this issue: I created an account with SendGrid and tried to get the basic example working, the API would return a 202 response, but the email was never sent, and the SendGrid web UI's activity feed showed no activity.
I submitted a SendGrid support ticket and ~8 hours later received a response saying that they had disabled my account's ability to send emails:
Hello,
Thanks for contacting SendGrid Support!
It looks like your account has been closed by our compliance team and this is the cause of the issue.
To reactivate we’d like to know a little more about the email you’ll be sending through SendGrid. Please elaborate on the following:
The nature of your business, the services you provide, and your potential customer base
Your sending frequency and volume
How you collect your recipient addresses (link to opt in page, or sign up process)
How you will allow your recipients to opt out of your emails (whether you plan to use SendGrid’s one-click unsubscribe feature, or if you have your own method)
The types of messages you will be sending (transactional or marketing)
Please reply at your earliest convenience in order to continue the activation process. Thanks for your cooperation!
~15 hours after submitting my answers, I received a response saying my account had been "activated":
Hi nathan.wailes,
Thanks for the additional information! Your SendGrid account has been
activated, and can now be used to send email. To get started, check
out our Getting Started page.
If you hit any snags while you're getting set up, you can find
solutions to common problems and FAQS in our Knowledge Base.
Let me know if you have any more questions!
Best,
Stevin O.
Associate Support Engineer
When I then ran the basic example code with my email address set up as the recipient, the email showed up immediately in my Gmail inbox.
Debug this by going to the sendgrid api log here:
https://app.sendgrid.com/email_activity
In my case, it was a DMARC receiving domain block.
The 202 Accepted Status Code returned from SendGrid does not really indicate that the message has been successfully delivered to the recipients inbox. It indicates that the message is valid and has been "Queued For Delivery". Now, it is up to the receiving server to deliver this message to the recipients inbox, or to send it to spam, or simply drop the message.
There are several reasons as to why messages that returns 202 Accepted Status code from SendGrid does not actually get delivered to the recipients inbox.
For example:
Invalid email address: The email address may no longer be valid (example, when an employee stops working at some company, their email might be removed from the company's system removing the ability to receive any email).
Blocked Emails: If the sending IP or domain is blocked or if the recipients inbox provider has some filters set up such that some specific content of your email/campaign is considered spammy and thus gets automatically blocked.
Another thing to note is that SendGrid may send the messages to spam/junk if the domain authentication has not been properly set up. So make sure that your domain is properly authenticated.
Here is the link to the documentation from SendGrid that explains these event in details. https://sendgrid.com/blog/delivered-bounced-blocked-and-deferred-emails-what-does-it-all-mean/
I had same issue and solved it by adding new api key with full access
In case someone will come across this looking for an answer to a similar problem. I solved the same problem by confirming the domain with DNS records - after that everything worked like charm.
In Sendgrind: Setting > Senders Authentication > Domain Authentication
For us, the problem was that the used dynamic template was not yet set to "active". Unfortunately no error was shown about the in the API response or the log.
Activating the email template solved this and emails are no longer dropped.
The same issue occurred when DNS is not verified and you are not using register email in from email.
Just change from email to register email.
I recently got the same issue. My e-mails were not sent without any reason, the response status was 202, e-mail activity was empty. The possible solution is to add a company details and add an unsubscribe block to e-mail. That worked for me.
I'm implementing a password reset feature and it's a little weird to have an unsubscribe block for this. I'll try to figure out what was the real reason of such silent suppression. Probably it's because I tried to send a draft debug e-mail several times which was looked like a spam. Maybe SendGrid has some smart algorithms for detecting this.
I also had this issue. I contacted sendgrid support however while waiting I changed the dummy data to real data I was calling sendgrid API with and then it started working.
in particular I changed the from email address to show my own domain.
For me the template was the issue. When using the template engine make sure to use {{variable}} instead of {{ variable }}. Afterwards I received the emails as usual.
My goal is to create a canned email on my server and then send the email from client email addresses. To do this and not be marked as spam I understand it must come from a domain matching the from address.
There are many user email addresses I would need to send email from, all with the same domain. With cooperation from my client, could I set this up to work with one SMTP credential or would I need credentials for each and every individual user?
To clarify, if I get an SMTP server address with a un/pw from my client, would that be enough to send from:
george#example.com
martha#example.com
ted#example.com
Thanks!
It depends completely on the SMTP server you are using. Some servers will allow this, like Google's SMTP, but it will attach a Sender header to the outgoing message when the From header does not match the authenticated account.
Example:
You authenticate with joe#gmail.com
You send out with From: bill#gmail.com
The message will contain From: bill#gmail.com, but Google will attach
Sender: joe#gmail.com to the message headers.
So, it completely depends on the SMTP server and their policy.
Problem
You want to avoid joe-jobbing in your automated messages.
Your Options
It depends on how you're submitting jobs to the MTA.
If you're authenticating to a remote SMTP server for each message, then you need credentials for each user.
If you're injecting messages directly into an MTA (e.g. with the sendmail command) that is authorized to send mail for the domain, then you only need privileged access.