Email validation is often presented as a simple yes-or-no decision: an API checks an address, reports whether it exists, and supposedly tells you whether your message will be delivered.
But email works differently. Mailbox providers use anti-abuse systems, some mail servers deliberately conceal mailbox information, and even an accepted SMTP transaction cannot guarantee that a message will reach the inbox.
ILHAM Email Validation (IEV) takes a different approach. Instead of relying on a single SMTP response or claiming certainty about mailbox existence, IEV evaluates multiple signals to assess an address's validity, potential deliverability and risk.
Why Traditional Email Validation Has Limitations
Basic email validation usually checks whether an address follows the expected format. More advanced services may inspect DNS records, identify disposable email providers, query SMTP servers or attempt to classify catch-all domains.
These checks can be useful, but no individual method can reliably establish every fact about an email address.
1. Syntax Does Not Prove an Inbox Exists
An address can follow valid email syntax without belonging to an active mailbox. For example:
customer@example.comThe address may be correctly formatted, but syntax alone cannot establish whether the mailbox exists, accepts messages or is monitored by its owner.
2. MX Records Do Not Guarantee Delivery
Mail Exchanger (MX) records identify the mail servers responsible for receiving email for a domain. Finding MX records is an important signal that the domain has a configured mail-routing destination.
However, a domain can have MX records while individual mailboxes are missing, disabled, restricted or unable to receive new messages. MX checks are therefore a useful part of validation, not proof of deliverability.
3. SMTP Checks Are Not Definitive
Some email validation APIs connect to a recipient's mail server and attempt an SMTP conversation, sometimes including a RCPT TO command, to see how the server responds.
Unfortunately, many providers restrict or obscure mailbox-level verification to help prevent spam, abuse and email address harvesting. Responses can be affected by rate limits, temporary failures, anti-abuse policies and the provider's configuration.
A 250 response does not guarantee that a message will be delivered to an inbox. Likewise, a rejection does not always mean the address is invalid.
What Makes IEV Different?
IEV focuses on combining multiple validation and risk signals rather than treating one server response as the final answer.
The objective is practical: identify addresses that appear valid and lower risk, while flagging addresses associated with disposable services, known abuse, unsafe domains or other concerns.
1. Syntax Validation
IEV checks whether an email address follows acceptable syntax. This helps identify malformed addresses, missing components and formatting errors before they enter your application or customer database.
Syntax validation is the first step, not the final verdict.
2. MX Record Verification
IEV checks whether the domain has MX records indicating where its email should be received.
This helps distinguish domains with an apparent mail-routing configuration from those that lack the expected records. It still does not establish that the specific recipient's mailbox exists.
3. BIMI Certificate Checks
IEV also checks for a valid and current BIMI certificate when evaluating the relevant domain.
BIMI, VMC and CMC certificates relate to brand identity and logo verification in supported email environments. Their presence can provide an additional domain-level signal, but a certificate is not proof that an individual mailbox exists or that every message will be delivered.
IEV treats this as one factor within its broader assessment, not as a replacement for standard email validation.
4. Disposable Email Database Checks
Disposable email addresses can be useful for temporary registrations, but they may be unsuitable for businesses that need reliable, ongoing communication with customers.
IEV checks addresses against an up-to-date disposable email database to identify domains associated with temporary email services.
This helps businesses reduce disposable registrations, low-quality leads and contact records that may not be useful for long-term communication.
5. Blacklist Checks Against Known Abuse Sources
IEV checks against a database containing more than one million known spam and phishing email addresses or senders.
These checks help identify addresses associated with known abuse indicators. A match does not necessarily establish that the current owner is malicious, so blacklist findings should be interpreted in context.
This protection is an important part of IEV's risk assessment and cannot be disabled through the API.
6. Safe-Domain Assessment
An email address can be correctly formatted and hosted on a domain that is nevertheless associated with malicious activity or inappropriate content.
IEV assesses whether a domain is known for threats such as:
- Malware distribution.
- Phishing and deceptive activity.
- Other known unsafe or high-risk behaviour.
- NSFW content, according to the applicable classification data and settings.
These signals help applications decide whether an address is suitable for their particular use case.
NSFW Email Domains: Built-In Filtering
IEV can block email addresses associated with NSFW domains and classify them as invalid with a high risk level.
This is useful for businesses that want to maintain a professional customer database, protect enquiry forms and restrict registrations from domains that do not fit their service.
If your application needs to allow NSFW domains, you can use the following API parameter:
&nsfw=falseThis disables the NSFW blocking rule for the request. It does not disable the checks for malware, phishing, blacklisted senders or disposable email addresses. Those protections remain in place.
For the exact parameter format and supported response fields, refer to the IEV API documentation.
Can You Trust a Catch-All or SMTP Result?
Catch-all detection attempts to determine whether a mail server accepts messages addressed to recipients that may not exist. SMTP validation attempts to infer mailbox status from the server's response.
Both techniques have limitations. Some servers accept messages for many or all recipient addresses, while others deliberately provide ambiguous responses. Provider policies can also change over time.
As a result, a service that claims to determine catch-all status or mailbox existence with near-perfect certainty should be evaluated carefully. Such results may be estimates rather than confirmed facts.
IEV does not need to treat a potentially ambiguous SMTP response as definitive. It focuses on the signals it can assess and combines them to produce a more practical view of address quality and risk.
How IEV Assesses Validity and Risk
IEV combines the checks described above to assess whether an email address appears useful for communication and whether it presents known risk indicators.
For example, an address may have:
- Acceptable syntax.
- A domain with MX records.
- No match in the checked disposable email database.
- No match in the checked blacklist database.
- A domain that is not identified as unsafe by the available checks.
- Additional domain-level signals, such as BIMI certificate status.
When the available evidence supports it, IEV can return an assessment such as:
{
"valid": true,
"risk": "low"
}This is an illustrative example, not a guarantee of the exact response schema for every API request. Use the current API documentation for the actual response fields and possible values.
A low-risk result means the address passed the relevant checks and no disqualifying indicators were found. It does not guarantee that the mailbox exists, that the recipient will respond or that a message will reach the inbox.
Can You Report an Incorrectly Blocked Address or Domain?
Automated databases are not perfect. Domains change ownership, websites change purpose, and legitimate addresses can occasionally be associated with outdated or incorrect records.
If you believe an address or domain has been incorrectly blocked by IEV, contact the relevant team to report it for review:
- Email addresses:
ive#email@ilham.au - Domains:
ive#domain@ilham.au
Include the affected address or domain and explain why you believe the classification should be reviewed. Reporting an entry does not guarantee that it will be removed; the decision depends on the available evidence and applicable security requirements.
Why This Approach Is Useful for Businesses
For a business collecting customer enquiries, registrations or leads, the most useful question is not simply whether an SMTP server returned a particular code.
The more practical questions are:
- Is the address correctly formatted?
- Does the domain appear configured to receive email?
- Is the address associated with a disposable email service?
- Does the address or domain match known abuse indicators?
- Is the domain associated with malware, phishing or other unwanted content?
- What level of risk should the application assign to the address?
By evaluating multiple factors, IEV aims to help businesses make better-informed decisions about contact data, registrations and enquiry quality without pretending that uncertain mailbox checks are infallible.
For enquiry forms, IEV can be used alongside server-side input validation, spam prevention, rate limiting and other appropriate security controls. Email validation should be one layer of a broader strategy, not the only line of defence.
Frequently Asked Questions
Can IEV guarantee that an email address exists?
No. No combination of these checks can guarantee that a specific mailbox exists or will accept future messages. IEV assesses multiple signals to estimate address quality and risk.
Does a successful SMTP response guarantee delivery?
No. A 250 response may indicate that a server accepted a particular SMTP command, but it does not guarantee final delivery, inbox placement or that the recipient will read the message.
Why does IEV check BIMI certificates?
BIMI certificate information provides an additional domain-level signal related to verified brand identity. It does not prove that an individual mailbox exists and is only one part of the overall assessment.
Can I disable NSFW domain blocking?
Yes. Use the nsfw=false parameter as documented by IEV. Malware, phishing, blacklist and disposable-email protections remain enabled.
Can I disable blacklist and disposable email checks?
No. These checks are part of IEV's built-in protection and cannot be disabled through the API.
Does a low-risk result guarantee that an email is deliverable?
No. A low-risk result indicates that the address passed the applicable checks without disqualifying indicators. Actual delivery still depends on mailbox status, provider policies, sender reputation and other factors.
Choose a More Practical Approach to Email Validation
Email validation should reflect the realities of email infrastructure. SMTP responses can be ambiguous, catch-all behaviour can conceal mailbox status, and no single check can reliably predict every delivery outcome.
IEV takes a multi-factor approach, combining syntax validation, MX checks, BIMI certificate checks, disposable email detection, blacklist checks and domain safety assessment to help classify addresses by validity and risk.
Rather than promising certainty where certainty is not available, IEV focuses on providing useful signals that businesses can use to improve contact data quality and reduce avoidable risks.
Explore ILHAM Email Validation
Discover how IEV can help your application assess email addresses using multiple validation and risk signals.
Explore the IEV API