Semrush Email Verifier: Lists Cleansing & Deliverability Guide

Phase A: Syntax Validation and RFC Compliance Standards

Before any network resources are utilized, the verifier analyzes the structure of each email address. This check validates that the address conforms to the exact syntactic requirements set forth by the Internet Engineering Task Force (IETF) in RFC 5321 and RFC 5322.

An email address is parsed into two distinct parts separated by an "@" character: the local-part (representing the user mailbox prefix) and the domain-part (representing the destination server). The syntax check applies the following rules:

• Length Constraints: The local-part is strictly limited to 64 octets (bytes/characters), while the domain-part must not exceed 255 octets. The total combined email length cannot exceed 254 characters.
• Character Restrictions: The local-part may consist of alphanumeric characters (a-z, A-Z, 0-9) and specific special characters: ! # $ % & ' * + - / = ? ^ _ ` { | } ~. However, periods (.) cannot appear consecutively (e.g., john..doe@domain.com is invalid), and the local-part cannot begin or end with a period.
• Quoted Strings: Special characters (including spaces or commas) are only allowed if the local-part is enclosed in double quotes (e.g., "john.doe,jr"@domain.com).
• Domain Validation: The domain-part must comply with standard DNS naming conventions, featuring labels separated by dots, each label between 1 and 63 characters long, consisting only of letters, digits, and hyphens. IP literals (e.g., user@[192.168.1.100]) are technically valid under RFC standards but are often marked as risky by modern verifiers.

While simple applications rely on basic regular expressions, true enterprise-grade validation requires a complete syntax parser. A simple regex often fails to catch advanced edge cases (like escape characters within quoted strings) or incorrectly flags valid, complex addresses.

Phase B: Domain Check and DNS Record Queries

If the email structure is syntactically sound, the verifier moves to the DNS lookup phase. This step determines if the target domain is active, holds valid routing records, and can accept mail traffic.

The verifier sends a query to domain name servers requesting the MX (Mail Exchange) records of the domain-part. The MX record specifies the hostnames of the mail servers designated to process mail for that domain, along with their priority weights (where lower numerical values represent higher-priority servers).

If the domain has no MX records, RFC 5321 rules that the verifier must fall back to querying the domain's A record (or AAAA record for IPv6) to see if a web server is configured to accept direct email relays. If both MX and A record queries return negative results (NXDOMAIN error), the domain does not exist, and the email address is flagged as Undeliverable.

Phase C: The SMTP Handshake and Mailbox Querying

The most critical and technically complex phase is the SMTP (Simple Mail Transfer Protocol) handshake. During this phase, the verifier establishes a direct connection to the destination mail transfer agent (MTA) via TCP Port 25 (the standard SMTP port for routing).

Rather than sending a message, the verifier initiates an interactive dialogue with the server, stepping through the command sequence up to the point of recipient validation, and then terminates the session. The dialogue proceeds as follows:

If the mailbox is invalid or suspended, the server will reply to the RCPT TO command with an SMTP error code, typically 550 User Unknown or 550 5.1.1 Mailbox Unavailable.

Handling Server Protections: Mail servers utilize several defense mechanisms to block verification probes. The two most common are Greylisting and Rate Limiting. Greylisting servers return a temporary error code (such as 450 4.2.0 Recipient address rejected: Try again later) to any unfamiliar sender. High-performance verifiers parse these 4xx codes, close the socket, wait a predetermined duration (between 5 and 15 minutes), and execute a retry. Rate limiting occurs when a server receives too many queries from a single IP address. To prevent blocking, verifiers distribute queries across a broad proxy pool and inject delays between SMTP handshakes.

Phase D: Catch-All and Spam Trap Identification

Even if an email address returns a positive 250 OK response, it may still be dangerous or ineffective for cold outreach.

• Catch-All (Accept-All) Identification:Many corporations configure their mail servers to receive all messages sent to their domain, regardless of whether the prefix exists. If an email is sent to a typo, like nleee@domain.com instead of neele@domain.com, the catch-all server accepts it and routes it to a generic admin inbox. Standard SMTP checks will return a 250 OK for any prefix. Verifiers identify this by submitting a connection request for a randomized, non-existent mailbox prefix (e.g., zqyxx99812@domain.com). If the server responds with a 250 OK, the domain is flagged as Catch-All. Catch-all leads to silent delivery failures, as security systems frequently delete unrecognized emails before they reach any recipient's screen.
• Spam Trap Detection:Spam traps are inactive, hidden, or recycled email addresses managed by ISPs and security consortiums (such as Spamhaus or Project Honey Pot) to identify and catch spam networks:
  • Pristine Traps: Addresses embedded silently in public website HTML source code (honeypots). Because they have never subscribed to a list, any outbound email to a pristine trap is proof that the sender has scraped data, triggering immediate IP and domain blacklisting.
  • Recycled Traps: Deactivated corporate mailboxes re-enabled by ISPs after months of inactivity. Emailing a recycled trap signals poor database maintenance and list hygiene, causing a drop in sender score metrics.
• Role-Based Filtering:Standard distribution groups (e.g., info@, sales@, admin@, hr@, billing@) are flagged. These addresses are accessed by multiple users, yielding high unsubscribe and spam complaint rates.

Hard Bounces vs. Soft Bounces

Bounces are categorized into two classes based on their root cause and the SMTP response codes returned by the receiving server:

• Hard Bounces (Permanent Failures - 5xx Codes): Occur when the destination server declares that the recipient does not exist or the domain is dead. The server replies with a code like 550 5.1.1 User Unknown. Once a hard bounce occurs, the email address must be removed from your database immediately. Continuing to email hard-bouncing addresses will damage your sender reputation.
• Soft Bounces (Temporary Failures - 4xx Codes): Occur when the server cannot deliver the email immediately, but the issue may be resolved later. Examples include a full recipient inbox, connection timeouts, or rate limits. The server replies with a code like 452 4.2.2 Mailbox full. If a soft bounce persists over several attempts, it should be treated as a hard bounce and removed.

IP Reputation vs. Domain Reputation

Email filters use two main systems to assess your trustworthiness as a sender:

IP Reputation:This is tied to the physical IP address of the server dispatching your emails. If you are using a shared IP on a marketing platform, your IP reputation is shared with other senders. If one sender sends high-bounce lists, the IP's reputation drops, affecting all senders on that IP.

Domain Reputation: This is tied directly to your domain name (e.g., yourcompany.com). It acts as a portable reputation score that follows you if you switch email service providers or IP addresses. ISPs keep a log of your domain's historical bounce-to-send ratio. A low domain reputation will cause your emails to be routed to the spam folder, regardless of your sending platform.

Deliverability Statistics and ISP Suspension Thresholds

To protect their users, ISPs establish strict thresholds for incoming mail. If your bounce rates exceed these benchmarks, your emails may face automatic filtering or blocklisting:

• Bounce Rate Under 1%: Optimal range. Indicates excellent database hygiene, helping ensure high inbox placement.
• Bounce Rate of 2%: The warning threshold. ISPs may begin greylisting or rate-limiting your domain, and delivery rates can decline.
• Bounce Rate Exceeding 5%: High-risk level. ESPs (such as Google Workspace or Outlook) may automatically suspend your sending account to protect their IP reputation, and your emails will be routed to the spam folder.

Blacklist Recovery: If your domain lands on a public blacklist (like Spamhaus, Barracuda, or Spamcop) due to high bounces or spam trap hits, you must pause all outreach immediately. You must resolve your list issues, submit a formal request for removal (delisting), and verify that SPF, DKIM, and DMARC records are configured correctly.