I have problems with SendGrid since few days but I did not change the way I config my web apps (Django).
I can see in Activity feed of my account that emails are received by SendGrid but Not delivered because "From field did not contain a valid email address".
I check to ensure "From field" is valid and it is.
I have also seen that 103 mails are sent today but it is not true. I thought that daily email are not reset every day... and as I have a free account (100 email/day) it could also be a problem...
Thanks for advices
The problems was infact that send_from is no longer accepting string like 'a new sentence'. If I change send_from = 'a new sentence' to send_from = 'noreply#mydomain.com' it works. I don't understand why...
I assume that your sender identity email is already verified since you are using it already.
Yes, their daily free mail limit is 100. Since you have hit 103 mails the maximum limit in a day, maybe you are account is blocked. Try creating a new sender identity email and check whether it is working or not with the new API KEY. Hope it works!
Related
I have a Google Workspace (I think that is what it is called) that I use to manage a private email address for a small business.
Everything has been working fine, and I can see the user (richard) in the admin area with associated email set up. I have sent test emails to and from their email account to make sure it is working okay and everything seems to be working fine.
I have two email addresses associated with the domain, for example:
emma#domain.co.uk (me) and
richard#domain.co.uk (richard)
I use the first email address as an admin account, and they use the second one.
They've had this email account for a long time, and have had no problems, however recently they have stopped receiving emails from one sender (their accountant).
I can still send emails to the account from my own personal email address to them, and they are receiving emails from other businesses, but just this one person is sending emails to them and they aren't being received.
Things I've tried:
Checked the spam/junk folders and no emails are there
Checked to make sure the sender isn't on the blocked list
Looked at the email logs as per this suggested article and don't see any record of the incoming email that has been sent
Sent a test email to account#accountant.co.uk and richard#domain.co.uk from emma#domain.co.uk and they both receive my email. When the accountant presses "reply all" the email only gets received by emma#domain.co.uk and never arrives at richard#domain.co.uk
Sent a test email from richard#domain.co.uk to account#accountant.co.uk and she receives the email. When she replies, he doesn't get the reply.
All I can think of is she has somehow blocked him via her email client, but I need to check out all the possibilities of it being a problem at our end as she's not great with email and not sure how I'm going to navigate that one :)
Any suggestions welcome!
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.
I'm making a user management system for my app, and I need to send users a "forgot my password" email with a token that lets them reset their account password. I signed up for SendGrid through Azure (to get the 25,000 emails per month free, which sounded like a great deal) and wrote some code to use it, but after testing my program a bit I was dismayed to find that only a couple of my emails actually went through.
After going onto the SG control panel, I found that 4 out of the 6 test emails I sent went through, and all of the others were rejected as being spam. I sent an email to mail-tester.com to see what it though my spam score was and it gave me a 4.3/10.
The email in question was a single sentence with a link to the password reset, without any images or other elements. I only sent those 6 emails out, so the volume of my emails definitely wasn't the issue. Still, I'm very puzzled as to why my messages are getting flagged as spam.
Without going to the trouble of making an elaborate authentication setup, are there any basic changes I can make to my system to make it get through to users?
In this case it's most likely because you are sending such a short message, with a link to 'reset your password' from a non-whitelabelled email address (the email address you're sending from cannot be verified against the actual domain), and the link may also be a different URL. It's probably getting pulled up as a potential phishing email.
You can rectify this by white labeling your domain and email links via the SendGrid dashboard, it's easy to do and should improve your deliverability.
Also check out this article from the SendGrid support team about White Labeling.
A question from 2015 which is sadly still relevant today as usage of SendGrid increases.
My organization has blocked all SendGrid mails except for those on the paid tier using fixed IP addresses with resolvable public DNS names (such as sendgrid1.sampledomain.tld) which we then whitelist.
There are now far too many domain impersonation, phishing and other spam mails coming in from SendGrid for us to allow everything from them - roughly 10 000 mails over a seven day period, which is far too many to manually report to SendGrids abuse department.
So my answer would be that switching to the paid tier of SendGrid is the better option if you like a better chance of your mails arriving intact at their destination.
I receive only Spam Mails from Sendgrid.
Goes direct to Spam folder and try to report Sendgrid everywhere I can. Maybe they get blocked by most mail servers and make them think about their policy in "hosting" all these Spammers.
In my case my emails are marked as spam because of the anchor label different to the href being actually called.
And that's because of the 'click tracking' setting of sendgrid.
So, if you have something like
yourdomain.com
sendgrid may replace the href and you end up with something like:
yourdomain.com
The sendgrid page being called tracks the click and then redirects the user to the url you originally set. But this sometimes results in your email being marked as spam.
Try to set 'click tracking' in sendgrid dashboard to off: settings | tracking | click tracking.
details here: https://sendgrid.com/docs/ui/account-and-settings/tracking/
Always start by setting up Domain Authentication, formerly known as domain whitelabel as #MartynDavies says. Found under Settings -> Sender Authentication in the UI. Should look like this:
https://sendgrid.com/docs/ui/account-and-settings/how-to-set-up-domain-authentication/
To identify problems have a look at Activity and choose to see deferred, drops, bounces, blocks and spam reports.
https://app.sendgrid.com/email_activity
Under Suppressions you can see details for Blocks and Bounces among others:
https://app.sendgrid.com/suppressions/blocks
https://app.sendgrid.com/suppressions/bounces
There you can see errors like:
550 5.7.1 SPF check failed. em1234.mydomain.com does not declare 11.222.33.44 as a valid sender
If it says Verified but you see errors like this then contact SendGrid support.
One thing that has worked is to upgrade from the Free plan to Essentials or Bronze via the Azure Portal. This made a lot of the emails marked as spam pass through.
I had a similar issue when trying to send a user verification email using SendGrid.
In my case, using a custom domain as the sender identity solved the issue.
Make sure to also verify the domain before using it.
The Problem
I use Apple Mail on OS X 10.10 and have two mail accounts configured--one for work, and one for personal. More than once when I have composed a new message (not a reply), I have forgotten to check the "From:" address and sent a work message from my personal account and vice versa.
The Request
I am looking for a way to automatically set the "From:" account based on who the recipient is when I compose a new message. If the email is a reply, I want the default Apple Mail behavior (reply from the account that the message was received at).
For instance, say I want to send a message to my co-worker John. So I compose a new message and address it to his work email. I want Apple Mail to automatically detect his email address and set the "From:" account to my work email address.
Of course, the list of these email addresses would have to be created, but after the initial configuration the behavior should work automatically.
Another example: Say that the same co-worker John and I are also friends, and he sent me an email to my personal account to set up a time to get together outside of work. When I reply to his email, I would like the "From:" account to be my personal account, since this is the account that the email was originally sent to.
I don't understand how this seemingly common sense approach is not standard issue for email clients in 2015! Surely I can't be the only one who wants more than the universal default "From:" account that Apple Mail--and every other mail client--offers.
I've looked at the AppleScript dictionary for Apple Mail and read some threads here that suggest that GUI scripting may offer this functionality, but I don't have any experience with that.
Is there a way to accomplish this?
The trick is getting Applescript to monitor the new messages being created. If you're willing to go the Keyboard Maestro route, you could remap command-N to an Applescript that gets the recipient address then creates a message with the appropriate sender (see http://www.macstories.net/tutorials/automating-mail-signatures-and-senders-with-applescript-and-keyboard-maestro/ and http://shawnblanc.net/2013/04/keyboard-maestro-email-signatures/ for some related examples).
Or run a script after you've entered the addresses. GUI scripting wouldn't be necessary. It would look something like this:
tell application "Mail"
set m to front outgoing message
set theRecipients to to recipients of m
repeat with r in theRecipients
if address of r is in {"mybuddy#fastmail.fm", "my buddy#gmail.com"} then
set sender of m to "Personal Me <personalme#gmail.com>"
end if
end repeat
end tell
Getting Applescript to automatically do this with no intervention would require a daemon or some other way of monitoring events in Mail. Unfortunately there are no hooks built in.
I use an email registration and confirmation in my project (yes, I know about OpenID. In my counry, a main email service lacks it).
Sometimes users misspell their email addresses. I know about this due to "message could not be delivered" letters in a mailbox. A misspelled address is absolutely correct, because I check it with a regular expression - say, jon.doe#example.com intstead of john.doe#example.com. And I do not want to duplicate a email field in a registration form (who likes it?).
Request processing routine cannot wait for email delivery - it could take an unpredictable time. So, my script will return to user a confirmation message "An email was sent". And the user will wait for it forever (of cause, not - he/she will turn to an alternative project with a more perfect registration system).
Does someone knows how it can be improved (in any programming language)?
If you cannot wait for a response back from a confirmation e-mail, I would display a yes/no message box confirming their e-mail (i.e Send e-mail to jon.doe#example.com?) before sending the e-mail. While your at it, you can check to see if the e-mail is a duplicate as well.
If no duplicate found and they click "Yes" then send the e-mail. If not, ask them to re-enter the e-mail address.
With this approach you have gone above and beyond validating correct e-mail addresses since there are no services that will explicitly check for correct/valid addresses.
Unfortunately, there's no canonical way to spell anything in an e-mail address and no way to check programmatically whether it's spelled correctly or not. The only tool that can confirm the correctness of a valid e-mail address is Eyeball 1.0, which runs client side.
You can try the SMTP VRFY on the server but most won't reply with anything valuable. Most will simply say "go ahead and try it" because returning something useful would be invaluable to spammers.
You can always check the domain name with a DNS lookup but the only way to check an email address is to send a message.
Try to have the user type his email twice with an email confirmation field (as for the password).
EDIT : Anthony's idea is good too.
For user parts of email the only thing I can think of is using:
MX lookups (if mail provider doesn't block them... since that can be abused to filter email lists)
Requiring user to enter email twice to ensure he doesn't misspell user portion of email
As for domain part of email, take a look at this:
AngularJs directive to offer suggestions for misspelled emails?
It helped me to reduce bounce for misspellings like gmai.com and gmail.con.