My registar had a problem and was doing maintenance when ICANN sent an email verification of the domain I had just bought. Consequently, I did not receive the mail and my domain has just been suspended. I would like to know how to get this email. If you have other alternatives for me, thank you for helping me.
Contact the service you used to register the domain. They should be able to get you in touch with the people necessary to reinstate / verify the domain.
Related
I have a verified domain configured in SES. When I send an email with no-reply#my.domain, SES is not sending the email. If I use a valid email address from that domain, SES delivers them.
Does anyone know why this is happening? If my memory doesn't fail me, this used to work just fine as I've had this setup for years. Did something change recently in the AWS SES service?
I have looked for any mention regarding this and all I found is that the domain needs to be verified which it is.
Any help/insight would be greatly appreciated.
According to AWS SES documentation, such emails are hight not recommended
Avoid using a no-reply address, such as no-reply#example.com, as your
"From" or "Reply-to" address. Using a no-reply# email address sends
your recipients a clear message: that you aren't offering them a way
to contact you, and that you're not interested in their feedback.
https://docs.aws.amazon.com/ses/latest/DeveloperGuide/tips-and-best-practices.html
In addition to the domain being verified, the sender email address that you want to use should be verified too. AWS will send you a mail to this address to confirm that it exists. If it doesn't exist, you can create a email receiving rule that will save the email into S3. You can then dig the verification link from there.
My team supports a website for a client, and we use SendGrid to send email related to the site on their behalf.
We do not have anything to do with their own email server and I don't at present know anything about it.
So far as I can work out, SendGrid has proper authentication and is an authorised sender for their domain, and almost 98% of email is delivered successfully.
However, we have had a handful of bounces with the reason "550 relaying denied" and all of these were to addresses at our client's domain (the same one as their website and the from address of the emails.)
Most emails to their domain were delivered successfully.
Unfortunately I don't have access to the full headers of the bounce emails, only the reason.
I understand that in general this error can either be caused by
the sender not being authenticated correctly. I am very far from being an expert in this but so far as I can tell, there is nothing wrong there. Or
a DNS or similar misconfiguration on the part of the recipient's email domain. I have even less understanding about this and I have no access or responsibility for the client's email server.
My main question is, is there any way the domain being the same as the from address could be related? Being as the email is claiming to be from the same place it's sent to, is it possible for that to affect how it's handled by relays?
If not, I'd also appreciate any pointers on where to look for the issue (or what to advise the client to look at if the problem is likely to be from their end.) I have been trying to research issues with email configuration and authentication but I am very much a novice in this area.
Thanks in advance.
The domain being the same could very well be related, but normally when that happens, the receiving server refuses all mail purporting to be from itself.
Separate from DKIM & SPF, most mail servers believe they alone are responsible for the mail from their domain.com. As such, a lot of them have anti-phishing filters that reject "outside" mail that claims to be from themselves. It's like "You can't be Carrie, I'm Carrie! Go Away!"
The fact that it's only some mail is interesting. The error being relay denied may also be key, though these anti-phishing filters often use "fake" errors to not give away the game.
Do the recipients of the messages that are being rejected have some kind of internal forwarding applied? That may be the cause, in which case that bounce reason is honest.
Or they may have a more defined anti-phishing feature, only rejecting mail From or For certain addresses. You can try testing certain combinations, and see if anything is repeatable.
Ultimately however, it will come down to working with the receiving mail domain's admin, and either updating those rules, or whitelisting the SendGrid IPs that are sending the mail to them.
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...
Sorry if I have not understood something but (I believe) I have searched enough for this.
First things first: I have successfully set up my domain (mydomain.gr) which has been verified.
I have created a custom SMTP address (contact#mydomain.gr).
I have created a route which forwards everything sent at *#mydomain.gr to my personal Gmail address.
Test 1: If I send an email from an external address (something#something.eu) to contact#mydomain.gr it is forwarded to my personal Gmail. OK!
Test 2: If I send from contact#mydomain.gr to any external address (something#something.eu) I get the error Free accounts are for test purposes only. Please upgrade or add the address to authorized recipients in Account Settings. Of course the password is correct while sending. Otherwise another error is raised.
I think I have missunderstood some things...
So here comes my question:
How can I send email from my custom SMTP email address? (I do not wish to upgrade my account since this -free- Mailgun account will handle very small amount of emails. So, 10K are more than enough for me.)
OK. After some emails with the mailgun team I finally figure it out!
All I had to do was to upgrade my account (just enter credit card info). Now I can send email from contact#mydomain.gr to anyone.
Thank you mailgun!
I have also contacted Mailgun for the issue and get response back within few minutes:
This error occurs whenever utilizing either a sandbox domain or a free account without inviting users called Authorized Recipients.
Sandbox domains always require Authorized Recipients. With free plans, which are intended for test usage, all custom domains require Authorized Recipients. With upgraded plans, which are intended for production usage, custom domains no longer require Authorized Recipients.
Please take a look at the following Help Center article for more information about the Authorized Recipient process:
https://help.mailgun.com/hc/en-us/articles/217531258-Authorized-Recipients
Then I have add the Authorize Recipients and it works like a champ!
At the moment, we are sending an email address verification email each time someone signs up. This email has been causing a number of problems: people don't get it, they just don't click the link in the email or the email gets block by spam or some other method. We are working on resolving the spam issue, although I don't think it's possible to completely resolve it.
I'm wondering what other methods there might be for verifying and email address. Is there any other way to verify an email address without sending an email? Or is there another method of ensuring people aren't signing up with fake information?
I'm not sure if there are other good methods, but sending an email and having them click a link is definitely the simplest and most accurate.
A main feature to sending that email, is for the person to verify that it's actually them that requested it.
The only way to verify someone owns an email address is to have him use it.
As for verifying users don't enter fake information - not even sending an email can help. With so many disposable/temporary email services out there (like GuerrillaMail) , someone can fill up your form with false info, post a temp email address, log to that address and click the link in your email - manually or programatically.
You have to trust your users to come back for your content, and ignore spammers.
strikeiron.com offers a paid web service to verify if an email exists without sending a message to that email. try it out here is the link: strick
http://www.strikeiron.com/Catalog/ProductDetail.aspx?pv=5.0.0&pn=Email+Verification