EMAIL VERIFICATION, EXPLAINED

Email verification glossary.

Clear, authoritative definitions of the protocols, status codes, and deliverability mechanisms governing modern email delivery. Built for cold outreach practitioners, lifecycle marketers, and infrastructure developers.

MAILCHECKUP / GLOSSARY↘
34 Authoritative Definitions Real-Time Search & Filter Interactive Term Deep-Dive Inspector RFC Standards & DNS Specifications
REFERENCE INDEX & PROTOCOL SPECIFICATIONS

Explore Deliverability & Verification Terminology

Search protocols, DNS records, and result codes, or select any term card below to launch the technical deep-dive inspector with RFC references and live code snippets.

RFC Compliant 2026 Deliverability Standards
Jump to:
PROTOCOLS & DNS RFC 5321

SMTP (Simple Mail Transfer Protocol)

The standard communication protocol used by mail servers across the internet to transmit and route electronic mail messages.

Why Cold Emailers & Senders Care

Verification tools simulate an SMTP connection (HELO, MAIL FROM, RCPT TO) to test mailbox existence without actually sending an email or alerting the recipient.

Verification Capability Boundary

SMTP confirms whether the server accepts the recipient at that moment; it cannot predict whether future messages will land in the primary inbox or spam folder.

PROTOCOL / SYNTAX EXAMPLE RFC 5321
HELO mailcheckup.net
MAIL FROM:<probe@mailcheckup.net>
RCPT TO:<target@company.com>
250 2.1.5 Recipient OK
RSET
QUIT
PROTOCOLS & DNS RFC 5321

SMTP (Simple Mail Transfer Protocol)

The standard communication protocol used by mail servers across the internet to transmit and route electronic mail messages.

Guide ↗
PROTOCOLS & DNS RFC 1035 / RFC 5321

MX Record (Mail Exchanger)

A DNS resource record that specifies the designated mail server responsible for accepting incoming email messages on behalf of a domain name, along with its priority preference.

Guide ↗
PROTOCOLS & DNS RFC 7208

SPF (Sender Policy Framework)

An email authentication standard that allows domain owners to publish a list of IP addresses and subnets authorized to send email on their domain's behalf using DNS TXT records.

Guide ↗
PROTOCOLS & DNS RFC 6376

DKIM (DomainKeys Identified Mail)

An email authentication technique that attaches a cryptographic digital signature to the message header, enabling the receiving server to verify that the email originated from the domain and was not altered in transit.

Guide ↗
PROTOCOLS & DNS RFC 7489

DMARC (Domain-based Message Authentication)

A policy protocol built on top of SPF and DKIM that tells receiving mail servers how to treat messages that fail authentication checks (none, quarantine, or reject) and specifies reporting addresses.

Guide ↗
PROTOCOLS & DNS RFC 1912

PTR Record & Reverse DNS (rDNS)

A DNS record that maps an IP address back to its associated domain name (the exact inverse of an A record). Forward-confirmed reverse DNS (FCrDNS) ensures both match.

Guide ↗
PROTOCOLS & DNS RFC 3207

STARTTLS (Opportunistic TLS)

An SMTP command extension that upgrades an existing plaintext communication channel into an encrypted TLS connection without changing ports.

Guide ↗
PROTOCOLS & DNS RFC 5322 / RFC 5321

RFC 5322 (Internet Message Format)

The formal Internet Engineering Task Force (IETF) specification defining the exact syntax, character encoding, and structure of email addresses and headers.

Guide ↗
PROTOCOLS & DNS RFC 5782

DNSBL / RBL (DNS Blackhole List)

A real-time database queried via DNS containing IP addresses and domain names known to originate unsolicited commercial email (spam) or malware.

Guide ↗
VERIFICATION OUTCOMES RFC 5321 §4.1.1.4

Deliverable (Valid / 250 OK)

A verification outcome indicating that the recipient server verified the local mailbox exists and returned an explicit 250 OK status during the SMTP handshake.

Guide ↗
VERIFICATION OUTCOMES RFC 5321 §4.2.1

Undeliverable (Hard Bounce / 550)

A permanent failure outcome where the recipient mail server explicitly rejects the mailbox as non-existent (e.g., 550 5.1.1 User unknown) or the domain lacks DNS records.

Guide ↗
VERIFICATION OUTCOMES RFC 5321

Catch-All (Accept-All Domain)

A mail server configuration where the domain accepts incoming email sent to any local mailbox prefix unconditionally, preventing outside servers from discovering whether specific mailboxes exist.

Guide ↗
VERIFICATION OUTCOMES Community Standard

Disposable / Burner Email

A temporary, throwaway mailbox provided by services like Mailinator, Guerrilla Mail, or TempMail, designed to receive a single verification message before expiring.

Guide ↗
VERIFICATION OUTCOMES MailCheckup Protocol Guarantee

Unknown Result ($0 Free)

An inconclusive verification outcome where the recipient mail server deferred the connection, timed out, or blocked probes with anti-spam firewalls, preventing definitive classification.

Guide ↗
VERIFICATION OUTCOMES RFC 6647

Greylisting (451 / 421 Deferral)

An anti-spam defense mechanism where a receiving MTA temporarily rejects connections from unfamiliar senders with a 4xx temporary error, expecting legitimate MTAs to retry later.

Guide ↗
VERIFICATION OUTCOMES RFC 5321 §4.2.2

Mailbox Full (552 Storage Limit)

An outcome where the mailbox exists but cannot accept incoming mail because the user's storage quota has been completely exhausted (returning SMTP 552 or 452).

Guide ↗
VERIFICATION OUTCOMES RFC 2142

Role-Based Account

An email address tied to a corporate function, team, or department rather than a single individual (e.g., info@, support@, sales@, billing@, admin@).

Guide ↗
VERIFICATION OUTCOMES Industry Security Standard

Spam Trap (Honeypot)

A decoy email address operated by blocklist operators and ISPs (e.g., Spamhaus) designed to catch unsolicited senders and scraper bots. Traps never opt-in to email.

Guide ↗
DELIVERABILITY & REPUTATION Industry Standard

Sender Reputation & IP Warming

The algorithmic score assigned to a sending IP and domain by mailbox providers based on bounce rates, spam complaints, engagement metrics, and authentication records.

Guide ↗
DELIVERABILITY & REPUTATION Industry Standard

Inbox Placement Rate

The percentage of successfully accepted emails that land in the primary inbox of the recipient, as opposed to the spam/junk folder or promotions tab.

Guide ↗
DELIVERABILITY & REPUTATION RFC 3463

Hard Bounce vs Soft Bounce

Hard bounces (5xx) represent permanent failures (non-existent address/domain); soft bounces (4xx) represent temporary delivery failures (mailbox full, server down, rate limit).

Guide ↗
DELIVERABILITY & REPUTATION Industry Deliverability Mandate

Google & Yahoo 2024+ Mandates

Mandatory technical requirements enforced by Google and Yahoo since February 2024 for senders transmitting over 5,000 emails/day: mandatory SPF/DKIM/DMARC, one-click unsubscribe, and spam complaint rate below 0.3%.

Guide ↗
DELIVERABILITY & REPUTATION Google / Yahoo Enforcement Standard

Spam Complaint Threshold (<0.3%)

The ratio of recipients who flag an email as spam relative to total delivered messages. Google enforces a strict ceiling of 0.3% (with 0.1% recommended target).

Guide ↗
DELIVERABILITY & REPUTATION RFC 5321

Domain Throttling & Rate Limiting

When receiving mail servers artificially delay or defer message acceptance (using 421 Too many connections or 451 rate limits) due to excessive volume spikes or poor list quality.

Guide ↗
DELIVERABILITY & REPUTATION Industry Advisory

Email Warmup Tool / Pool Risks

Automated peer-to-peer networks where secondary accounts send canned emails to one another to artificially boost reputation metrics.

Guide ↗
DELIVERABILITY & REPUTATION Cold Outreach Best Practice

Secondary Domain Isolation

The practice of hosting outbound sales cadences on dedicated variations of your primary corporate domain (e.g., getcompany.com instead of company.com) to insulate corporate email.

Guide ↗
ARCHITECTURE & HYGIENE RFC 4180

CSV Schema Preservation

The principle of verifying uploaded contact spreadsheets while keeping all custom CRM columns, lead IDs, tags, and UTF-8 formatting strictly intact in the export file.

Guide ↗
ARCHITECTURE & HYGIENE CAN-SPAM / GDPR Standard

Suppression List

A centralized negative database of email addresses that must never receive outreach due to past unsubscribe requests, spam complaints, or permanent bounce history.

Guide ↗
ARCHITECTURE & HYGIENE Resilient Systems Architecture

Fail-Open Verification Pattern

An architectural pattern where a signup or checkout form allows user registration to proceed if the third-party verification API times out or returns an unknown status.

Guide ↗
ARCHITECTURE & HYGIENE RFC 2104

Webhook Event Notification (HMAC-SHA256)

An automated HTTP POST callback mechanism that notifies client servers when bulk verification lists complete, cryptographically signed with HMAC-SHA256 for integrity.

Guide ↗
ARCHITECTURE & HYGIENE Anthropic Open Protocol

MCP (Model Context Protocol)

An open standard enabling AI assistants (like Claude, Cursor, and ChatGPT) to securely connect to external tools and verification APIs over streamable JSON-RPC 2.0.

Guide ↗
ARCHITECTURE & HYGIENE Computer Science Data Structure

Radix Trie / Blocklist Lookup

A space-optimized compressed prefix tree used to perform sub-millisecond lookups across tens of thousands of disposable and blacklisted domain names in memory.

Guide ↗
ARCHITECTURE & HYGIENE Industry Permission Standard

Single Opt-In vs Double Opt-In

Single opt-in adds subscribers immediately upon form submission; double opt-in requires the subscriber to click a confirmation link sent to their inbox before activation.

Guide ↗
ARCHITECTURE & HYGIENE EU Regulation 2016/679

GDPR Article 28 Compliance

The European data privacy framework establishing that MailCheckup acts strictly as a Data Processor on behalf of the customer (the Data Controller), with zero contact resale.

Guide ↗

Why deliverability vocabulary dictates sending decisions

In high-volume email operations, confusing technical terms leads directly to damaged domain reputation, burned secondary accounts, and wasted campaign spend. When marketing teams conflate "delivery rate" with "inbox placement", they celebrate 99% delivery while their messages rot in recipient spam folders.

Similarly, when outreach tools label a catch-all server as "verified valid", senders suffer preventable hard bounces that trigger automated Google and Yahoo domain throttling. Understanding the precise RFC definitions behind email verification allows teams to architect resilient cold email pipelines and protect sender scores.

The 6 stages of email verification and delivery

Modern email verification is a progressive diagnostic hierarchy. Each check builds upon the previous stage:

Verification StageCore Protocol / MechanismWhat It EvaluatesFailure Consequence
1. Syntax & GrammarRFC 5322 / RFC 5321Local part, @ symbol, valid domain characters.Immediate client-side or mailer rejection.
2. DNS & RoutingDNS MX, A, AAAA RecordsRecipient domain existence & active mail servers.550 Unrouteable domain / host not found.
3. Mailbox ExistenceSMTP Handshake (HELO, MAIL FROM, RCPT TO)Whether recipient inbox exists & accepts mail.550 User unknown / hard bounce.
4. Domain Integrity6-Hour Disposable Domain Radix TrieWhether domain is a burner or temporary host.Delayed 550 bounces & trial abuse.
5. Infrastructure RiskCatch-All & Full Mailbox DetectionServer policy heuristics & inbox storage limits.Uncertainty or 552 storage bounces.
6. Delivery & PlacementSPF, DKIM, DMARC, ReputationAuthentication alignment & inbox placement.Spam folder placement or ISP block.

Core email authentication standards at a glance

Authentication records prove to recipient servers that an email truly originated from your authorized infrastructure rather than a malicious spoofing actor:

Authentication ProtocolRFC StandardPrimary FunctionGoogle/Yahoo 2024 Requirement
SPF (Sender Policy Framework)RFC 7208Authorizes sending IP addresses via DNS TXT.Mandatory for all senders.
DKIM (DomainKeys Identified Mail)RFC 6376Cryptographically signs email headers & body.Mandatory with 1024-bit or 2048-bit keys.
DMARCRFC 7489Enforces policy on SPF/DKIM alignment failures.Mandatory (minimum p=none policy).
PTR & Reverse DNS (rDNS)RFC 1912Validates EHLO hostname matches sending IP.Mandatory forward-confirmed rDNS.

How MailCheckup categorizes verification outcomes

Every address uploaded to MailCheckup is categorized according to strict RFC evidentiary principles:

Outcome CategorySMTP / Result CodeCredit Billing RuleRecommended Senders Action
Deliverable (Valid)250 OK / Mailbox Exists1 Credit ConsumedSafe for primary cold outreach cadences.
Undeliverable (Dead)550 User Unknown / No MX1 Credit ConsumedPurge immediately; prevent hard bounces.
Catch-All (Accept-All)Server Accepts All Recipient Addresses1 Credit ConsumedIsolate into warmed secondary sequences.
Disposable (Burner)Domain in 97k+ 6-Hr Blocklist1 Credit ConsumedFilter from sales pipelines & free trials.
Role-Based (Functional)info@, sales@, billing@, admin@1 Credit ConsumedExclude from personalized 1-on-1 sales outreach.
Mailbox Full (Quota)552 / 452 Storage Limit Exceeded1 Credit ConsumedSuppress temporarily; indicates dormant account.
Unknown (Inconclusive)Timeout, Greylisting, Firewall Deferral$0 Free (Hold Released)Keep in database; retry after several hours.

Frequently asked questions (Email verification terminology)

What is the technical difference between email verification and email validation?

While often used interchangeably in marketing, email validation strictly refers to checking address formatting against syntax standards (such as RFC 5322 grammar and valid domain characters). Email verification goes several steps further by performing live network queries: resolving DNS MX records, connecting to the mail server via an SMTP handshake, testing the mailbox with RCPT TO, and querying disposable blocklists. Validation confirms the address is shaped correctly; verification confirms the mailbox actually exists to receive mail.

Why is email deliverability different from email delivery rate?

Delivery rate measures the percentage of sent emails that did not bounce (meaning the recipient mail server returned a 250 OK acceptance code). Deliverability (or inbox placement) measures where those accepted emails actually land—in the primary inbox, secondary tab, or spam/junk folder. An outreach campaign can have a 99% delivery rate while suffering a 15% inbox placement rate if sending domains lack proper authentication or trigger spam filters.

Why does MailCheckup distinguish catch-all domains from confirmed deliverable mailboxes?

A catch-all mail server is configured to return 250 OK for any email address at that domain, regardless of whether a real mailbox exists. If a verification service marks catch-all addresses as "valid," cold emailers will experience unexpected hard bounces when recipient postmasters generate delayed non-delivery reports (NDRs). Separating catch-all results prevents false confidence and allows senders to isolate those contacts into secondary sequences.

Why are 'unknown' verification results free ($0) on MailCheckup?

An unknown result occurs when the recipient mail server cannot be evaluated definitively due to temporary greylisting (451/421 deferrals), connection timeouts, or anti-spam firewalls. Because MailCheckup believes in mathematical honesty over guessing, we treat unknown as inconclusive rather than invalid. We never charge credits for inconclusive checks; any initial credit hold is released automatically.

What is forward-confirmed reverse DNS (FCrDNS) and why do mailbox providers require it?

Forward-confirmed reverse DNS occurs when an IP address resolves to a domain name via a PTR record, and that domain name in turn resolves back to the exact same IP address via an A record. Mailbox providers like Google, Microsoft, and Yahoo use FCrDNS as a baseline filter to confirm that sending mail servers are legitimate infrastructure rather than hijacked consumer computers or botnets.

How do Google and Yahoo enforce the 0.3% spam complaint rate threshold?

Google and Yahoo calculate spam complaint rates using Google Postmaster Tools and recipient feedback loops (FBL). If more than 3 out of every 1,000 delivered messages are marked as spam by recipients (0.3%), the sender domain enters a penalty state where subsequent messages are automatically throttled or routed directly to the spam folder. Maintaining clean, verified lists is the primary defense against reaching this threshold.