0

This question is not about how to protect against spam or validate a particular email user. But how reliable is validating emails domain (does it exists at all) by reverse dns. What are the pitfalls of this method?

I don't care in this part is it some spam address or not, I just want to know if domain exists at all and is able to receive and send emails.

Like in title, how reliable is this check. I want to validate emails domain name, if it exists. I've asked similar question on board for programmers, but I can't get full answer, so I think this board will be better for such question.

Every single server in the world have their MX record exposed to the world? Or is there a possibility that there exists a server that hides their MX record and even if email will be valid, check will fail.

I know and I've tested that only emails domain is checked, not the user part. I just don't know how reliable it is. Is it always possible to check servers MX records.

With some more research I have found that some servers use something like MTA for mail exchange which don't use MX record. If I check A/AAAA records then, will that be enough?

2 Answers2

2

Not reliable at all and will fail for a HUGE % of legit email. Expecting the server sending mail for a domain to also be configured to receive email for the domain is an assumption thats very likely to be incorrectly.

For example many applications will send email through a 3rd party email sending service like amazon SES or google apps. These are generally send only services. In this case a mobile app sends through SES but mx records will point somewhere completely different i.e. On premise exchange.

The question of "Is the host connecting to me authorized to send email on behalf of the senders in the email it's delivering?" Is best addressed by DKIM and SPF. Use these techniques instead.

Nath
  • 1,282
  • 9
  • 10
0

Checking for an MX record on a given domain to determine whether that domain can accept email would be a good start, but you must bear in mind that the server listed in the MX record might not exist or might not be accepting mail for whatever reason. You would have to make a test SMTP connection and begin the basics of an SMTP session (e.g. get as far as RCPT TO) to know if the server was likely to accept your message. If there are multiple MX records, you would have to test all the servers until you got one that looked good.

MX records are no indication of whether a domain is likely to send email or not. In theory any domain containing a host speaking SMTP can send a message. I suppose the presence of SPF records in DNS might indicate a domain that is properly set up to send mail, but cannot be relied upon.

Mintra
  • 531
  • 3
  • 7