A contact table and a location table can sit in the same warehouse, pass the same completeness checks, and still be wrong in very different proportions 12 months later. Location data ages slowly. A point of interest keeps its coordinates, and a postal boundary only moves when a municipality redraws it. Contact data ages on human timescales, and the email field ages fastest of all.
Most data quality programs measure the wrong thing here. Fill rate, format validity and uniqueness all pass on a record whose owner left the company 18 months ago. Nothing inside the table carries a signal. It lives outside, on a mail server that will answer the question if you ask.
Table of Contents
Decay rates, field by field
Start with the slowest one. The US Census Bureau’s American Community Survey 1-year estimates put the 2024 mover rate at 11.8 percent of the population, split between 8.9 percent who moved within the same state and 2.1 percent who moved to a different state. A residential address therefore carries roughly a 1 in 8 chance of being stale after a year. Business addresses move less, since companies relocate less often than their employees.
Job title runs on a different clock, and it is the one field that decays without anyone leaving. A promotion inside the same company invalidates it while the address, the phone and the email stay correct.
Phone sits in the middle and splits in two. A direct dial extension is tied to a desk and dies with the role. A mobile number survives the job change, since portability lets the person carry it across carriers and employers. A column mixing both holds two decay rates under one field name, inseparable without a line type flag.
Email carries the highest rate of the four, and no public series measures it directly. The closest proxy is the rate at which people leave a job, since a voluntary departure disables a work mailbox within weeks of the exit interview. On that basis a file of work addresses assembled two years ago and never rechecked has lost a substantial share of its reachable contacts, with nothing inside the record to show for it.
Why the email field leads
A mailbox can stop working overnight and leave no trace in any other column. Someone resigns on a Friday, IT disables the account on Monday, and the address starts returning 550 while the name, company, title and phone stay exactly as they were. No correction gets published anywhere, and the row keeps looking healthy on every profiling report.
The rest of the record degrades gradually. A job title drifts from Manager to Senior Manager and stays useful for segmentation. A postal address remains deliverable through mail forwarding for months after a move. An email address has no equivalent grace period. It resolves or it does not.
The volume of qualifying events is large. The BLS Job Openings and Labor Turnover Survey recorded a total separations rate of 3.3 percent of employment in December 2025, of which 2.0 percent were quits. Each separation is a candidate for a disabled mailbox, on the employer’s schedule rather than the data team’s refresh cycle.
Domain level events remove addresses in blocks. A company migrates off its old domain after a rebrand or acquisition, keeps the old MX records answering through a transition period, then drops them. Every address on that domain dies the same day, which shows up as a step in the failure curve rather than a smooth slope.
The completeness metric that never fires
Standard data quality dimensions cover completeness, validity, uniqueness, consistency and timeliness. A dead mailbox passes the first four: the field is populated, it matches the addr-spec grammar, it appears once, and it agrees with the domain sitting in the company column.
Accuracy is the dimension that fails, and the only one that cannot be computed from the table alone. Every other check reads the warehouse and compares it against itself. This one requires asking an external system whether the thing the row describes still exists.
The practical result is a record that scores well on every dashboard and reaches nobody. Downstream it inflates addressable audience counts and feeds hard bounces back into the sending domain’s reputation. A model trained on engagement data reads those rows as low engagement contacts rather than absent ones.
Controls that catch it, and where each one belongs
Four controls exist, and they differ by two orders of magnitude in cost, so their order matters more than which ones you adopt.
Syntax validation comes first and costs nothing beyond CPU. It parses the string against the addr-spec grammar and applies the length limits set out in RFC 5321, 64 octets for the local part and 255 for the domain. It runs inside the ingestion job, before the row gets written. A syntactically valid address proves only that the string could be an address.
Domain resolution comes second. A DNS query establishes whether the domain resolves at all, which catches expired registrations, dead subdomains and typo domains nobody registered. The cost is per domain rather than per record, so 500,000 contacts usually collapse to fewer than 40,000 distinct domains. Cache the answer and respect the TTL.
MX lookup follows, and it gets misread often. A domain publishing no MX record is not automatically undeliverable, because RFC 5321 has the sender fall back to the address record as an implicit MX. Treat a missing MX as a lower confidence signal rather than a rejection.
The SMTP probe is the only control that tests the mailbox itself. It opens a connection to the highest priority MX host, sends EHLO, then MAIL FROM with a null reverse path, then RCPT TO carrying the target address, reads the reply code and issues QUIT without ever sending DATA. A 250 means the server accepted that recipient. A 550 means, in the wording of RFC 5321 section 3.3, that the recipient is known not to be a deliverable address.
Three caveats decide how much weight the reply deserves. A catch-all domain accepts every recipient, so a 250 there says nothing about the specific mailbox. Greylisting returns a 4xx temporary code that has to be retried rather than recorded as a failure. Some servers defer recipient verification until the message body arrives, which RFC 5321 labels a subsequent failure, so a 250 at RCPT time can still bounce afterwards. VRFY was designed for exactly this question and is unusable in practice: the RFC says responses should be interpreted very carefully, if at all, and most operators disable the command.
Placement in the pipeline follows from cost. Syntax and normalization sit inline at write time. Domain and MX checks sit in the same job, served from a domain keyed cache. The SMTP probe belongs out of band, in a queue with rate limiting and a retry policy for 4xx codes, since it calls a system you do not control and one that throttles for volume. The cheapest control is the simplest one, running the field through an email tester tool before it enters the warehouse, which settles a single questionable address without building any of it.
Store the outcome as state rather than a boolean. A status column plus a checked-at timestamp lets each consumer set its own staleness window, and anything checked more than 90 days ago reads as unknown rather than valid, given how quickly the field turns over.
Unreachable records are storage risk with no offsetting value
Article 5(1)(c) of the GDPR requires personal data to be “adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed”. Article 5(1)(e) adds that it be “kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed”.
An unreachable contact record fails both tests. The purpose of storing a contact email is contacting the person, and once the mailbox is gone the row becomes personal data held past the point where it does any work.
The exposure is asymmetric. A dead address carries the same breach risk as a live one, since it still names a person and ties them to an employer, a title and a phone number. It carries the same storage cost, replication and subject access obligations, and returns nothing. Deleting verified dead records lowers storage cost and legal exposure at once, which few data quality actions manage.
Measure your own curve
Vendor averages describe someone else’s data. Pull a sample of 1,000 contact records, note the ingestion date of each, run the four controls, and plot the failure rate against record age. That curve is the decay rate for that source, and the only number that should set a re-verification schedule. Run it once a quarter, on the postal and title columns too, and the schedule maintains itself.
James is the head of marketing at Tamoco
