I have a webpage that reads webhooks received from mail events and routes
In mailgun I created a subdomain that we actually only use for testing, I can not add MX records to the domain we use.
so for example for my domain "mycompany.com" I have added "testing.mycompany.com"
Now I want to send a mail to "testaccount#testing.mycompany.com" that get forwarded with mailgun routes to my webpage but.
Without being able to add MX records to our main domain, is it possible to configure a solution in mailgun so I can send an email to an unexisting mail "testaccount#testing.mycompany.com" in a newly created subdomain ?
Related
I have a SES verified domain example.com with a verified FROM my.example.com and we send emails with service#my.example.com.
If someone replies to service#my.example.com, they will get a 550 mailbox not found error. Is it possible to override this default error by some custom template? We want to inform our customers they should use another email address to reply to.
My Django (hosted through a cPanel Python App) is not sending out emails to addresses belonging to the same domain as the site.
The same send_email() function works fine in sending out messages to any other domain.
I use Google Workspace for managing emails, and all MX records are set up via cPanel as normal – and emails otherwise work fine via Gmail.
Any ideas?
I am trying to send email from my Django application. For this, I have used Twilio SendGrid service. Though my application can send the email, it ends up in spam folder. So, I have followed this tutorial to authenticate my domain which I bought from AWS route 53. In sendgrid, the domain authentication status shows 'verified' but the emails are still sent to spam folder. I have not created any MX or TXT record in DNS setting as the tutorial says it was created automatically during domain authentication in sendgrid.
One thing I have noticed that the email still shows, 'via.sendgrid.net' message (attached an image below) with the email. Whereas it should be my authenticated domain name. I have created sendgrid account with an outlook email and using that address to send email from Django app. Is this the reason my emails are going to spam? Or can anyone please help me to find a solution for this problem? Thanks in advance.
FYI: I have done 'Single Sender Verification' in sendgrid during developing this app. But now I have deployed it in aws. I guess this feature is still working instead of 'Domain Authentication'.
We have a site on Google Cloud, let's call it 'main.co.uk'
and a subdomain site called 'forum'.
We are using Gmail business for main.co.uk emails, verified by MX records, SPF etc
Now what's confusing me is using mailgun for sending mail for 'forum'.
I know we can have multiple MX Records for main.co.uk but is there a good way to do this? do we set different priorities? Will we get issues with mailgun and Google trying to handle incoming mail?
Any advice would be great.
Using mailgun for sending emails does not involve MX records. Services like mailgun will use credentials for one of your email servers and will act like an email client program. Mailgun will authenticate and then upload email to the email server. There is also the option for programs like mailgun to act as an SMTP server for your domain (you can have more than one sending server).
Mailgun can also be configured as an email server for receiving email. However, you do not replace your existing email server, instead you create a subdomain that is then managed by mailgun. In this use case all incoming emails for that subdomain someone#mailgun.example.com are then processed by mailgun. This is similar to having multiple email accounts that you need to login into to read your email. The intent here is for mailgun to apply intelligence to the sending and processing of your email campaigns by managing email bounces, click throughs, etc.
MX records specify the mail server responsible for accepting email. You can have multiple MX records with different priorities but they are pointing to the same email system (collection of servers storing your inbox), not to different servers at different providers. For example, you would not have one MX record point to Gmail and another MX record pointing to Office 365 (or mailgun and Google). Multiple MX records support fault tolerance and failover, not multiple providers.
You can have an email server setup for main.co.uk and another email server setup for forum.main.co.uk but these are separate email server setups (I am ignoring email aliasing). You can have mailgun send email for someone#forum.main.co.uk with a return address anotherperson#main.co.uk. Normally you want to keep the sender address and return address the same so that SPAM filters don't kick in.
In summary, use mailgun to send emails from your website and / or email marketing campaigns and a normal email system (Office 365, Gmail, etc.) for everything else but have them setup as separate independent email systems.
Suddenly all the emails sent through gmail api are landing with a red banner in recipients inbox as shown below.
So, I created a new OAuth ClientID in Google Cloud platform and used those credentials to provide access to my test gmail account. Then I sent emails using Gmail Api and emails are landing in inbox without any red banner which is good.
But we need to use the same old OAuth ClientID as we have so many users who provided access to it. If we change these ClientID and ClientSecret to use the new one, we need all our users to re-authorize, which we don't want to do. Can someone help why the existing OAuth Client ID is throwing this red banner in recipients mailbox?
As stated in this blog, this warning message speaks about one of the security measures taken by Google. Also from this related SO post, either your message contains a scam web page that steal users informations or the Domain/IP of your server has been used in the past for stealing personal informations. Check if IP is blacklisted on Mxtoolbox Configure Reverse DNS (Match your domain name with your IP), SPF and DKIM, Send legitimate email and everything will be fine.