This one has me stumped... I currently have one MailGun route setup... its a catch_all() that forwards all mail on my domain to my GMail account. For some reason, if I email somebody who has an autoreply (i.e. an out-of-office responder), I do not receive the autoreply message. I checked the MailGun control panel logs, and the autoreply never even shows up... its as if messages sent via MailGun don't trigger other mail services to send an autoreply? I've confirmed that my sent messages are received in the Inbox of the person with the autoreply active. I've also confirmed the behavior when sending to outlook and GMail users.
Help please! Thanks.
Here's a response I got from mailgun support:
We by default drop all system messages, NDRs, OOOs and auto-replies (they'll all have a null <> Sender header which don't allow).
Related
All I have is an email client (emClient) and a working sendgrid account. When prompted to enter an email address, I can happily put anything#mydomain.com and it will confirm that it works with SMTP. I can also send emails using this client. I authenticate with the username apikey and my api key.
However, these emails are permanently stuck in the "outbox" and are constantly sent over and over again, presumably because the client has no confirmation that they were sent. When trying to set up a new account under this domain, I setup my "incoming server" as smtp.sendgrid.net and provide my credentials and it sort-of works (after prompting me for my authentication?).
As you can see, SMTP authenticates just fine and this makes sense as I am seemingly able to send email. However, both IMAP and POP3 when I select them in the "incoming server" are stuck on this "testing" stage until they fail.
Now, if we skip ahead to me sending something out - basically, it works. I receive the email on the destination, it does not get marked as spam and it comes from my domain and my name.
However, when I attempt to receive an email on the anything#mydomain.com one, it just doesn't do anything. I don't get an error from gmail that it wasn't delivered, it simply just doesn't get delivered.
For my domain settings, I have the following configured:
Twilio SendGrid developer evangelist here.
While SendGrid allows you to send emails over SMTP or via the API, SendGrid is not a full mailbox that you can connect to over POP3 or IMAP. You cannot connect to SendGrid using an email client, that is not what it is intended for. SendGrid is not a mailbox, but a way to programmatically send and receive emails and other email based events.
The way to receive incoming emails is via the inbound parse webhook. When you have set that up, incoming emails to your configured domain will cause a webhook, an HTTP request, to be sent to a URL you configured, with all the information about the email.
I am trying to send an email from my Firebase Cloud Functions using the SendGrid's mail client for Node.js
I am following their example described as follows:
const sgMail = require('#sendgrid/mail');
sgMail.setApiKey(functions.config().sendgrid.key);
const msg = {
to: 'my_own_mail#gmail.com',
from: 'my_other_own_mail#gmail.com',
subject: 'Sending with Twilio SendGrid is Fun',
text: 'and easy to do anywhere, even with Node.js',
html: '<strong>and easy to do anywhere, even with Node.js</strong>',
};
sgMail.send(msg);
Once the function is fired, everything gets executed successfully. In my function logs I get Status 202 and the actual mail gets delivered but not in the main mailbox but rather in the Spam folder. When I open the message, it simply says:
I don't really understand what is the problem.
NOTE: If I send the message to an Yahoo email it doesn't go in the Spam folder. Same applies if I send it to my business email.
Your problem is not related to cloud functions or the code, there are a few anti-spam rules you need to follow, this gave me a good starting point
Sendgrid does not send your messages to the SPAM folder it all depends on the recipients mail delivery flow spam filters.
Most messages are marked as spam for one of the following reasons
1. Message is not authenticated properly
Validated that your message is authenticated properly with SPF or DKIM
2.Your message originates from an IP that is in a Blacklist (this might be on Sendgrid's)
Try by sending a message to your self and open the message headers , then look for entries like the one below
Received: from xxxxxxxxx.com (xxxxxxx.com [xxx.xx.xxx.xx])
by xxxx.com with SMTPS id ##############
The IP between [] is the sending server IP try to use public blacklist such as spamhaus to see if it is blacklisted and report to Sendrig if you find a match
3.The content of your message has known phishing techniques (accidentally or not)
Check the "Format your mail" section for Gmail senders guidelines as general recommendation
I tried to send an email through sendgrid. I have a custom domain myself#contoso.com. If i try to send an email to user1#gmail.com with the from address as myself#contoso.com,then,the email is delivered to gmail with "via". When i try sending email to myself#contoso.com with the from address being myself#contoso.com the activity says the email is delivered however, in outlook client i have not received the email. What is it that I can try or do?
I have tried whitelisting contoso.com but it did not work
This is not an answer, as it doesn't help work out why the emails that are "Delivered" have not been received, but this is SendGrid's note on why Email messages with the “Delivered” status are not received:
Twilio SendGrid posts the Delivered event after the destination server accepts the message with a 250 OK response. Once an email is accepted by the destination server, we are unable to see what happens to the message. The receiving server could send it to the inbox, queue it for later delivery, put it into the spam folder, etc.
Often times, a recipient domain will initially accept a message for delivery, and then apply additional filtering afterwards. In this situation, we would have posted the Delivered event, but not have any insight into the additional filtering. Any additional Twilio SendGrid events for your email message would be triggered by recipient engagement (i.e. open/click events, unsubscribes, etc.).
Also note that at the time of writing, that answer had 26 downvotes (and zero upvotes) on the SendGrid website, probably indicating that many other users have experienced this problem.
I had several issue solving this problem. The most important part is to set "Sender Authentication" from sendgrid to your domain dns. There is a instruction here. I'm using godaddy, so the link to set dns is https://dcc.godaddy.com/manage//dns .
A bot has found a way to send bulk spam through my server. My server is not an open relay. All mails are coming from localhost. The emails are being sent from a series of FIRSTNAME_LASTNAME#mydomain.com. At mydomain, there is only 1 email account that was created that we send from.
Is there a way to restrict outgoing email that are being sent through exim to only allow emails to be sent from the 1 email account we created and block all other Sent From addressed that are being created?
You have to add the next condition to your SMTP router(s):
condition = ${if match{$sender_address}{legal#mydomain.com}{yes}{no}}
I was able to resolve this by turning on X-Headers which allowed me to locate where the emails were being executed from which in turn allowed me to eliminate an exploit from an old script.
I have a web app that only registered users can use, therefore I should have a valid e-mail address for the creator of the message.
One part of this web app will allow a user to create and send a e-mail message to an e-mail address that the user enters. My web server will be creating and sending the e-mail, however if there is a delivery problem with the e-mail I would like the bounce to go to the user's e-mail address instead of the server. This will allow the user to know that there was a problem delivering the message and they can take the appropriate action.
Would setting the "return-path" attribute to the user's e-mail address handle this?
As RFC2821 says:
The primary purpose of the Return-path is to designate the address to which messages indicating non-delivery or other mail system failures are to be sent. For this to be unambiguous, exactly one return path SHOULD be present when the message is delivered.
So yes, all standard compliant servers should account for the Return-path you set.
You could set up windows service on your server to periodically check BadMail folder and parse the bounced messages and resend them to the original sender. This solution would work in most cases. I don't think return-path would help in every instance (if it would at all), because different mail servers handle bounces differently.