SendGrid Emails Getting Rejected as Spam

Question

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?

Solution 1

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.

Solution 2

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.

Solution 3

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.

Solution 4

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

<a href="http://yourdomain.com">yourdomain.com</a>

sendgrid may replace the href and you end up with something like:

<a href="http://sendgrid.net/....<very-long-url>.......">yourdomain.com</a>

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/

Solution 5

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.

View more solutions

Comments

[Stephen Tetreault]

I've got the most bizarre scenario, I've set up automated email accounts in AWS WorkMail/SES and set up Sendgrid as well. Firing off emails from a sendgrid lambda script, 3 projects work perfectly w/o whitelabeling. 1 project always go to spam even after setting up DKIM and whitelabeling. So to anyone reading -- whitelabeling isnt a bullet proof solution

[D G]

This seems to be a common issue with SendGrid. Many of their servers are on the block list at SpamHaus (who are the spam filter service for Outlook, and probably others). See spamhaus.org/sbl/listings/sendgrid.com. There seems to be a lot of spammers taking advantage of their free tier and therefore causing this ongoing issue. I can't even test their platform without having to pay a minimum of $90 per month for a dedicated IP, so I'm forced to look around for alternatives who don't offer a free tier.

[Adambean]

I concur. It doesn't help that SendGrid intentionally discard legitimate spam/abuse reports via Spamcop. They're just making a terrible reputation for themselves.

[collimarco]

Not every website can afford to pay $100/mo for a few emails... Blocking all Sendgrid small plans is not respectful to those who have a small business and see the legit emails not delivered. At least you could store them in the spam folder and let the user decide if that sender is spam or not (e.g. like Gmail, with a large "Report not spam" button). Your strategy of detecting spam based only on the money spent is terrible and unethical.

[Scotty H]

Second link is broken

[PulpDood]

Thank you! We had a situation where only a small subset of our users weren't getting password reset emails. Turns out that this was due to us rebranding, the email sender was using the old domain whereas the link to the password reset in the email was the new domain. So there was a domain mismatch. And it must've thought it was a phishing email. Changed the domain