Question FormMail.PHP won't send emails

[schemer]

Are you sure that mx00.ionos.com can be the correct MX entry? Should that not point to your server instead?

I am not sure of anything after spending a week trying to figure this out. Here is what I read:

Name servers are the servers that assign a specific IP address to each specific domain name that has set those name servers in its DNS settings.

They are responsible for your domain being found under a fixed IP address when the visitor types in the domain name itself, making it easier to find websites by name rather than by a set of numbers. IONOS uses its own name servers to automatically assign an IP address for a domain during the registration process at IONOS.

By default, all name server settings are pre-configured for your IONOS domain. You can configure a website, blog, or online store, and set up the appropriate email mailboxes. You don't have to worry about a thing!

Typical name server entries are:

ns1ZZZ.ui-dns.de
ns1ZZZ.ui-dns.biz
ns1ZZZ.ui-dns.org
ns1ZZZ.ui-dns.com

ZZZ represents a number between 016 and 126.

And this link:

Adjust MX Records for Receiving Email via IONOS Mail servers - IONOS Help

says:

Note:

    The DNS settings described here apply to IONOS.com customers. Different settings apply to customers with IONOS contracts in other countries.
    Please note that as of 14 September 2020, receiving emails will only be possible using the correct MX record entries mx00.ionos.com / mx01.ionos.com (alternatively mx00.1and1.com / mx01.1and1.com).

Thanks for looking,

 

[learning_curve]

@schemer FWIW, we're also with IONOS (Cloud) but have no issues at all with mail, even when using PHPMailer on some hosted domains. You have already said that you have root access i.e. You are not using a mananged service from IONOS, but which IONOS server are you using? Dedicated, VPS or Cloud Server? (Ref: IONONS-HERE) as there's subtle differences. Plus, which IONOS date centre (US / UK / Germany etc) are you using? As again, there's subtle differences.

Back to this thread, content @Peter Debik has already asked: "Are you sure that mx00.ionos.com can be the correct MX entry? Should that not point to your server instead?" - We would ask the same question too. We have a specific sub-domain for mail on all hosted domains, e.g. mail.mydomian.com i.e. NO IONOS mail servers but, we do use IONOS not Plesk, for all DNS, so ALL of our hosted domain MX entries do NOT include the mentioned IONOS mx00.ionos.com etc.

Worth remembering that test sites like intoDNS: checks DNS and mail servers health can sometimes give a false positive, on certain records, due to several things e.g. an unusual domain name. One of our own hosted domains is an example; Testing mydomain.global at intodns will give the MX name validity "error" below, despite everything else being reported as 100% correct whilst the same item and all the other mail and MX tests are reported as 100% correct on other mail / mail server test sites. This error isn't seen on any conventional domain name tests on intodns e.g. the MX name validity of mail.mydomain.net etc even though, all of their mail / mail server setups are identical to mydomain.global and the tests run by intodns are identical. It's just a false positive, nothing more.

MX name validity

The MX records that do not seem valid hostname: mail.mydomain.global This can cause problems

 

[ChrisCP]

Ionos blocks port 25 by default. You cannot open this port by yourself, you have to contact Ionos support and ask them to open port 25 for sending.

 

[schemer]

Ionos blocks port 25 by default. You cannot open this port by yourself, you have to contact Ionos support and ask them to open port 25 for sending.

Thanks ChrisCP. Unfortunately that port is open on both incoming TCP and outgoing SMPT. One of the tech support guys at IONOS opened port 25 over a week ago. But I called to verify and he checked and yes it is really open. We went through all of my settings on IONOS and Plesk and he does not see anything wrong with my setup. He even checked to see if I was blacklisted (my ip address) and didn't find anything.
Still figuring...

 

[schemer]

@schemer FWIW, we're also with IONOS (Cloud) but have no issues at all with mail, even when using PHPMailer on some hosted domains. You have already said that you have root access i.e. You are not using a mananged service from IONOS, but which IONOS server are you using? Dedicated, VPS or Cloud Server? (Ref: IONONS-HERE) as there's subtle differences. Plus, which IONOS date centre (US / UK / Germany etc) are you using? As again, there's subtle differences.

Back to this thread, content @Peter Debik has already asked: "Are you sure that mx00.ionos.com can be the correct MX entry? Should that not point to your server instead?" - We would ask the same question too. We have a specific sub-domain for mail on all hosted domains, e.g. mail.mydomian.com i.e. NO IONOS mail servers but, we do use IONOS not Plesk, for all DNS, so ALL of our hosted domain MX entries do NOT include the mentioned IONOS mx00.ionos.com etc.

Worth remembering that test sites like intoDNS: checks DNS and mail servers health can sometimes give a false positive, on certain records, due to several things e.g. an unusual domain name. One of our own hosted domains is an example; Testing mydomain.global at intodns will give the MX name validity "error" below, despite everything else being reported as 100% correct whilst the same item and all the other mail and MX tests are reported as 100% correct on other mail / mail server test sites. This error isn't seen on any conventional domain name tests on intodns e.g. the MX name validity of mail.mydomain.net etc even though, all of their mail / mail server setups are identical to mydomain.global and the tests run by intodns are identical. It's just a false positive, nothing more.

MX name validity

The MX records that do not seem valid hostname: mail.mydomain.global This can cause problems

learning_curve,
I am using a Virtual Server Cloud L as shown here and have root access etc and based in the USA. VPS IONOS On the MX entries I was on the phone this morning and tech support verified my settings are all correct so I don't know what to do there instead of looking elsewhere. I looked at my mail log file again and found a lot of "refused to talk to me" and "delivery temporarily suspended" and also a link to Cloudmark to fill out a form for "Please visit CSI IP Reputation Remediation Portal AUP#IPBL1000)". The x's are my ip covered by me of course. I am going to fill out that form and see what they have to say.
Thanks

 

[schemer]

I just filled out the form and will see what happens...

Cloudmark​

CSI IP Reputation Remediation Portal​

IP Reputation Remediation Request Complete​

Your request has been sent to the Cloudmark IP Remediation Team for evaluation.
More information about Cloudmark Sender Intelligence and why your email may have been blocked: FAQ.
Enter another request for IP reputation remediation.

 

[schemer]

That was quick. Here is what Cloudflare wrote back. I still have to learn/figure out how to set this up, but I will ask my provider for help first.

Dear Dave,

Thank you for contacting Cloudmark.

Follows is our generic rdns text, but it also applies when we notice the rDNS for the IP address does not match the domain you supplied in the form.


Please could you update the rDNS on this IP to be something more specific to the sender and/or your organisation rather than the generic pattern that the provider has assigned by default. You may need to contact your provider in order to accomplish this rDNS change. Continuing to send mail from an IP with a generic rDNS pattern is likely to affect your Cloudmark reputation score in the future as well as your reputation with many ISPs and DNSbls.

For instance mail.example.com would be considered far less generic than 208-83-136-1.sfo.example.com or hosted-by.example.com

xxx.xx.xx.xxxx www.mysite.com

I have reset the reputation of your IP, so you should see delivery improve shortly. Please note that updates do not occur instantly but should generally happen within an hour of receiving this response.

For further information on rDNS naming patterns you may wish to consult:
The Spamhaus Project - Frequently Asked Questions (FAQ)

--
Cloudmark CSI Support

"Dave" <[email protected]> wrote:

Name: Dave

Title: admin

Company: user

Phone #: xxx-xxx-xxxx

IP Address: xxx.xx.xx.xxx

Originating IP: xx.xxx.xxx.xxx

Domain: www.mysite.com

Comment: I switched from Hostmonster to IONOS and moved my 7 domains over and am
trying to run a Formmail script from tectite.com that I used to use without issues
for years. The PHP form works but the emails are never sent or received.

Rejection Notice: AUP#IPBL1000

Issue: 10

>

 

[schemer]

Tech support (IONOS) said I should add SPF records so that is what I did after he showed me how to do one. I will report back tomorrow if that worked.
Fingers crossed...

added: Some of the emails are coming through form yesterday and before from the backlog so I guess it's working. It might just be from the block lifted. Don't know if the SPF records kicked in. But the tech (from Cloudmark) did seem like he thought the rDNS needed work. So my next thread (tomorrow( will be on rDNS. More testing tomorrow.
Thanks for all the responses here.

 

[learning_curve]

....On the MX entries I was on the phone this morning and tech support verified my settings are all correct so I don't know what to do there instead of looking elsewhere.....

Thanks for the info. Your IONOS VPS based in the US isn't exactly the same setup as our IONOS Cloud setups based in the UK, so can't directly relate, but the actual need to use the mx00.ionos.com etc entries apart from it being the most simple / least input option available at IONONS is still questionable really...

In post #15, you could already see that the MX PTR record is different as a result of this (below) and whilst intoDNS is correctly reporting "...that is a good thing..." which is correct, in terms of a reverse (PTR) record actually existing, but the details shown are very different than your server / domain IP details, which ironically, are shown on the very next line of that specific intoDNS report under the WWW A Record section, as you can see if / when you look back at it.

Reverse MX A records (PTR)

Your reverse (PTR) record:
21.5.208.74.in-addr.arpa -> mx01.perfora.net
3.5.208.74.in-addr.arpa -> mx00.perfora.net
You have reverse (PTR) records for all your IPs, that is a good thing.

You've posted that Cloudmark CSI Support disagree with the differences, as do many other test sites e.g. You can test the domain that you used in post #15 yourself, here: Domain Health Check - Online Domain Tools - Blacklist, Email, Website, DNS - MxToolBox and here: Email Server Test - Online SMTP diagnostics tool - MxToolbox then look at the results. It's not just the reverse (PTR) record that's marked as an isssue as you can see, its dmarc too and that's relevant at the moment, because it's not 100% clear at this stage that the reverse (PTR) issue is the only cause of the problem that you posted initially, when using Tectite (Free). There are many other e-mail test sites that you can use too to get a clearer picture, but again just FWIW, the IONOS Cloud setups that we use doesn't result in any IP / reverse (PTR) mismatches, dmarc issues or any other probems, consequently (maybe luckily?) we don't have any current IONOS mail problems.

 

[schemer]

My home ISP is having serious outages in my area and many others starting last night and still messed up this afternoon. A bad day for testing anything and my mail server for my home ISP is not sending any mail most of the day. Timeouts etc. I will post back tomorrow...
Sorry