We run a large newsletter and we use Google Postmaster to track feedback loops. We followed all instructions and correctly configured our domain in Google Postmaster. We also add a custom header to all emails sent:
Feedback-ID: $template:$domain:$email_to:$server
However, in Google Postmaster our FBL spam rate is always zero which is impossible because we send to over 100k subscribers so we usually get between 0% to 0.5% spam reports
But if I look at the "Spam Rate" graph (non-FBL) then I see non-zero values
Related
I'm sending automated emails from my account to my account, I'm using Integromat (now Make) and I've done all the necessary stuff in the Google Cloud Platform (or Console) to authorize Integromat. The scenario works and I send automated emails.
However when I go to check the usage status to see how many emails I have sent and how many I have left in the Google console, it shows no results.
For reference, I go here https://console.cloud.google.com/apis/api/gmail.googleapis.com/ to check the status, but all the graphs show no data whatsoever, despite the automated mails getting sent normally. I have the correct project selected when doing this.
There is no way to see stats on any of your google usage quotas. The Stats page on Google cloud console. Is at best an estimate and not real time in any sense of the word.
Either create your own counter, or just wait until you get the quota error. I normally go with the latter.
I’m trying to understand Microsoft Graph API’s rate limiting/throttling with OneDrive/SharePoint and excel endpoints. I know that they don’t publish these limits (see here), but am hoping that if I provide some information about my use-case, someone might be able to provide ballpark figures.
Here is some information about the use case:
There is a spreadsheet that is kept in OneDrive or SharePoint
This spreadsheet runs calculations
Users send in inputs and get back outputs from this spreadsheet
There are 200 users
Each user makes about 10 read requests (sending in inputs) and 10
write requests(getting back outputs) per day i.e. 2,000 read requests and 2,000 write requests per day
Given the information above, is there any way to know if users will encounter the 429 ("Too many requests") or 503 ("Server Too Busy") error?
And if so,:
How often?
Is there a strategy for dealing with this?
I'm ultimately trying to decide if this is an appropriate tool for an enterprise-grade app or if I should go with SpreadsheetWeb.
Using SendGrid through Azure (free version).
I recently disabled a user's email because it was receiving way too much SPAM. Prior to doing this my activities list was about 1-2 pages long with recognizable e-mails my system was sending out per customer input in a website (there is a workflow for forms which the user inputs, then my system sends out an e-mail confirming input).
Now that I have disabled that e-mail, I am seeing upwards of 59 pages of activity just for one day (since I disabled the e-mail address), most of which is listed as "Deferred" or "Processed". The lists include SPAM e-mail addresses (something-reverse-mortgage#whatever.net, etc.).
Reading the SendGrid documentation, it seems that "Deferred" activities just mean that the receiving ISP is asking SendGrid to slow down. I take this to mean that my server is sending these e-mails.
This is worrisome obviously. Disabling that e-mail has this unintended consequence of seeing hundreds of "Defered" activity listings in SendGrid.
I am confused, however, if this is just the system getting these e-mails and then trying to bounce them back through my server. Since it's SPAM and likely not a real e-mail address, is SendGrid just trying to return the e-mails? Hence the activity?
If so, is this something that will eventually die down, or should I do something to prevent SendGrid from returning these obviously bogus SPAM e-mails to what it thinks is the originating sender?
Thanks in advance.
I send about 100K emails a month with sendgrid and I don't worry at all about deferred. About 1/3 of my outgoing emails are gmail and gmail is very agressive at blocking emails when you send more than 50 or so at once. They simply reject and sendgrid tries again later. They all seem to go thru within about 24 hours.
I wrote a small Google Apps Script to send out personalized e-mails (conference invitations) individually to recipients (i.e. one recipient per e-mail). As a workaround to the issue of e-mails sent using GmailApp.sendEmail not showing up in the Sent Mail folder, I have one script send the e-mails to itself (i.e. the sender and recipient are the same), then another script to forward those to the appropriate recipients. There are only about 100 (maybe less) verified recipients, but I'm concerned that sending out the e-mails as fast as the script executes might get them flagged as spam due to the rate at which they are being sent. My questions are the following:
If a Google Apps Script accesses a Gmail account to send and forward e-mails using GmailApp, does it incur a sending rate limit (e.g. in e-mails/second, kB/second, etc.)?
Which quota applies to said script? Is it Gmail's 500/day or Google Apps' 100/day?
P.S. I found this discussion about quotas, but I'm not sure if my case falls under either of the scenarios described therein.
There are no such limits. There is a limit on the body size per email - 20KB
It's 500 emails/day for Gmail users and free Google Apps users. Please note though that CCing and BCCing are all counted against your quota. So if you send one email and CC it to 500 hundred people you would have used up all your quota for that day. Also, there are additional quotas when sending emails within a domain.
Also, the method MailApp.getRemainingDailyQuota() will tell you how many more emails you can send that day.
All the quotas are described here:
https://developers.google.com/apps-script/guides/services/quotas
How are e-mails sent using GmailApp.sendEmail not showing up in the Sent Mail folder?
I have a site on a dedicated server with it's own IP range that has been running for a good few years. We have a notification email address (mailout#domain.com) which we use to send automated emails (activation emails when a user signs up and notification emails if something relevant to them happens, eg someone befriends them or comments on their picture etc). Users can select whether to receive these notifications or not. We have SPF and RDNS setup.
Email from all our other email accounts go to hotmail/gmail/yahoo mail etc correctly into the inbox. However any mail sent from the mailout#domain.com account (whether automatically by the server or manually via outlook) is delivered correctly to the inboxes for yahoo and gmail however goes into Junk in Hotmail (but other #domain.com addresses deliver to hotmail's inbox correctly). It says at the top of the message that MS Smartscreen marked this message as junk. I signed up for MS Smart Network Data Services to monitor the IP and it says it's not blocked but it displays Bot-like behaviour (which kind of makes sense as our notifications are kind of bot like even though they're not spam).
I can't work out what to do to prevent this from happening, we've authenticated the email, there's obviously not a general block on the IP as emails from different accounts on the same domain are going through successfully. It doesn't seem to be the format of the email either because if I send identical emails from mailout#domain.com and contact#domain then the one from contact# gets through to the inbox but the one from mailout# goes through to junk.
I can't really work out what to do and obviously trying to get MS to sort it out is never going to happen and i've used all their available tools. I can obviously try setting up a new email address (eg noreply#domain.com) and using that for notifications but i assume it will only be a matter of time before that gets blocked as well.
I would be immensely grateful for any suggestions anyone has!
Thanks so much,
Dave
You don't have many options. Try to do as many of the following as you can:
Reach out to MS support (don't discard this notion)
Implement DKIM and possibly DMARC (which are vastly more informative than SPF)
Change your IP address to something cleaner
Find and follow bulk sender best practices, e.g. M³AAWG's BCPs, perhaps the Help – I'm on a Blocklist doc