Skip to main content

Understanding the report

Example:

{
"email": "a.valid.email.account@gmail.com",
"l1": "PASSED",
"l1_explanation": "provided email address is syntactically correct",
"l1_score": 100,
"l2": "PASSED",
"l2_dkim": false,
"l2_dmarc": true,
"l2_dnssec": false,
"l2_explanation": "email domain name service settings are functional",
"l2_fcrdns_check": "PASSED",
"l2_fcrdns_detail": "11111",
"l2_score": 75,
"l2_spf": true,
"l3": "PASSED",
"l3_220_helo_correct": false,
"l3_explanation": "email server handshake successful",
"l3_rcpt_ack": 250,
"l3_score": 90,
"l3_tls": true,
"l4": "PASSED",
"l4_explanation": "no temporary email but it is a free email service account",
"l4_free_email": true,
"l4_score": 75,
"l4_temporary_email": false,
"l5": "PASSED",
"l5_explanation": "free email service account with no red flags detected",
"l5_score": 60,
"mail_servers": [
"5 gmail-smtp-in.l.google.com.",
"10 alt1.gmail-smtp-in.l.google.com.",
"20 alt2.gmail-smtp-in.l.google.com.",
"30 alt3.gmail-smtp-in.l.google.com.",
"40 alt4.gmail-smtp-in.l.google.com."
],
"requested_level": "l5_smell",
"result": "PASSED",
"score": 73
}

High Level Overview

The "result" field—either "PASSED" or "FAILED" —is likely the key detail you’ll want to check. We conduct an in-depth analysis of the email address, as you can see in the full report, and this field provides the overall conclusion: 👍 (PASSED) or 👎 (FAILED).

Given the complexity and nuances involved (evident in the report's details), we pair the PASSED/FAILED result with a "score" field to indicate our confidence in the outcome. Think of the score like a grade: 100/100 is perfect, and anything above 75 is highly reliable. Scores between 60 and 74 suggest a possible false positive or false negative (e.g., we might have marked it as "PASSED" when it should've been "FAILED", or vice versa). Scores below 60 indicate a "FAILED" result or an account with uncertain trustworthiness. The score reflects our confidence in the result—not the quality of our analysis—based on multiple factors evaluated during the process. We also include explanations at each verification step to help you understand the reasoning.

The "email" and "requested_level" fields simply echo the information you provided in your request.

Multi-staged verification

The verification process unfolds in five stages:

  • l1 syntax: Is the email address properly formatted and spelled?
  • l2 domain: how is the domain server configured?
  • l3 server: how does the email server respond?
  • l4 database: Is the email linked to a free or temporary email service?
  • l5 smell: does it 'feels' legitimate? We’ve trained an AI to assess this.

If a failure occurs at any stage, the process halts, and subsequent stages are not executed. Why? For example, it wouldn’t make sense to query an email server if the domain doesn't exist or lacks an email server configuration.

L1: Syntax

This stage involves a straightforward textual validation. We check that the email adheres to the expected format—such as including an "@" symbol, a domain with a dot, and similar requirements.

L2: DNS Specific fields

  • l2_dnssec: Returns true if the domain uses DNSSEC (Domain Name System Security Extensions),which provides cryptographically secure name services. More information here.
  • l2_dmarc: Returns true if the domain has DMARC records, DMARC stands for Domain-based Message Authentication, Reporting and Conformance. Read the full specification here.
  • l2_dkim: Returns true if the domain supports DKIM (DomainKeys Identified Mail), an email authentication method. More here.
  • l2_spf: Returns true if the domain has a SPF (Sender Policy Framework) configured to specify authorized mail servers. More information here.
  • l2_fcrdns_detail: Checks every MX (Mail Exchange) host for Forward-Confirmed Reverse DNS (FCRDNS). A value of 1 indicates the server is properly configured; 0 means it’s not. The numbers correspond to the server order listed in the mail_servers array. Read more here for further information.
  • l2_fcrdns_check: Returns PASSED if all reverse DNS entries for all MX servers are correctly configured.

L3: Server Handshake Specific fields

  • l3_transient_error: Returns true if the server recognizes the email address as valid but cannot process it at the moment. This may relate to l3_450_gray_listed and could indicate an anti-spam measure, though we couldn't fully confirm it.
  • l3_450_gray_listed: Returns true if the server responds with, "The email is fine, but we won’t accept it right now." This is a common anti-spam tactic that requires the sender to retry after a delay (e.g., a few minutes), deterring spammers who typically don’t bother. Read more here.
  • l3_tls: Returns true if the server offers TLS (Transport Layer Security) to encrypt the connection for email delivery. A server without TLS may be outdated, less secure, or associated with spamming/temporary accounts due to its lack of concern for confidentiality.
  • l3_220_helo_correct: Returns true if the mail server correctly reports its hostname. Spam servers often reuse the same server across multiple domains, so an incorrect hostname isn't mandatory but is a common red flag.
  • l3_rcpt_ack: Captures the server’s response when asked to accept a message for the provided email. Responses in the 2XX (success) or 4XX (temporary issue) range are generally fine. A 5XX (permanent error) response requires broader context, as it involves more nuance and should be assessed holistically.

L4: Database-Specific fields

  • l4_temporary_email: Set to true if the email originates from a temporary email service. Such emails are rejected during verification, as we deem them invalid due to their short lifespan (typically a few minutes).
  • l4_free_email: Set to true if the email is from a free email provider (e.g., Gmail, Yahoo), which may offer user anonymity and be used with any intent.

L5: AI Smell test

After gathering all available data from the email address, we input it into an AI system to assess its legitimacy. The AI excels at detecting subtle cues—such as threatening words or insults in foreign languages—effectively "smelling" whether something seems off or suspicious.

The AI performs a holistic analysis, evaluating not only the email address but also the entire report, including Domain Server configuration, Mail Server handshake, and additional factors.

Estimating your own certainty

You can use the score field as a gauge of confidence. For example, if the score is below 85, you might allow account creation but offer fewer free benefits, require an additional CAPTCHA, or prompt for more frequent email reconfirmation beyond initial registration.

For mailing lists, if sender reputation is a concern, consider filtering emails with a score below 85 to ensure higher quality.

Passing l3 with "l3_tls": true, clearing l4, and having a domain with l2_spf, l2_dmarc, and possibly l2_dnssec provides strong confidence in a well-maintained, likely trustworthy server.

"l3_tls": false

A server accepting unencrypted emails raises a significant red flag.

The result field indicates whether the domain’s email server will accept the email and if it's free of temporary or spam traits. However, other fields can help gauge the email''s reliability or trustworthiness further. For instance, @gmail.com lacks l2_dnssec and l2_dkim but is a well-known domain, while @proton.me (ProtonMail) supports most checks except l2_dkim.

On Completeness and Confidence

Without a full report (l5_smell), the score cannot reach 100, as it reflects the certainty of result based on completed tests. Skipping tests limits maximum confidence.

Finally

The API can server as a simple 👍YES/👎NO check via the result field or as a confidence gauge using the score field, depending on your needs.