Ok, I am working on an invite system for my work, the invite system sends an email to the recipient with a link containing a unique token allowing them to sign up.
The issue is, now that I am actually testing it, the emails are marked as "This message seems dangerous" by gmail, This looks really bad for the company. I have not been able to find any information on what triggers this.
The email is being sent via office365(SMTP) as that is what our email is set up with to try and avoid this kind of thing.
I have seen comments online that it may be due to the token link, If so, how else am I meant to do this?
Related
I created an application which uses SendGrid's Inbound Parse Webhook. Whenever someone emails "whatever#mydomain.com", the email goes to SendGrid, and then SendGrid hits our server with a POST containing the email's contents. We can then feed that email data back into our main application.
I have it all working. But now I do not know how I am supposed to authenticate the messages SendGrid posts to our server. Does anyone know the best course of action for doing this? Verifying that our inbound emails actually come from authorized users of our main application?
Obviously we can check the "From" address in the headers, but I've read that these can be completely spoofed. Apparently "dkim" and "spf", two attributes of the incoming mail from SendGrid, have something to do with authorization. But i cannot find anything in the documentation, or really anywhere else for that matter, that tells me how I should be consuming these "dkim" and "spf" fields to verify message authenticity.
If anyone has any help, general, specific, or otherwise.. It would be greatly appreciated. Thanks in advance.
Well. Since this doesn't seem to be getting a lot of traction I thought I'd post my own janky-ass solution to the problem, on the off chance that anyone else runs across this issue in the future.
Disclaimer: this could be total garbage nonsense. But it appears to be working all right.
Basically I ended up taking some critical contextual information about the original message that initiated the inbound email. We encode that information in the local-part of the "Reply To" address that we set up with the SendGridMessage. Then I encrypt the encoded local-part.
When SendGrid POSTs to our server with the inbound email, we decrypt the "TO" local-part and validate the result. If it decrypts successfully, we check the "FROM", and verify that they are an actual authorized user of our main application. THEN, we verify that THAT user in question has the correct permissions to edit the information associated with the original encoded local-part of the "Reply To".
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.
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.
I'm building a website that allows user to connect using Facebook Connect. So far I'm able to log the user in and fetch data about them (name, email, pic, etc.). If I fetch the email (using Users.getInfo) I get a proxied email (apps+blahblah#facebook.com), which is absolutely great. Problem is, that email doesn't work. I've tried sending an email to it and I never received it. There are two reasons I see that could cause this:
I don't have enough permissions. Ok, I can understand that, but if I don't have enough permissions then why are they returning an email at all?
The email has to be somehow sent from the application itself (I've tried sending it from my Gmail account) -- but how would Facebook know that the email is coming from the application?
So which is it? Or is it something else?
I have recently been looking into this as well.
I did find some guidelines on http://www.insidefacebook.com/2010/01/15/facebook-platform-email-sharing-api-proxy-email-service-going-live-in-5-days/
here is the most important part:
Emails you send must clearly indicate that they are from you and must not appear to be from Facebook or anyone else. For example, you must not include Facebook logos or brand assets in your emails, and you must not mention Facebook in the subject line, “from” line, or body header. All emails to users must originate from the same domain, and you must provide us with the name of that domain in the Facebook Developer application used to manage your application.
I have already found that if you do not have the address in the from as #facebookappmail.com
might even have to be appname#facebookappmail.com the emails will bounce. So sending from your gmail will not work, the "blah blah blah" in the proxy contains the application information of the application that had the permissions to get that email.