I have a survey form that people submit the hours they work and it sends their response in an email to me and then CC's two other people. The script was authorized by me to send the emails and has worked fine for a long time until a couple days ago when now I am getting a reply back from all three emails saying Message blocked. Any idea why these are being blocked?
MailApp.sendEmail("myemail#gmail.com",emailSubject,"", {htmlBody: body, cc: "anotheremail#gmail.com, thirdemail#gmail.com"});
If I only send the email to myself then it works perfectly fine. If I include even one CC email address I get the block.
Reporting-MTA: dns; googlemail.com
Arrival-Date: Mon, 12 Nov 2018 04:57:05 -0800 (PST)
X-Original-Message-ID: <000000000000eb73c1057a773c96#google.com>
Final-Recipient: rfc822; myemail#gmail.com
Action: failed
Status: 5.0.0
Diagnostic-Code: smtp; Message rejected. See https://support.google.com/mail/answer/69585 for more information.
Last-Attempt-Date: Mon, 12 Nov 2018 04:57:05 -0800 (PST)
Using GmailApp.sendEmail(emailAddress, subject, message) solves this.
This seems to be an issue with all new GSuite accounts as discussed here:
MailApp.sendEmail() in Google Apps Script not sending email
It is particularly frustrating that Google has no response to this huge shortcoming for over 4 months!
This likely happens when Google algorithms find any suspicious link in the body of your email. You can consider removing any links from the email and try sending the message again to confirm the issue.
The Google support site has more information.
I do not have a clear answer in here; I just want to be able to converse with devs in the same tough spot between a Google algo and a client having his business interrupted.
#amit: First that link you sent does not cover the actual situation. Second I ran my code for a second time manually and it processed everything perfectly so the content is not the sole trigger for this rejection.
To elaborate:
I made a survey tool for a client (with google biz account) that inputs the results in a google sheet with multiple tabs that receive rows of data. Once a day each tab generates a "day summary" of those results and sends it in an email.
It has 1 TO and 2 BCC targets. The body of the text contains multiple email addresses as clickable links. This worked fine till a few weeks ago.
Now today, without changing anything, the emails were sent out with no bounce/rejections. My conclusion is that it is indeed Google's preventive anti-spam filters doing. Just not as simple as "containing links".
Perhaps it's the time? As I see your email, and mine are sent at 3/4 AM, correct? Perhaps it has to do with the CC/BCC emails never being opened? As my BCC targets are both my client's own email addresses (in gmail).
It really sucks that there is no actionable info from Google on this error.
Related
I have a website that allows visitors to fill in a form with their name, email address, and a question, and this is sent as an email message to the nominated website member.
The email messages are plain text and contain a 'Reply-To' header with the name and email address provided by the visitor. They are sent from noreply#mydomain which is managed by Google Workspaces.
Here is an edited snippet of the relevant headers:
Date: Wed, 10 Nov 2021 11:25:55 +0000
Subject: Question
From: My Business <noreply#mydomain>
Reply-To: Visitor <visitor#theirdomain>
To: Member <member#theirdomain>
When this is working correctly, the recipient receives the message from noreply#mydomain, and when they click the reply button in their email client, the reply will be addressed to the visitor. Most email clients are compliant and this arrangement has worked reasonably well for many years.
However, over the last few days a number of website members with gmail addresses are replying to the noreply#mydomain address. I have sent myself a test message through the website, and when I click the 'Reply' button on the received message, the reply is addressed to noreply#mydomain. This occurs on Gmail for web, Android and ios.
I have also noticed that gmail is no longer displaying the account name for the noreply#mydomain account. It's there in the headers, but only the address is displayed in list view and message detail view.
I have opened up older messages from 2017 (these are the most recent ones I have) and they still display and create a reply correctly. I have compared headers, and both pass SPF and DKIM. The major difference is the new message contains ARC- headers that weren't implemented in the past.
Does anyone have any ideas how I can fix this problem?
This question already has an answer here:
MailApp.sendEmail method doesn't get through to accounts with URL in the body - Message Blocked
(1 answer)
Closed 2 years ago.
Recently I have decided to upgrade to a GSuite account from the basic free gmail account. I have a collection of Google AppsScripts that manage a collection of forms/spreadsheets and send out notifications on changes.
All scripts were copied into the new GSuite account and all seem to run well. All APIs used (spreadsheet, calendar, drive, forms work with the except of the script.send_mail which refuses to send any emails to external email addresses. If I set it to send emails to myself, it works fine, but to any external email and the message gets blocked with this message
Action: failed
Status: 5.0.0
Diagnostic-Code: smtp; Message rejected. See https://support.google.com/mail/answer/69585 for more information.
Last-Attempt-Date: Mon, 30 Sep 2019 14:02:02 -0700 (PDT)
I have created a very simple script to test it and it still fails. Code attached:
function testSendMsg(){
var subject = "Test Message";
var message = " Testing 1 2 3..";
var emailAddr = "emailaddressX#gmail.com"; // put correct email address here
MailApp.sendEmail(emailAddr,subject,message);
}
Sending this email using the browser mail app works fine, only the script based email sends fail. Any help or pointers on this is appreciated.
Google Cloud Support was not able to find any solutions to this!
After a week of frustration trying to figure out why this was not working, it just started working today with no changes. I suspect a new GSuite account is blocked from using this API at the beginning for some reason that I can not imagine and then released eventually after probation period is over.
I use dnsimple to host my DNS and have valid SPF, DKIM, and DMARC records to validate my emails sent from Zoho. However, Whenever I send emails to an #ucdavis.edu account I get an Undelivered Mail response
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its recipients. This is a permanent error.
lsmiyashita#ucdavis.edu, ERROR_CODE :550, ERROR_CODE :5.7.1 <admin#study.space>... Access denied
Received:from mail.zoho.com by mx.zohomail.com
with SMTP id 1478675695600485.6815385213283; Tue, 8 Nov 2016 23:14:55 -0800 (PST)
Message-ID:<15847f087ed.112901d8e106580.9166398699723335101#study.space>
Date:Tue, 08 Nov 2016 23:14:55 -0800
From:Jacob Bevilacqua <admin#study.space>
User-Agent:Zoho Mail
To:"lsmiyashita" <lsmiyashita#ucdavis.edu>
Subject:Here's a little test for you.
Content-Type:multipart/alternative;
boundary="----=_Part_335760_1020694757.1478675695597"
I have tried several different hosts (GSuite, MailGun, & Zoho) and I get the same issue. I checked and I am not blacklisted on any sites. I ran a test at mail-tester.com and got a 10/10. Why won't my messages deliver.
I verified that the email address you are sending to is valid: Verified Email Address
So like #Synchro says, they just don't like you. It's always a challenge to figure out the exact reason, but contacting their admins is the right way to go. I have a feeling it's because of the .space domain ending, they probably haven't updated the list of domain endings they accept.
Anyway, if you wanted to do additional mail testing, use this Mail Tester.
You are under the unfortunate illusion that it's your fault. A 5.7.1 error means that they just don't like you, and they don't have to give a reason. Welcome to the world of deliverability, or lack thereof. Well-behaved mailers are often punished for no particular reason. If it's just this domain, your best bet might be to contact their admins.
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've searched all around, made several changes over the past two weeks, and still no luck so here I am.
We just put up a new site, and there are 3 different forms. Each form sends to a different email of theirs, a forwarder that sends to the same email of theirs (I had to make this after I figured out there was a problem with them not receiving emails from the website), and one of our emails.
Currently, they use office 365 for their email. A few days ago I figured out to change the SPF record, so I added the IP of their current website.
Here is the current SPF record:
v=spf1 include:spf.protection.outlook.com ip4:23.229.157.193 a ~all
I'm stumped. I've sent test submissions, and they receive the forward, and I receive it from my email, but the email that it's supposed to be sent to doesn't receive it.
I don't have access to their office 365 account. I tried a different option of sending the emails through swiftmailer, but GoDaddy doesn't allow me to connect to their smtp details, so that's a bust.
Has anyone encountered this problem before and know of a solution? All help is greatly appreciated.
THE SOLUTION:
After hours of calling, I was able to get the problem solved. I should have edited this earlier, but better late than never. In cPanel, there is an area for routing mail. It was set to local, rather than remote. Every email that came through went to the local emails, and since their were none, they were discarded. After changing the option to remote, the emails started flowing through. After the 3rd or 4th call, I reached someone who's actually dealt with this problem because he explained what was happening and the fix in under two minutes, unlike the others. I hope this helps anyone in the future with the same problems I encountered.
If you've configured SPF on your sending smtp server, you can configure a _dmarc
DNS record with an email address for the receiving server to send mail reports to...
Better yet, if this 'new' server is not required to be fully operational while you set up everything - you can set the _dmarc record to tell the receiving server to reject anything that doesn't pass the SPF test.
In any case, if you are setting up an email server that will send messages to any outside Internet address, and you have the ability to install software on the server - you should install and configure:
SPF, DKIM, and have a dmarc DNS record.
If you don't have these items, it's very likely much of your site's notification email will end up in the subscribers' spam box, or worse rejected by the receiving server.
Several good websites that have helped me:
unlocktheinbox.com
dmarcian.com
emailsecuritygrader
protodave.com dkim key checker
appmaildev.com domainkeys test
gettingemaildelivered.com