Facebook
Twitter
I received this message on gmail. I was sending an email to [email protected] from my personal gmail account. The message hasn’t been delivered to [email protected] however the emails I send from [email protected] have been successfully delivered to my personal gmail account. In other words I can send mails from the server but I cannot receive them.
-
If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
CentOS2Alma discussion
Issue Can send mails but can't receive (554 5.7.1 Relay access denied)
I receive this error from [email protected] and the message never reaches my mailbox hosted on my server. I have tried to send emails between two addresses hosted on the same server they never reached either.
Well, when I created the mailbox, it only has few options and none really concerned the server directly on plesk. I'll try to remove the DNS records (managed externally) but without the DMARC and SPF the emails were not sent.
Well, you don't have reverse DNS setup, since you are using VPS most likely.
I would connect your DNS records to the DNS of the server provider. You can use domain connect extension for that. Point the name servers to the DNS of your VPS provider, not to Plesk. Then setup MX records to point to the VPS provider's mail server. (or in fact any mail server). Or you can try to setup the reverse DNS, but Plesk is not good for emailing, since your IP will get blocked from Gmail, Outlook or in fact most mailing providers. That's the nature or VPS I guess...
I would connect your DNS records to the DNS of the server provider. You can use domain connect extension for that. Point the name servers to the DNS of your VPS provider, not to Plesk. Then setup MX records to point to the VPS provider's mail server. (or in fact any mail server). Or you can try to setup the reverse DNS, but Plesk is not good for emailing, since your IP will get blocked from Gmail, Outlook or in fact most mailing providers. That's the nature or VPS I guess...
Thanks for the input. I had set up SPF and DMARC records but it had not fixed the issue. I just had a nice green check mark on MX Toolbox… I never had issues before but I was using cloud hosting.
The thing is, you need to check if your VPS or cloud provider has reverse DNS already setup for you. Some providers already does it. If not, then mail will not work, no matter what. Having Plesk as a mail server is not a good option anyway.
SPF, dmarc, or domainkey (DKIM) records has no effect on the fact that mail is not being sent. It will have effect on deliverability though. Also, port 25 for SMTP. Please, don't open it, and use the secure 587, which is a standard these days. Weird that Plesk recommends opening port 25. SMTP port 25 is no longer used, it is a port from the 80s and not secure, against any data security measures.
If your VPS server provider has free mail server, just point it to them. I would also manage DNS with them, since a lot default setups are done for you. Or point MX to other mail servers with free options out there.
SPF, dmarc, or domainkey (DKIM) records has no effect on the fact that mail is not being sent. It will have effect on deliverability though. Also, port 25 for SMTP. Please, don't open it, and use the secure 587, which is a standard these days. Weird that Plesk recommends opening port 25. SMTP port 25 is no longer used, it is a port from the 80s and not secure, against any data security measures.
If your VPS server provider has free mail server, just point it to them. I would also manage DNS with them, since a lot default setups are done for you. Or point MX to other mail servers with free options out there.
Why do you think so?
When port 25 is closed, the server will not be able to send mails to other mail servers on the internet reliably, because no. 25 is the industry standard port for SMTP.
Such mail servers have the habit to being on DNSBLs frequently as many users are using them and some are always sending spam, knowningly or unknowingly. It is much better to send mail through your own server instead of some mass gateway.
Generally, companies would use Outlook or Gmail as email servers. Unless you are Oracle and can handle your own. But if you find any benefit in running mail servers, why not. Managed mail servers are cheap these days. No delivery issues, no spam, no malware and viruses.
It is a default one, but not secured. The malware risk is too high.
Checking if the (right) reverse DNS is set is a good suggestion. A lot of server won't accept emails from a server on which the reverse DNS is not (correctly) set. But it does not mean that email will not work as you stated.
That's very bad advice! Port 25 is the default (and only) port used for email traffic (SMTP) between servers. Which means that if you block port 25 on a server, there is no (normal) email traffic possible from and to that server.
And yes, SMTP connections between a server and a client over port 25 are not secure. Other, secure ports, are better suited for that use case. However port 25 needs to be open on a server for email to simply function.
Nonesens. Running your own mail server can be very useful and cost effective. But some technical knowledge is needed to get it to run smoothly.
Last edited:
That's if you use other mail servers. But the risk of malware or virus in email is just too big. I think separating hosting with mail is best if you don't have the resources. And if you check DNS of big companies, you will see most of them use Outlook or Google.
What are you on about? Literally every mail server connected to the internet uses port 25 for mail communication to other mail servers. Thats how email messages go from one server to another. No matter if its a Plesk server, Gmail server from Google or a mail server from NASA. They all use port 25. And blocking port 25 on a server will effectively disable to ability to send and receive email with that server.
Also which port is being used has absolutely nothing to do with malware or viruses.
Last edited:
