All the emails which I sent via SendGrid is getting deferred. On the SendGrid Activity dashboard it shows the message. "554 Your access to this mail system has been rejected due to the sending MTA's poor reputation. If you believe that this failure is in error, please contact the intended recipient via alternate means."
It used to work 3 months ago. For the past 3 months, there were only very few email being sent out. Now All the emails sent are getting deferred.
Please let me know a fix for this.
Thanks in advance
I think I figured it out. I'm using shared hosting of SendGrid, so the server is being used by others as well. Go to the activity overview, and click the info icon. You will see more information, in my case it's like:
...Client host [149.72.39.137] blocked using Spamhaus. To request removal from this list see https://www.spamhaus.org/query/ip/149.72.39.137...
If you click the link, you can see the reason:
So here it's obvious that some phising was going on, therefore, mails are delayed and/or blocked.
I guess to solve this, we should upgrade to have a dedicated server...
Related
I have a client who communicates with me via email. Crazy, I know.
Here is the issue: When I send him an email from Mac Mail — with my URL in the footer – he receives it. However, when he tries to reply from his gmail account, my server bounces it back to him. The error is "554 rejected due to spam content". (a false-positive)
I can not collect the Spam Checker data from his email headers, as he is not tech savvy. I can not duplicate the error using a gmail account of my own. I have eliminated all possible problems, except the URL in my footer, which triggers this every time.
My email server is: 01-ah-r28u33-ss05.alphahosting.com
His gmail server is: mail-ob0-f172.google.com
Both of these (and also my test gmail server) are shared servers and have some blacklist reports. However, I have no such problems from other clients. My concern is that this could be a reporting problem, and I am failing to hear from those who would rather delete my email than give me a call. I think that you can understand my concern.
Please help, and do let me know if you need any other data that I might add in here.
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.
Mandrill does not offer any support. I've sent them many tickets, but still no answer. I hope someone here will help me out.
I'm sending emails through SMTP. I'm able to send few thousand emails in start, but after few thousands, no email reaching any mailbox. Mandrill activity showing that the email is delivered, but it's not and there's no email in backlog. I have limits around 50K/hour.
I tried making another account after a day, and did some deposit too, but same thing happen with other account too. No error in SMTP client, no error in logs, nothing.
Other thing to notice is, when I hover over 'Delivered' it says "No SMTP event", but emails which are actually got delivered, showing some stats on hover over.
The Mandrill Delivered-status in the UI doesn't actually mean that it is sent, only that Mandrill have received the message for processing. This is of course extremely confusing.
The only way of seeing if an email is actually sent (i.e. successfully delivered to the receiving mail server) is to see if the message has smtp-events. Do note that it can take some time before the SMTP-events are available in the GUI/API (I have experienced a delay of between 2 minutes and 24 hours).
To see all emails that not currently confirmed delivered you can search for "NOT smtp_events.diag:250" in the search field.
After some research, one of the reason, I came to know that if TEST API KEY gets used to send emails, no mail is actually sent to inbox, but webhooks trigger normally and it shows status as delivered on the Mandrill UI. In order to check actual delivery of email to your inbox, please try to use different API KEY other than test account
It turns out to have been a delay in the emails being received by the mailserver (gmail). It appears as if they were accepted and not processed for a few hours.
I had run in to the same issue and this explanation given by OakHosting_James helped me a lot in understanding what is going on:
It turns out the message was sent from IP that is on an RBL (it happens - I get that). So the receiving server rejected the message at SMTP time.
They replied to say two things about that:
(i) Anyone can set up a blacklist and put any IP on for no good reason.
(ii) Some messages bounce in such a way that Mandrill is not able to detect that it's bounced - which is why their website said "delivered".
Let's take those issues:
(i) It's true, but this was UCEPROTECT-Level 1. They're not a pleasant blacklist to work with, but they're not a backyard project for someone with an axe to grind. I still get the fact that it's impossible for any sending network to remain 100% clean. I'm not frustrated that one of their IPs was listed temporarily. But I did feel fobbed off by being told that there are some tiny blacklists out there that no-one in their right mind would use. UCEPROTECT is not one of those, and they should have come clean: "Even with the best spam protection, we get blacklisted occasionally; we detect this very quickly and switch to other IPs."
(ii) I'm sure there are some after-the-fact bounces that Mandrill's system can miss. But this was rejected at SMTP time. How can they mark a message that never left their sending server as "delivered"?
So the solution (to some degree) to the RBL IP problem (i) could be an "Dedicated IP $29.95 / month" for your account in Mandrill. But using a dedicated IP can be a problem on it's own and is for most cases not advised.
In your mail.rb file you need to do the following :
ActionMailer::Base.smtp_settings = {
address: "smtp.mandrillapp.com",
port: 587,
enable_starttls_auto: true,
user_name: "yourname#gmail.com",
password: "apipassword",
authentication: "login"
}
We have a desktop system that sends various e-mails to the users. These users have the option to choose to receive a copy of all these e-mails in his/her Facebook message inbox and we do this by sending a copy of the e-mail to the user's #facebook address.
For some time, this was working with no problems but recently a client reported that some of the messages sent to the user's Facebook address were failing and returning.
After analyzing the returned message, we found that the diagnostic code was "POL-P8":
554 5.7.1 POL-P8
http://postmaster.facebook.com/response_codes?ip=143.106.10.159#pol-m
Message refused (in reply to end of DATA command)
Looking at the code description page (http://postmaster.facebook.com/response_codes?ip=143.106.10.159#pol-m), we found that this particular code translates as "The message does not comply with Facebook's abuse policies and will not be accepted.", which seems to tell us that the message was considered spam and, therefore, not sent.
Still, we don't know exactly why this is happening. It doesn't appear to be related to the message content, since we tried manually sending an e-mail with the exact same content to the #facebook address and it was sent and received with no problems. We also thought that the problem could be caused by a large number of messages being sent to the user's inbox in a short period of time, but we also weren't able to reproduce this.
I did not find any detailed information about compliance to the "Facebook abuse policies" so I am a bit lost on what could be the problem and what could be done... any help someone can give me will be greatly appreciated!
I'm sure this must exist, but I can't find anything anywhere that does this. What I want is some online service that provides an email address I can send an email to, and guarantee that it will always bounce.
The reason I want this is to test the bounce-handling functionality of a piece of software. Obviously I can use some kind of valid address that I know doesn't exist, but that doesn't seem like good practice, even though this is only for a one-off test, not something that will be automated (at least not yet).
Ideally, I'm looking for something like Mailinator, but where I can send messages, see them pending, and choose whether to bounce them, and what type of bounce.
Google did turn up this address bounce-test#service.socketlabs.com, but as far as I can tell, it's no longer bouncing messages, because when I try it I'm not getting anything back.
Any suggestions?
EDIT
As per John's post below, the service seems to be working again - tested on 30th September 2016 from Gmail, and got a bounce response within 5 minutes.
We have a bounce test email which we recommend to our customers and anyone is free to use it.
It just replies back:
:fail: No such person at this address.
The email is: bouncetest#tribulant.com
We have it listed in our documentation for our newsletter plugin for WordPress: http://tribulant.com/docs/wordpress-mailing-list-plugin/382#doc1
Hopefully someone will find this useful since there doesn't seem to be any easy way of testing bounces like this specifically.
I use bounce#simulator.amazonses.com for AWS SES.
http://docs.aws.amazon.com/ses/latest/DeveloperGuide/mailbox-simulator.html
From the above page:
"You can only access the mailbox simulator by using Amazon SES. You cannot access it from an external mail server."
It's worth noting that bounce#gmail.com bounces, with a 'no such user'. To verify (even though the likelyhood was low), I attempted to create an account in gmail as bounce#gmail.com, and it failed stating it was already taken. So clearly google has reserved the address, and the only use it could possibly have is to generate bounces.
Even though - as of 07mar2019 - the bouncetest#tribulant.com still works, bounce#gmail.com is also a fair alternative.
Curiously, bouncetest#gmail.com....gets delivered. Whether there's a human on the other end is a question yet to be answered...
I work over at SocketLabs. First, I apologize that we are seeing this message so late. I just wanted to stop in and provide some follow-up on this issue for anyone who is still interested.
The SocketLabs bounce email address is working. I tested it on Friday, September 23, 2016 and successfully received a bounced message.
The address is bounce-test#service.socketlabs.com
I would suggest trying again. Or contacting support. Our support team is very responsive and friendly. Here's a link to reach the support staff. https://support.socketlabs.com/
http://www.socketlabs.com/blog/bounce-and-feedback-loop-test-addresses/
bounce-test#service.socketlabs.com
Since the Socketlabs service is no longer active and the SES simulator is only for sending from local SES accounts, I ended up having to use my own domains hosted at either Google Apps or cheap shared (CPanel) hosting:
For soft bounces, set up an email account and set it to suspended.
For hard bounces, send email to an invalid address (and make sure you don't have catch-all turned on)