I'm trying to use mailgun for it's SMTP service. The place I am trying to use it sends an email to the address entered as the "username":
postmaster#portal.example.com
I set up mailgun for receiving email within my DNS settings:
I've checked mailgun.org and made sure it sees the changes:
I have no idea where to see these actual emails, I've checked around the mailgun dashboard but I'm not finding it, I've checked logs and saw that the message was "accepted" but no delivered log.
I tried creating postmaster#portal.example.com on the host and then tried sending the validation code again but I didn't receive anything.
Help would be appreciated, thank you.
For Mailgun to handle the incoming emails for you, you need to add Routes.
Check the documentation on Routes to get started. It´s really quite straight forward.
Related
I have an issue where I have a custom domain set up with gmail, I have all DNS pointing to the correct location as defined in the google documentation (4 hours is the smallest TTL my DNS allows me to assign):
I have already set up gmail in google admin, and that all seems correct to me.
The weird thing is that if I send email from the account admin#mycustomdomain.com I can send it and the recipient will receive it.
However if they try to respond, they get an error from Mail Delivery Subsystem saying that it is not delivered, and it never appears in the admin#mycustomdomain.com email address.
Does anyone know what I'm missing? I've made sure that there are no extra MX records that could be messing this up in my DNS as well. I have been googling around about it but I am not finding anything I haven't tried already and am not sure how to debug this.
I created an application which uses SendGrid's Inbound Parse Webhook. Whenever someone emails "whatever#mydomain.com", the email goes to SendGrid, and then SendGrid hits our server with a POST containing the email's contents. We can then feed that email data back into our main application.
I have it all working. But now I do not know how I am supposed to authenticate the messages SendGrid posts to our server. Does anyone know the best course of action for doing this? Verifying that our inbound emails actually come from authorized users of our main application?
Obviously we can check the "From" address in the headers, but I've read that these can be completely spoofed. Apparently "dkim" and "spf", two attributes of the incoming mail from SendGrid, have something to do with authorization. But i cannot find anything in the documentation, or really anywhere else for that matter, that tells me how I should be consuming these "dkim" and "spf" fields to verify message authenticity.
If anyone has any help, general, specific, or otherwise.. It would be greatly appreciated. Thanks in advance.
Well. Since this doesn't seem to be getting a lot of traction I thought I'd post my own janky-ass solution to the problem, on the off chance that anyone else runs across this issue in the future.
Disclaimer: this could be total garbage nonsense. But it appears to be working all right.
Basically I ended up taking some critical contextual information about the original message that initiated the inbound email. We encode that information in the local-part of the "Reply To" address that we set up with the SendGridMessage. Then I encrypt the encoded local-part.
When SendGrid POSTs to our server with the inbound email, we decrypt the "TO" local-part and validate the result. If it decrypts successfully, we check the "FROM", and verify that they are an actual authorized user of our main application. THEN, we verify that THAT user in question has the correct permissions to edit the information associated with the original encoded local-part of the "Reply To".
I'm setting mailgun route to xx#me.com to forward an email to a server at http://xxx:7000/reply.
I tested already the email route and it's fine as well as the server is up both in browser and using curl. However sending an email to xx#me.com still nothing happens.
There is already a similar question but nobody answered:
Can't recieve incoming mail with Mailgun
There are a few requirements for handling incoming emails with Mailgun.
Your account must be verified (email/SMS message)
The domain or subdomain must be added to the account.
SPF & DKIM must be verified and have MX records configured with Mailgun's values. Details for DNS record information
Route filters configured with the recipient domain or subdomain matching. (Example: Domain "bar.com" is added to the account. The expression can match_recipient("foo#bar.com"). If a subdomain is added, then it will need to match the subdomain, e.g. match_recipient("foo#mg.bar.com"))
The error from the linked question would be due to one of the above requirements wasn't fulfilled. A rejection of "550 5.7.1 Relaying denied" from Mailgun's incoming mail servers indicates a domain or subdomain has MX records pointed toward Mailgun's but the domain does not exist within an account.
**Disclaimer I work at Mailgun
I know this is 6 months old, but since I spent 4 hours trying to figure this out, I will share my solution:
There is another cause of the 5.7.1 Relaying denied message: My mailgun account wasn't verified. I saw someone suggest this but I figured they just meant that I had to verify the address I was forwarding to. Nope, when I logged in today I saw a banner at the top saying click here to resend your verification email. I did that, it went through a text message verification process, and all immediately started working!
I know this is quite a stale thread, but I also wanted to chime in here in hopes of saving folks a few hours of their life trying to solve the "550 5.7.1 Relaying denied" caper.
For me? It was what has plagued me on several occasions. I was able to verify via Gmail > 'Settings' > 'Accounts and Import' > 'Add another email address' only after I disconnected from my software-based VPN (Private Internet Access).
[Your sigh or wince here]
Now, go get it... make it happen. ;-)
If you're using MailGun with cPanel (for example, after following this tutorial) and you're getting the 550 5.7.1 Relaying denied error, make sure you're using the MailGun SMTP credentials given after adding your domain (as opposed to your MailGun username and password as the documentation suggests). That was the origin of my own problem.
Another reason for this error code may well be that you are trying to send stuff over SMTP whereas you've indicated on the sending properties of mailgun settings for your domain that you want to use the API...
I'm trying to get the basic "hello world" of sendgrid working, but have so far been unsuccessful. The response returns code 202, suggesting that it will send the email, but the email never sends out. Does anyone know what's going on?
import sendgrid
sg = sendgrid.SendGridAPIClient(apikey='**my-api-key**')
data = {
"personalizations": [
{
"to": [
{
"email": "me#gmail.com"
}
],
"subject": "Hello World from the SendGrid Python Library!"
}
],
"from": {
"email": "me#gmail.com"
},
"content": [
{
"type": "text/plain",
"value": "Hello, Email!"
}
]
}
response = sg.client.mail.send.post(request_body=data)
print(response.status_code)
I just had this issue: I created an account with SendGrid and tried to get the basic example working, the API would return a 202 response, but the email was never sent, and the SendGrid web UI's activity feed showed no activity.
I submitted a SendGrid support ticket and ~8 hours later received a response saying that they had disabled my account's ability to send emails:
Hello,
Thanks for contacting SendGrid Support!
It looks like your account has been closed by our compliance team and this is the cause of the issue.
To reactivate we’d like to know a little more about the email you’ll be sending through SendGrid. Please elaborate on the following:
The nature of your business, the services you provide, and your potential customer base
Your sending frequency and volume
How you collect your recipient addresses (link to opt in page, or sign up process)
How you will allow your recipients to opt out of your emails (whether you plan to use SendGrid’s one-click unsubscribe feature, or if you have your own method)
The types of messages you will be sending (transactional or marketing)
Please reply at your earliest convenience in order to continue the activation process. Thanks for your cooperation!
~15 hours after submitting my answers, I received a response saying my account had been "activated":
Hi nathan.wailes,
Thanks for the additional information! Your SendGrid account has been
activated, and can now be used to send email. To get started, check
out our Getting Started page.
If you hit any snags while you're getting set up, you can find
solutions to common problems and FAQS in our Knowledge Base.
Let me know if you have any more questions!
Best,
Stevin O.
Associate Support Engineer
When I then ran the basic example code with my email address set up as the recipient, the email showed up immediately in my Gmail inbox.
Debug this by going to the sendgrid api log here:
https://app.sendgrid.com/email_activity
In my case, it was a DMARC receiving domain block.
The 202 Accepted Status Code returned from SendGrid does not really indicate that the message has been successfully delivered to the recipients inbox. It indicates that the message is valid and has been "Queued For Delivery". Now, it is up to the receiving server to deliver this message to the recipients inbox, or to send it to spam, or simply drop the message.
There are several reasons as to why messages that returns 202 Accepted Status code from SendGrid does not actually get delivered to the recipients inbox.
For example:
Invalid email address: The email address may no longer be valid (example, when an employee stops working at some company, their email might be removed from the company's system removing the ability to receive any email).
Blocked Emails: If the sending IP or domain is blocked or if the recipients inbox provider has some filters set up such that some specific content of your email/campaign is considered spammy and thus gets automatically blocked.
Another thing to note is that SendGrid may send the messages to spam/junk if the domain authentication has not been properly set up. So make sure that your domain is properly authenticated.
Here is the link to the documentation from SendGrid that explains these event in details. https://sendgrid.com/blog/delivered-bounced-blocked-and-deferred-emails-what-does-it-all-mean/
I had same issue and solved it by adding new api key with full access
In case someone will come across this looking for an answer to a similar problem. I solved the same problem by confirming the domain with DNS records - after that everything worked like charm.
In Sendgrind: Setting > Senders Authentication > Domain Authentication
For us, the problem was that the used dynamic template was not yet set to "active". Unfortunately no error was shown about the in the API response or the log.
Activating the email template solved this and emails are no longer dropped.
The same issue occurred when DNS is not verified and you are not using register email in from email.
Just change from email to register email.
I recently got the same issue. My e-mails were not sent without any reason, the response status was 202, e-mail activity was empty. The possible solution is to add a company details and add an unsubscribe block to e-mail. That worked for me.
I'm implementing a password reset feature and it's a little weird to have an unsubscribe block for this. I'll try to figure out what was the real reason of such silent suppression. Probably it's because I tried to send a draft debug e-mail several times which was looked like a spam. Maybe SendGrid has some smart algorithms for detecting this.
I also had this issue. I contacted sendgrid support however while waiting I changed the dummy data to real data I was calling sendgrid API with and then it started working.
in particular I changed the from email address to show my own domain.
For me the template was the issue. When using the template engine make sure to use {{variable}} instead of {{ variable }}. Afterwards I received the emails as usual.
I am having a problem where i get a bounce whenever i send a mail to my email address xxx#mydomain.com, from xxx#anyotherdomain.com. I tested this with about 10 of my email accounts and none of them work.
However I am able to receive mails from accounts like xxx#hotmail.com or xxx#gmail.com.
I get this bounce :
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. The following address(es)
failed:
However no error codes. If anyone can help me or point me at the right direction that would be appreciated.
You should see a more detailed error message below what you quoted. But I would check to see if you have an SPF record for either of the two domains and make sure it is set correctly.