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!
Related
I am new to firebase and I am trying to handle firebase user authentication in React.js. I did manage to create users with email and passwords. But, now I would like to send the user an Email link to reset their password.
My code currently look like this.
// This line of code belongs to the top
import { auth } from '../firebaseConfig'
//This part goes under the React component
<p onClick={async () => {
try{
await sendPasswordResetEmail(auth, // My Email Id)
alert('Password reset link has been sent to your email')
}
catch(err){
alert(err)
}
}}
>Forgot your Password ?</p>
However, I do not get any error messages and I do get the alert message that says "Password reset link has been sent to your email." Unfortunately, I didn't receive any email. Note that I have given my own email id as the parameter for testing purposes.
firebaser here
Did you check your spam folder? We recently see a lot of the emails from Firebase Authentication ending up in the user's spam folder or being marked as spam in a system along the way. This is being tracked in this status message on the Firebase dashboard and in public issue #253291461.
To reduce the chances of the messages getting marked as spam, consider taking more control of the email delivery yourself.
As a first step, consider using a custom domain with your project. Email that comes from a custom domain has less chance of being marked as span.
As a second step, consider setting up your own SMTP server.) for delivering the email, so that the emails are not being delivered from Firebase's shared infrastructure anymore.
While these steps are more involved, they typically will drastically reduce the cases where the messages from Firebase Authentication are marked as spam.
Full Guide Based on Frank's Answer
Firstly create a new email account you can use to relay the Firebase emails through the SMTP server with. I personally chose Gmail, but I tested with Outlook and it also works.
You can now find an SMTP server host that will work for your scenario. If you're sending less than 1000 emails per month you can find free and reliable hosts. I chose SMTP2GO's free option.
Now you've found the SMTP host, add the email address you've chosen as a single sender email (note that if you do own a domain, you can alternatively use that to send emails).
Note that you will have to verify the email, usually by your host sending a link to the email's inbox. Make sure to check spam.
Once verified, navigate to where you host allows you to add SMTP Users and add a new user. This will allocate an SMTP username and password.
Navigate to the Firebase console, and choose the Authentication option from the sidebar (within the Build product category).
Go to Templates → SMTP Settings and enter the details of your SMTP server. The username and password fields are to be filled with the SMTP user login you created in the step above.
It is better to use TLS, but I believe SSL should work too but it is untested.
Click save, and you're all set up - but there may still be steps to perform depending on your email provider.
Provider Specific Steps
If the emails are being sent to an account managed by Google you will have no issues with your emails being quarantined by anti-spam policies and it will work immediately.
If you are using Outlook, you will have a different problem on your hands. Outlook's built in defender will most likely have auto-quarantined your email under multiple policies - that bit is important.
These policies are likely to be both spam and phish policies. If you unblock one of them, the other will catch it and re-quarantine.
Unblock both policies for the email address, and test. You can see the status of quarantined messages in Microsoft 365 Defender app under Review → Quarantine. Please note that you will need to be an administrator to add global allow policies to your email accounts.
If this still doesn't work it is likely that your company has an additional external filter (as mine did), and you will have to add the IP's manually to the Tenant Allow/Block Lists spoofed senders tab.
(Disclaimer I'm fairly new to development in general and this is my first StackOverflow post all and any feedback is greatly appreciated.)
I'm posting here because I'm on a free SendGrid account and their support team has yet to get back to respond and it's been over a week and I'm dying to solve this issue.
Currently, I'm using Sendgrid as an SMTP and recently my emails have stopped sending to the following esp Yahoo, AOL, and Verizon.net but emails send to Gmail just fine.
Because emails still send to Gmail I used "Email Header Analyzer" via mxtoolbox.com to review and meet the recommendations provided. Which I have implemented on. (See screenshot)
The only thing not checked off is the "DKIM Authenticated" in which it's my understanding that when you verify the domain you're using to send emails with SendGrid takes care of that for you.
It's not the email function itself because it sends just fine to Gmail.
My question is has anyone else experienced this issue? If so what was the fix you did that made it work?
Screenshot of my email header analyzer results:
Turns out that my SendGrid account was over the daily email sending limit for the "free plan" and the emails that were sent correctly to Gmail had been doing so because of a pre-existing mail function (not using SendGrid even though SendGrid was still logging these emails).
I figured out this was happening by looking at the "mailed-by:" info when you toggle the drop-down above the email just under the sender email address. Mailed-ByView With SendGrid it would say "mail-by: sendgird.net" SendGird-Mailed-ByView
It would have been nice if SendGrid made my sending limit information a little more apparent but you can find this information about your account by going to "Settings">"Account Details">"Your Products." YourProductsView
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 making a user management system for my app, and I need to send users a "forgot my password" email with a token that lets them reset their account password. I signed up for SendGrid through Azure (to get the 25,000 emails per month free, which sounded like a great deal) and wrote some code to use it, but after testing my program a bit I was dismayed to find that only a couple of my emails actually went through.
After going onto the SG control panel, I found that 4 out of the 6 test emails I sent went through, and all of the others were rejected as being spam. I sent an email to mail-tester.com to see what it though my spam score was and it gave me a 4.3/10.
The email in question was a single sentence with a link to the password reset, without any images or other elements. I only sent those 6 emails out, so the volume of my emails definitely wasn't the issue. Still, I'm very puzzled as to why my messages are getting flagged as spam.
Without going to the trouble of making an elaborate authentication setup, are there any basic changes I can make to my system to make it get through to users?
In this case it's most likely because you are sending such a short message, with a link to 'reset your password' from a non-whitelabelled email address (the email address you're sending from cannot be verified against the actual domain), and the link may also be a different URL. It's probably getting pulled up as a potential phishing email.
You can rectify this by white labeling your domain and email links via the SendGrid dashboard, it's easy to do and should improve your deliverability.
Also check out this article from the SendGrid support team about White Labeling.
A question from 2015 which is sadly still relevant today as usage of SendGrid increases.
My organization has blocked all SendGrid mails except for those on the paid tier using fixed IP addresses with resolvable public DNS names (such as sendgrid1.sampledomain.tld) which we then whitelist.
There are now far too many domain impersonation, phishing and other spam mails coming in from SendGrid for us to allow everything from them - roughly 10 000 mails over a seven day period, which is far too many to manually report to SendGrids abuse department.
So my answer would be that switching to the paid tier of SendGrid is the better option if you like a better chance of your mails arriving intact at their destination.
I receive only Spam Mails from Sendgrid.
Goes direct to Spam folder and try to report Sendgrid everywhere I can. Maybe they get blocked by most mail servers and make them think about their policy in "hosting" all these Spammers.
In my case my emails are marked as spam because of the anchor label different to the href being actually called.
And that's because of the 'click tracking' setting of sendgrid.
So, if you have something like
yourdomain.com
sendgrid may replace the href and you end up with something like:
yourdomain.com
The sendgrid page being called tracks the click and then redirects the user to the url you originally set. But this sometimes results in your email being marked as spam.
Try to set 'click tracking' in sendgrid dashboard to off: settings | tracking | click tracking.
details here: https://sendgrid.com/docs/ui/account-and-settings/tracking/
Always start by setting up Domain Authentication, formerly known as domain whitelabel as #MartynDavies says. Found under Settings -> Sender Authentication in the UI. Should look like this:
https://sendgrid.com/docs/ui/account-and-settings/how-to-set-up-domain-authentication/
To identify problems have a look at Activity and choose to see deferred, drops, bounces, blocks and spam reports.
https://app.sendgrid.com/email_activity
Under Suppressions you can see details for Blocks and Bounces among others:
https://app.sendgrid.com/suppressions/blocks
https://app.sendgrid.com/suppressions/bounces
There you can see errors like:
550 5.7.1 SPF check failed. em1234.mydomain.com does not declare 11.222.33.44 as a valid sender
If it says Verified but you see errors like this then contact SendGrid support.
One thing that has worked is to upgrade from the Free plan to Essentials or Bronze via the Azure Portal. This made a lot of the emails marked as spam pass through.
I had a similar issue when trying to send a user verification email using SendGrid.
In my case, using a custom domain as the sender identity solved the issue.
Make sure to also verify the domain before using it.
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