Firebase Hosting - Emails not coming through - email

I followed the procedures and set up firebase hosting for my domain: when the user types in domainname.com or www.domainname.com the site hosted on firebase is opened.
But my emails do no longer come through :(
Error messages include
Action: delayed - Status: 4.4.1 -
Diagnostic-Code: smtp; The recipient server did not accept our requests to connect*
It will try a couple of times and then fail.
The domainname is registered with awardspace.com. There, I have the possibility to set DNS entries for domainname.com, mail.domainname.com, www.domainname.com and mx.domainname.com
Note: I can sent emails from info#domainname.com

Resetting DNS records at my provider, disconnecting the domainname from firebase hosting and connecting the domain again from scratch solved the issue for me.
Note: the previous connection used CNAME records, no longer used / needed by firebase.

Related

Links inside Sendgrid Emails Not Working After Pointing DNS domain to Linode servers

(MERN PROJECT) I'm using Sendgrid to send emails to confirm user accounts once they register. Before hosting the app on Linode, the links inside the emails worked fine. After configuring my DNS (Namecheap) domain to point at Linode's servers the emails continued to function however the links inside of the emails became broken.
Clicking the link would produce this error: Check if there is a typo in url781.xxxxxx.com.
Before the configuration the links did not contain "url781" prefix and so everything worked fine.
Wondering if anyone has come across similar issues when working with an smtp provider during the deployment stage.
NOTE: I followed Linode's guide to setting MX servers and set up the Sendgrid configuration mentioned there but it did nothing to resolve this issue.

How to use a custom SMTP URL for Mailgun?

I use Mailgun for the outgoing emails of my customers and Cloudflare to manage DNS.
The problem is that my customers want to send emails using GMail as well, but I don't want them to know which service I am using.
Therefore, In case in the future I change the service, I don't want to contact all customers asking to change the parameters again.
Here is what I use:
So I decided to use DNS for this: I created for each domain a new CNAME (smtp.mydomain.com) which points to smtp.eu.mailgun.org:
Everything worked fine for few months by now, but from yesterday emails sent from GMail bounce back with this error: "TLS Negotiation failed, the certificate doesn't match the host".
I tried using other ports also, but still the same result.
If in GMail I use smtp.eu.mailgun.org instead of smtp.mydomain.com everything works fine again, so I guess the problem is in the DNS/Cloudflare configuration...
This is the report of the DNS Check of smtp.mydomain.com that I get from MXToolbox:
Any idea on how to fix this?
Thank you!
SOLUTION:
As of April 2020, Google started enforcing TLS when sending email.
In the Gmail settings under Accounts and Imports, Edit your Send mail as Email settings.
Change your outgoing servername (SMTP Server) to smtp.hostprovider.com (mine was smtp.dreamhost.com). If you are using your website name, (mail.example.com), this will continue to fail.
I also updated the port number from 587 to Port 465
Hope this helps.

email crash after domain transfer

I'm helping a friend to migrate a website to his server, however, after the domain transfer the client's emails stopped working. I believe their email was hosted on cPanel with the old provider. What does he have to do to get the emails working again? The old service hasn't been terminated yet.
With the limited information I would recommend looking into the following.
Verify the MX records are set correctly.
Verify any subdomains they are using for example mail.domain.com or imap.domain.com etc are still pointed to the proper email server. Can verify old DNS records on previous domain server.
I would also look into the error the mail client is getting. For example is the error an auth error, server not found or something else.
You can use online tools such as https://mxtoolbox.com/ to verify that the dns records are correct.

Will email go down when website goes down if email is hosted elsewhere?

We are hosting email with a hosted exchange provider so it is separate from the website.
The domain is registered with 123 reg and the nameservers are pointing to a server where the web files and database sit. From our control panel we have configured the appropriate MX/DNS entries to point the email to the hosted exchange server.
If our server went down where our website sits, will our email go down too because the MX records and DNS entries are hosted on this server?
Thanks
It depends. DNS is usually cached, so any email server that recently sent you a message and the TTL hasn't expired, should be able to reach you. Any new requests could go unanswered.
That being said, what I described will not provide any reliable redundancy. The best solution is to have another authoritative dns server in a separate location in case your server goes down.
It sounds like you're worried about missing messages. If your downtime isn't more than 24 hours you should be ok. Most email servers will try several times to send a message before it's returned.

Could a mail server be blocking a domain?

Weird question here. Could a mail server be blocking a domain?
I ask because i am in the process of migrating to a new server and i am testing out a few email accounts.
the domain x.com is hosted on server 1
the domain y.com is hosted on server 2
the domain z.com is hosted on server 2
If i email from x.com to y.com, the server replies with
550 sorry, no mailbox here by that name. (#5.7.17)
However, if i send from x.com to x.com also x.com to z.com they send fine.
y.com and z.com are on the server, so i don't see an issue with an IP block or anything like that.
Generally this error happens when mail was hosted on the server at some point, but has since been moved to an external mail server. Qmail will still try to deliver the message locally and fail with this error:
This_address_no_longer_accepts_mail
To correct this check the following two files for the domain in question:
/var/qmail/control/rcpthosts
/var/qmail/control/virtualdomains
Remove the line with this domain from both files then restart Qmail:
/etc/init.d/qmail restart
From http://toastergremlin.com/?p=181