Verification is several different checks — syntax, domain, MX, mailbox and suppression — and they can legitimately disagree. These notes cover catch-all domains, role addresses, re-verifying an old list, global hard-bounce suppression, deduplication across mailboxes, and the DNS edge cases (Null MX, NXDOMAIN, SERVFAIL) a verifier should never collapse into one result.
New to this? Start with the pillar guide: Cold email deliverability: the stack that decides inbox placement
Verification is a stack of filters, not one yes/no lookup; each layer removes a different failure mode before the mailbox pays the cost.
Read field note →
A catch-all server can accept probes for many addresses, so verification confidence is lower even when the domain accepts mail.
Read field note →
Addresses like info@, sales@ or team@ can route to multiple people, ticket systems or stricter filters, so they behave differently from a named mailbox.
Read field note →
List age matters because companies close domains, people leave roles and previously valid mailboxes disappear.
Read field note →
A permanent delivery failure belongs to the recipient state, not merely to the mailbox that happened to send the first attempt.
Read field note →
Deduplication needs a stable recipient key and campaign state; spreadsheet row uniqueness is not enough when data enters through multiple sources.
Read field note →SMTP reply classes describe temporary versus permanent outcomes. A suppression engine should not erase a prospect merely because any delivery attempt failed.
Read field note →SMTP historically allows fallback to the domain’s address record when no MX exists, while a Null MX explicitly signals that a domain accepts no email. “No MX” is therefore not identical to “cannot receive.”
Read field note →NXDOMAIN means the queried domain name does not exist in DNS. A domain that exists but lacks MX records is a different condition and can still have SMTP fallback behavior.
Read field note →Mailbox verification can receive temporary SMTP responses because of greylisting, rate controls, recipient-server load, or policy. A 4xx probe result is uncertainty, not proof that the mailbox does not exist.
Read field note →Mailbox-full conditions are often reported as temporary 4.2.2-style responses, but provider wording and persistence vary. Treat the first event as temporary unless the receiver explicitly returns a permanent failure.
Read field note →A domain can explicitly say it accepts no mail with a null MX, omit MX and rely on SMTP fallback behavior, or not exist at all. Those states have different meanings.
Read field note →A resolver failure is not proof that a recipient domain does not exist. Verification systems need a temporary DNS state that can be retried without poisoning suppression data.
Read field note →SMTP verification sees the behavior of the address you connect to, not every downstream hop that a forwarder may use after acceptance. Treat forwarding as a limit on certainty.
Read field note →A temporary-email provider can publish valid DNS and accept mail normally. Classifying it as disposable may be useful for your lead policy, but it should not be mislabeled as SMTP invalidity.
Read field note →