The email address is Invalid because it's Bounce.

[chronic]

Hi, I wanted to share a problem that I discovered I have with all directadmin servers, and with all mail addresses of all domains.

Yesterday I was registering with a well-known online graphic resource site, and upon registration it told me that my company email address was not valid, so I tried with that of another domain always on the same server, and this too was invalid.

So I decided to ask the website support for assistance, and they replied:

"We are sorry to inform you that our system recognizes your email address [email protected] as invalid and bounce. Please check it here: https://debounce.io/

This is most likely due to the fact that the domain is probably not a direct email address but an address that gets emails redirected via an "umbrella" address.

Please create the account with a different email address."

At this point I decided to test my address and also other addresses all hosted on different servers with directadmin, to the site indicated by them https://debounce.io/ and they all return the same result:

"The email address is Invalid because it's Bounce."

This thing doesn't happen if I try with other addresses that don't use directadmin.

Given that this is the first time I've had such a problem in many years of using directadmin or at least I've never noticed it, I wonder if there could be something in the mail configuration that generates this result? And if so, how could it be solved.

Thanks in advance to anyone who can enlighten me on this.

 

[Richard G]

To me, this seems spamming about that debounce website, because the rest is a load of BS, sorry.

 

[chronic]

Sorry Richard, but I didn't understand this part of your answer "because the rest is a load of BS, sorry."

 

[Richard G]

Ok at first I thought somebody might even have hacked your account. I presume you know what BS stands for, but in a nice very nice way said, it's not believable.

At least you understood the first part. There is no way we can check without registering on that site, which me for example certainly will not do.
Then about the bouncing stuff, after all this years, this (if it's true) is the only site stating that DA mail addresses would not be good, over all the world. While DA just uses Exim like a lot of others, including other professional panels do.
If all the world have no issues and only 1 or 2 sites do, then in 99,9% of the cases, the issues is either with those sites or with your configuration somewhere.

You can rather visit https://www.mail-tester.com and do the check, it's free. If you get a 10/10 there, you are fine.

If DA mail addresses would bounce, then we all would have issues, especially with really big mailers like Microsoft and Gmail and others. Also on this forums are a couple of guys who are professionally busy with e-mail in very big proportions. I won't even mention one of them, so I won't waste their time.

If you are really posting this from an honest feeling, then why only making advertisement for the .io site and you don't even state which "well-known online graphic resource site" you were trying to register.

It all seems too funny to me and too chatgpt maybe or something like that, especially because of your follow up question about the rest of my answer.

 

[chronic]

I'm sorry to have been misunderstood, I didn't want to do any kind of advertising or spam, mine just wanted to be a request for help, because I ran into a problem with registering on a site that sells graphic resources on the net, in fact I omitted that service precisely because it was irrelevant from my point of view.

Instead, I mentioned and reported the other url just to allow anyone who might want to help me, to check where the problem was reported to me and maybe try it, because on the page there is the possibility of testing an email address without having to register, I too would never have signed up honestly. My servers generally don't have bounce problems, but the technical support report of the site I was registering for alerted me to possible problems I might have.

Then I noticed that entering different addresses of my servers always gave the same result and I thought it could be related to a configuration problem with my servers, mine is absolutely not an accusation against directadmin, which as you can see I have been using with satisfaction for several years, but a request for help, on where to investigate a possible configuration problem that could give this result.

 

[BillyS]

Of course there could be something wrong with the configuration of your mail servers. Again, there is enough experience here to indicate it would not be a problem with DA. Doing some quick research, it appears DeBounce has a good reputation. Do they tell you what this actually means?

>"The email address is Invalid because it's Bounce."

It appears they have both hard and soft bounces.

 

[chronic]

They don't really say much more, the addresses I tested pass all tests except the bounce one.

This is their analysis report:

Your email address is Invalid because it's Bounce.

Role: false
Syntax Error: false
Spam-trap: false
Disposable: false
Deliverable: false
Accept-all: false
Free Email: false

Invalid
An invalid email address has been verified as a bad recipient address that does not exist or is not accepting mail. Invalid emails will result in a bounce.

DON’T SEND – These emails do not exist and are not safe for sending.

I wonder if anyone else can try testing an email address to see the result, it's about halfway down their homepage. I'm curious if it's just my problem. I can't understand why, in the end I use all standard directadmin settings for mail, I don't like to customize too much just to avoid running into possible problems.

 

[BillyS]

I just tried it and it worked for me. The first time I got Deliverable, Role because I used one of the admin@, info@ type email addresses. When I switched to a non-Role email I got the below result.

The email address is Safe to Send because it's Deliverable.

---

DELIVERABLE
Free Email: false
Role: false
Syntax Error: false
Spam-trap: false
Disposable: false
Accept-all: false

Have you tried using tools like mxtoolbox to see if there is a configuration issue?

Domain Health Check - Online Domain Tools - Blacklist, Email, Website, DNS - MxToolBox

mxtoolbox.com

 

[chronic]

Thanks BillyS, I tried the service at the link you recommended and everything worked fine, it passed all the tests, no warnings and no errors.

I then found other services similar to debounce, some even though I didn't know them seem quite well known and authoritative, and some did not report any problems with my email addresses, they were valid results, and others instead reported the same debounce problem, i.e. that the email address doesn't exist on the server, which of course it doesn't, because addresses exist.

But I honestly don't know what to think and where to look. Since in general I have no problems, but it was by pure chance that I discovered this anomaly, I'm starting to think that in reality there isn't a real problem, but maybe I'm wrong and I should investigate more.

 

[Richard G]

But I honestly don't know what to think and where to look.

As I stated in post #4, if you want to investigate if all is good, check the https://www.mail-tester.com site and see if you get a 10/10 score.
If not, then mostly it's stated why not and then you know where to look for.

Sorry if I might have been a bit blunt, but since I only seen the commercial link, and not the graphic site stating the issue, I was concerned about maybe your account was hacked.
Seems it's not, so again, I apologize if I was a bit blunt for that reason.

Please take the time to test via mail-tester.com (not mailtester.com!!) and evt. you can share the results, unless you have 10/10.

 

[chronic]

Richard, you were just a bit abrupt I admit that I was a bit upset by your reaction, because I have great respect for your activity on the forum, anyway, no problem, apologies accepted

Yes, I already knew that service used in the past, but I've always thought it was more useful than anything else for checking the compliance of emails when sending newsletters.

I did the test anyway and the result was 10/10.

 

[Richard G]

apologies accepted

Thank you, sorry that I managed to upset you. I really thought your account was hacked as previous time we had good contact. Glad to see that I'm forgiven.

The service is good for newsletters, but also for allround check of the mail system. If you have a 10/10 there, which you have, your system should be in good order to send e-mail to everywhere unless it's on some blocklist.

When looking at the test of @BillyS then I'm also wondering as to why you get a notice of "invalid" e-mail address.
Since I've been unjustly abrupt, I will register there and also do a test with 2 or 3 mail addresses of different servers and see what result it will give.

I will share it here.

 

[sparek]

Never heard of Debounce. Not sure what they're doing. If they are reporting that an email address will bounce when the email address is valid, then that would seem to indicate that their process for making this determination is flawed.

But you can check whether an email address is being accepted by the MTA (doesn't mean it'll go into the user's inbox, but the remote mail server will... in all likelihood... accept the message) just using basic system administrator tools.

If you want to determine that [email protected] is a valid email address and you're running these commands from the server called myserver.server.tld:

dig example.tld MX

This will list the mail servers (Mail Exchanges) that are handling mail for example.tld. Pick one of these these servers (for argument's sake, I'll say it returned mail.example.tld).

telnet mail.example.tld 25

to connect to the remote mail server on the mail sending port, port 25.

Then in the telnet session type:

EHLO myserver.server.tld
mail from: <>
rcpt to: <[email protected]>

If this returns a 250 OK response, then [email protected] is a valid email address. If it returns something else, then mail.example.tld is not going to accept mail to [email protected].

Type quit to end the telnet session.

If you are familiar with Sender Callouts - where a remote MTA will try to determine if the email address sending the message is an actual email address that exists - this is the same (or similar) procedure those callouts do.

I say that in all likelihood mail.example.tld will accept messages if it return a 250 OK response. If mail.example.tld is doing any type of spam filtering or content filtering at SMTP time then it's possible the mail server may refuse to accept the message after the content is received. But that would still mean that [email protected] is accepting some messages - just the message you are sending is being filtered and rejected.

 

[Richard G]

I think dabounce is giving some odd resultes.

First test is with a hobby mail address of mine on server 2. This domain has SPF, DKIM and DMARC and even DNSSEC.
But this is the result:

Your email address is Risky because it's Deliverable, Role.

DETAILS:
[HR][/HR]
Email: [email protected]
Role: true
Syntax Error: false
Spam-trap: false
Disposable: false
Deliverable: true
Accept-all: false
Free Email: false

Then a hobby domain of mine on server 1, which domain does not even belong to me, only the subdomain. It's a free servers like no-ip.com so I have something like somename.no-ip.com but then with another service.
This only has SPF and DKIM, nothing else and look here:

Your email address is Safe to Send because it's Deliverable.

DETAILS:
[HR][/HR]
Email: [email protected]
Role: false
Syntax Error: false
Spam-trap: false
Disposable: false
Deliverable: true
Accept-all: false
Free Email: false

I don't know why on the first test the role is true and second test the role is false. But it's already odd that the first email address which is protected so big, get's a Risky result, because it's deliverable??? Mail should be deliverable right? So why risky...

Test 3:
This is with a company mail address of me, which I won't make public, but it's not a common address, this is also protected by SPF, DKIM, DMARC and DNSSEC and this is the result:

Your email address is Safe to Send because it's Deliverable.

DETAILS:
[HR][/HR]
Email: [email protected]
Role: false
Syntax Error: false
Spam-trap: false
Disposable: false
Deliverable: true
Accept-all: false
Free Email: false

So I got 2 safe to sends and 1 odd risky, result. I don't know how to interpret these results or why once I get a Safe to send with as reason that it's deliverable and the other time Risky because it's deliverable.

Do you always get the "invalid" email address notification?

I wonder if they are not trying to get people to take accounts, not sure. Can you share which online graphics site refused your email? Maybe I can test there too.

 

[Richard G]

Ah found it. If you look again at single check, you get a list of the checked e-mails.

The "risky" one was given number 8, which means it's a role account such as info, support, etc. and that gets a "maybe, not recommended" to send with, probably because they are often send to by spammers.

Could you have a look which code number your tests have @chronic?

 

[sparek]

Looking at their website:

Is It Safe to Send Emails to Role-Based Email Addresses? - DeBounce

Is It Safe to Send Emails to Role-Based Email Addresses? Tuesday, April 30th, 2019ArticlesDeBounce During your email lead generation, you will collect different types of email accounts including role-based email accounts. While it is advisable to send emails to deliverable email accounts by an...

debounce.io

It would seem that they just arbitrarily determine what email accounts are designed for a specific role. [email protected] is not expected to go to an individual but is expected to go to a group of people that work in Support.

Not sure I really buy all of that - who gets to make these arbitrary determinations?

The paranoid in me would has to wonder if the whole point of the website is to collect "valid" email addresses that they can then sell to marketers.

 

[Richard G]

The paranoid in me would has to wonder if the whole point of the website is to collect "valid" email addresses that they can then sell to marketers.

Hmmz... I wonder... you might even be correct in that. However, I'm just wondering which code that @chronic get's because he get's an invalid notice. And I'm curious as to which well known online graphic resource site refuses good addresses, probably base on them using the api of dabounce. Which to me, seen the results, seems not the best choice to use.

 

[chronic]

Never heard of Debounce. Not sure what they're doing. If they are reporting that an email address will bounce when the email address is valid, then that would seem to indicate that their process for making this determination is flawed.

But you can check whether an email address is being accepted by the MTA (doesn't mean it'll go into the user's inbox, but the remote mail server will... in all likelihood... accept the message) just using basic system administrator tools.

If you want to determine that [email protected] is a valid email address and you're running these commands from the server called myserver.server.tld:

dig example.tld MX

This will list the mail servers (Mail Exchanges) that are handling mail for example.tld. Pick one of these these servers (for argument's sake, I'll say it returned mail.example.tld).

telnet mail.example.tld 25

to connect to the remote mail server on the mail sending port, port 25.

Then in the telnet session type:

EHLO myserver.server.tld
mail from: <>
rcpt to: <[email protected]>

If this returns a 250 OK response, then [email protected] is a valid email address. If it returns something else, then mail.example.tld is not going to accept mail to [email protected].

Type quit to end the telnet session.

If you are familiar with Sender Callouts - where a remote MTA will try to determine if the email address sending the message is an actual email address that exists - this is the same (or similar) procedure those callouts do.

I say that in all likelihood mail.example.tld will accept messages if it return a 250 OK response. If mail.example.tld is doing any type of spam filtering or content filtering at SMTP time then it's possible the mail server may refuse to accept the message after the content is received. But that would still mean that [email protected] is accepting some messages - just the message you are sending is being filtered and rejected.

Yes,

dig example.tld MX

Return correct mx record

telnet mail.example.tld 25

If I try from my pc, it hangs:

Trying xxx.xxx.xxx.xxx...
telnet: Unable to connect to remote host: Connection timed out

If I try from another server with directadmin installed:

Trying xxx.xxx.xxx.xxx...
telnet: connect to address xxx.xxx.xxx.xxx: Connection refused

I wonder if they are not trying to get people to take accounts, not sure. Can you share which online graphics site refused your email? Maybe I can test there too.

The site is freepik.com

Could you have a look which code number your tests have @chronic?

If you are referring to this page, https://help.debounce.io/kb/understanding-results/result-codes/ the number for me is 6

The paranoid in me would has to wonder if the whole point of the website is to collect "valid" email addresses that they can then sell to marketers.

I have to admit that even the paranoid in me often makes me think about this when I use this kind of services.

 

[Richard G]

the number for me is 6

Oke thank you. Very odd that there is no reason given there except for "Verified for invalid (bounce)", however... maybe it's the port 25 issue.

If you want you can give me domain and ip per pm and I will have a look from my server if a telnet connection is possible and check some things.

 

[chronic]

Ok guys, I found the problem. Just in a recent forum conversation that Richard also participated in if I remember correctly. I had started using the spam.spamrats.com rbl, also with some success to be honest.

Removed this rbl from servers the result is now valid.

On another server instead, specifically, I still had the rbl bl.mxrbl.com active, I had tested it in the past, it was effective, but it seemed too restrictive to me, because following this in the past some customers had contacted me for blocking problems but that's another story.

At this point I just have to thank you all, especially Richard who is always very precious, for the support you have given me and your time spent, it's nice not to feel alone in these situations.

I hope this little mishap of mine maybe helps someone in the future.