Retrigger email routing after adding a default route - gmail

In Google Admin's Gmail section, under "Dafault routing" we have a rule in the "Also deliver to" section to "Add more recipients". This delivers emails to a second email account.
I mistakenly made the following sequence of changes to a gmail inbox this morning:
Remove the existing rule
Wait some time (in which we received some emails)
Panic and re-add the rule
There are now some emails which haven't been delivered to the second account. Is there any way to trigger the action to redeliver these messages?

There's no way to trigger redelivery of email. If they bounced, the sender should retry over the next few hours.

Related

How to auto-receive all Gmail messages in a Google Group

I am using a Google Workspace account and wanted to create a backup of all the emails received in my Gmail Inbox so that even after cleaning the inbox (deleting the emails from Gmail), the backup of emails would be there in Google Groups.
To do this, I am thinking of creating a google group with only one member (me).
After deleting the emails from my Email ID, the emails will still be present in the Google group.
But to achieve this, if I add a Gmail forwarding rule, then I might receive all the messages from my name instead of the original sender's name.
Is there a way through which I can auto-receive the original messages on Google Group which I received on my Email ID?
You won't be receiving the email from your email address when adding a forwarding rule.
Therefore, if you plan on forwarding all the incoming mail to your group, you should proceed by adding a forwarding rule and adding the email address of the group.
Afterwards, you will end up receiving the email in the group looking something similar to this:
Reference
Automatically forward Gmail messages to another account.

Azure action group not sending emails for outlook contact group

I want to configure an alert in Azure portal. When it fires, I want to send a notification to a contact group, for example: mygroup#xxx.com.
I choose action type: Email/SMS/Push/Voice
Interesting thing: when I set up action group not for a contact group, but for my personal email - I see the alert in my mailbox.
Is there any way to configure action group for a contact group consisting of emails?
Is there a whitelist/blacklist configuration somewhere?
Verify that emails from these three addresses are not blocked:
azure-noreply#microsoft.com
azureemail-noreply#microsoft.com
alerts-noreply#mail.windowsazure.com
It is common that internal
mailing lists or distribution lists block emails from external email
addresses. You need to whitelist the above email addresses. To test,
add a regular work email address (not a mailing list) to the action
group and see if alerts arrive to that email.
https://learn.microsoft.com/en-us/azure/azure-monitor/platform/alerts-troubleshoot
Note also that sometimes MS/Azure IPs get blacklisted as well, and the Azure Portal will still say the notification was "fired" with no indication it failed. Sad, but true.
Check this link for more detail: Azure Action Group email notifications - fail, not reliable

Sendgrid Inbound Parse Webhook Emails are not received on Sendgrid

I am using the SendGrid for receiving the emails from my domain (example.com). I have configured all the steps from the mentioned link Sendgrid Inbound Parse Webhook.
I have added all the name records(MX records and CNAMES) in the GoDaddy DNS records against my domain.
The issue is when I send an email to hello#example.com. When an email is sent to this email-id there is no mail delivery failure report. There is no any statistics for the SendGird console about the webhook got triggered.
I am not able to figure out what went wrong in this process. As emails in the sendgrid webhook are not received.
I think they are lost in between.
I found the documentation to be insufficient in this area. You need to send to the subdomain, listed in your MX record, which redirects mail to sendgrid.
For example, if you add a MX record for email.example.com, you need to send the email to user#email.example.com.
One of the best ways to test if a 3rd party Web API post is being triggered or not is by using a tool that receives posts and provides visibility to the data sent along with the post (e.g. Headers, parameters, and the related data in json, text, etc).
One of the tools that I have used to test if a post is being triggered or not is offered by: https://requestbin.fullcontact.com/. Take these steps to set-up your testing environment:
(note: I am not associated with the requestbin.fullcontact.com resource - I am just an enthusiastic fan of this very useful service).
Go to requestbin and "Create a RequestBin". This will create your own unique requestbin URL. (e.g. https://requestbin.fullcontact.com/xxxxx)
Copy this URL, and paste it into your SendGrid Inbound Parse "Destination URL".
Keep your testing environment simple initially by NOT checking the "Additional Options" (Check incoming emails for spam & Post the raw...).
Be sure you do not enter a 'Subdomain' in the SendGrid Inbound Parse "Receiving Domain" unless you are expecting users to use the subdomain as part of your email address.
Re: #3, same applies to your DNS at GoDaddy. Your email should also not reflect a 'subdomain' as part of your MX record (e.g. you should not use mail.example.com).
Click "Add".
Now, send an email to your domain (e.g. info#example.com).
Check your requestbin to see if a post was made by using your unique requestbin URL, appended with "?inspect" (e.g. https://requestbin.fullcontact.com/xxxxx?inspect).
Result: You should see post information when viewing your 'inspect' URL.
Using this first step of a diagnostic process to test your usage of SendGrid's Inbound Parse should help expose potential problems in your configuration (e.g. DNS set up would be the next area to look at if no post data is being received in the requestbin inspect URL). Good luck.

Email selection screen, set default recipient email

I have an easy one, never had to do it before
I'm on the invoice, I click on the + and I click on email.
The recipient email is the customer, fine.
But I have a case where I need to hardcode the email.
I created a workflow and assign the email to the hardcoded address.
It's not working and I'm not surprised.
I want to update the email recipient field in the "popup" screen
I'm sure it's easy for all of you but it would help me
Mark
The logic needs to be deployed to the message record instead of the invoice record. I am not sure if the message record is exposed to workflows, but it is exposed to user event scripts. A user event script deployed on the message record will execute on every message, so the script logic needs to check the passed parameters to determine if the email was opened from an invoice. The easiest way to change the recipient email address is to use a redirect with the desired parameters.

Does MailApp.sendEmail() method impersonate sender address?

I'm sending mail to a third party-service from Gmail using Google Apps Script. This third party requires the sender email address be registered with them. If the sender is not registered, an error/marketing message is sent back to the original sender.
When the message is sent from Gmail manually, it is processed as expected by the third party. When the message is sent by a script, the message is not processed by the third party and no error response is sent as described above. After adding a different gmail address as a BCC on one such message, I found the script generated message shows "mailed-by: bounce.secureserver.net" and "signed-by: gmail.com"
I'm worried GAS is impersonating the sender in such a way that the third party does not recognize the sender as a registered address. Or, the third party may be dropping the messages as spam. (http://productforums.google.com/d/topic/apps-script/tGxlioK1ejg/discussion)
Community feedback on this problem is most appreciated.
According to Google's documentation, the sendEmail() method sends an email as the user running the script. That being said, additional parameters are automatically added to the email's header, and these might trigger some filtering rules on the recipient side. There is not much you can do about that, beside using a third-party email service like SendGrid which might do a better job at ensuring that your email will go through.

Resources