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.
Related
My team supports a website for a client, and we use SendGrid to send email related to the site on their behalf.
We do not have anything to do with their own email server and I don't at present know anything about it.
So far as I can work out, SendGrid has proper authentication and is an authorised sender for their domain, and almost 98% of email is delivered successfully.
However, we have had a handful of bounces with the reason "550 relaying denied" and all of these were to addresses at our client's domain (the same one as their website and the from address of the emails.)
Most emails to their domain were delivered successfully.
Unfortunately I don't have access to the full headers of the bounce emails, only the reason.
I understand that in general this error can either be caused by
the sender not being authenticated correctly. I am very far from being an expert in this but so far as I can tell, there is nothing wrong there. Or
a DNS or similar misconfiguration on the part of the recipient's email domain. I have even less understanding about this and I have no access or responsibility for the client's email server.
My main question is, is there any way the domain being the same as the from address could be related? Being as the email is claiming to be from the same place it's sent to, is it possible for that to affect how it's handled by relays?
If not, I'd also appreciate any pointers on where to look for the issue (or what to advise the client to look at if the problem is likely to be from their end.) I have been trying to research issues with email configuration and authentication but I am very much a novice in this area.
Thanks in advance.
The domain being the same could very well be related, but normally when that happens, the receiving server refuses all mail purporting to be from itself.
Separate from DKIM & SPF, most mail servers believe they alone are responsible for the mail from their domain.com. As such, a lot of them have anti-phishing filters that reject "outside" mail that claims to be from themselves. It's like "You can't be Carrie, I'm Carrie! Go Away!"
The fact that it's only some mail is interesting. The error being relay denied may also be key, though these anti-phishing filters often use "fake" errors to not give away the game.
Do the recipients of the messages that are being rejected have some kind of internal forwarding applied? That may be the cause, in which case that bounce reason is honest.
Or they may have a more defined anti-phishing feature, only rejecting mail From or For certain addresses. You can try testing certain combinations, and see if anything is repeatable.
Ultimately however, it will come down to working with the receiving mail domain's admin, and either updating those rules, or whitelisting the SendGrid IPs that are sending the mail to them.
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.
I am trying to send mails with mailgun. My DNS config (SPF,DKIM) seems to be ok and are being validated in mailgun service. I can send mail to several users with gmail, live and most others mail providers. However, I have a problem when I sent an email for email accounts of my university.
The message is rejected with the following alert:
"554 5.7.1 : Client host rejected: MX-CIDR"
My current DNS settings are:
TXT # "v=spf1 include:mailgun.org ~all"
MX 10 mxa.mailgun.org.
MX 10 mxb.mailgun.org.
DKIM was validated as well. I checked my domain at mxtoolbox and the dns config pass in all tests. I did not find errors related with that alert in others questions. May someone help me to fix it?
Update 1:
Just some more informations:
1) I dont send, and I have absolutely no intention to send spam. I created an educational website, used by students and instructors, and they send messages sometimes between each others. I also send mail to confirm registers, recovery password, as a lot of others websites do. I only send messages to people who was agreed with my terms of service, that includes the information about my mail policy. It is a small service, I never sent more than 2,000 messages in a month (I have 800 registered users so far)
2) I do not believe I was blacklisted, mxtools verify several blacklists databases and my IP have passed in all verifications. Also, the server is not rejecting all messages from my IP, I can send messages with my personal email with the same domain, but I use different services to handle my personal inbox with my domain and the emails send by my website. So, I guess it may be a DNS record mistake.
3) I only use mailgun (or others transactional email services like mandrill or sendgrid) because it is highly recommended (and easy). I use a small VPS and it is hard to configure my own email service (I am a programmer, I am not an expert in that kind of configuration). If exists negative factors about the use of these systems, I really like to know and learn more.
I see no evidence posted that the reason the receiving mail server is rejecting your mail is because of your SPF records.
There isn't even any evidence here that the receiving mail servers are even performing SPF checks on their incoming mail.
Can you explain why exactly you believe that this has anything to do with SPF?
Just because someone's rejecting your mail, and you happen to be messing around with your SPF records, doesn't mean that the reason for your mail being rejected is due to your SPF records.
The only ones who can tell you exactly why your email is being rejected, and what needs to be done to fix it, is the receiving mail servers' administrators, and that's who you should be asking. They are the only ones who know exactly how their mail servers are configured, and how they work. Unless it's evident from the text of the error message, and it's not, anyone else's answer will be nothing but guesswork.
And actually my guess would be that, if anything, the error message seems to suggest that they have simply blacklisted your IP address range, period, for whatever reason. I would interpret "MX-CIDR" as meaning "MX's IP address' (you can Google what "CIDR" means by yourself); i.e.: sending mail server's IP address is explicitly blacklisted from sending them mail.
Now, taking from the referenced domain's web site, I quote:
"Our software automatically manages the delivery process to give your emails the best chance of landing in the inbox."
I would think that the only type of folks who would be concerned about having "the best chance of landing in" someone inbox would be all the typical spamming parasites. I browsed through the referenced website, and I couldn't shake off a slimy feeling I get after typically wandering into a typical spam spewer.
Is this domain being used to send spam?
If so, then you probably know the answer to your question, already.
Certain SPF libraries might reject emails when trying to perform a reverse lookup on the domain that you're sending from.
They usually get this from the MX records attached to the domain and if there's a mismatch it'll fail out with a rejection (more detail here: http://www.zytrax.com/books/dns/ch9/spf.html).
It's usually only a problem if the receiving server is not necessarily configured correctly, or is being super harsh on incoming mail due to an overwhelming amount of spam.
I'm usign amazon cloud services to host my webpage. Our web site, actually sends a lot of emails per hour. In one instant our server could be asked to send 30 mails or more.
Sometimes our clients complaint about not getting emails from the web, which is connected to our mail server to send emails. This doesn't happen if we send the email directly from our addresses to theirs, so I'm pretty much know is the web page who's causing the problem.
The thing is I don't know what is happening and neither know what to look for. I've checked memory and cpu of that server and everything seems to work fine
make sure your website sends the messages with a correct bounce address (aka envelope sender address). this does not have to be the same thing as the address in the From: header. by default, this is often something like "apache#www.example.com" - I don't know about amazon). these types of bounce addresses are bad because usually you don't receive the error message if something goes wrong. use a real email account. To check what bounce address you currently use, look at the message source of a received mail and see the Return-Path header.
check the logs of your mailserver for those missing messages. either it reports an error (in which case you should get the error to your bounce address) or it reports the message as sent to the target server (in which case you tell your clients to check THEIR maillogs since you can prove you have sent the message)
On our website which is asp.net, we make a sale and an automated email is sent out to the client with an attached PDF invoice we create using a 3rd party app. We are having trouble getting these delivered successfully to some corporate clients. Yet we also send a copy of that same email to ourselves which we receive fine. We can then forward this on to the client and they do receive it no problems. So the original is not received but the forwarded mail is.
The webserver is a seperate IP address to our office Exchange server which sends the forwarded mail.
I have tried to find the difference between the 2 mails and it looked like a rich text issue, except that the mail is plain text or html!
The question is a little vague i know as i do not know where to look for the best. It seems to make no differenec which mail program is used, we tried MailEable and it was the same thing.
Mail is logged on the web server as leaving and that is the last we see of it. It doesnt bounce but it is definatley delivered to the client server, but doesnt reach the recipient. We used to track thru Message Labs and it would say it had reached the destination server ok. We do not use ML anymore until we find the issue, keeping it simple.
We have no issues sending to AOL, Hotmail and Yahoo etc.
It appears something in the email is upsetting server based spam software.
We havnt been able to get hold of any email logs from clients.
any suggestions?
Check out this link mentioning a reason not related to size issues
The SMTP (internet mail protocol) RFC (An RFC is a document describing
the standards that make the Internet work.) explicitly states that the
length of a single unterminated line can be 1000 bytes, no larger.
Some SMTP servers violate this, and the Firebox (this is our firewall)
will drop the connection when the line length exceeds the configured
length, which defaults to 1000.
which might indicate your pdf generator and/or mail generator creates output that's not 100% standards compliant. Might be a good point to check as it could explain why certain customer suffer fom this problem only.
552 Requested mail action aborted: exceeded storage allocation
This means there was a violation at the client's ("customer's") mail server. The message exceeded a threshold/limit of some kind. It's not clear if this is a per-message limit or if the user's mailbox is just so full that it cannot accept another message.
Either way, this is mostly out of your control. Only thing you can do it try to keep your e-mail messages and attachments as small as possible. If you can, compress (zip) any attachments before sending.