The Outreach-Ready Contact Standard: When a Record Is Safe to Send

Deciding whether one named contact is safe to enter an outbound sequence is a pass/fail judgement, and most teams make it by feel. This standard is for founders selling their own product, account executives, SDR leads, and RevOps owners who grade rows before they hit a sequence. It gives you a fixed set of criteria - identity, role currency, deliverability, reachability, and lawful basis - stated so that two people scoring the same record reach the same verdict.

Other standards in this library cover the account brief a rep needs before first touch, the buyer-readiness signals in one person's footprint, and the operations-level lawful-send framework for whole lists. None of them define done for a single person's row. This one does.

What "outreach-ready" means for one record

An outreach-ready record is one that passes, in a single documented pass, four independent tests: the person is who the record says (identity), they still hold the role now (currency), the email is deliverable (deliverability), and there is a second way to reach them if the first fails (reachability), all stamped with a last-checked date inside cadence and cleared through a separate lawful-basis gate.

The point of writing it this way is that "ready" stops being a vibe and becomes a verdict two graders can reproduce. The most common mistake is collapsing all four tests into one - usually deliverability - because that is the check a tool runs for you. But a deliverable email tells you almost nothing about whether the role is current.

The email is the last field to die, so it hides the death of every field around it.

Fields decay independently. In the Biznology/InsideView study, 65.8% of records changed titles or job functions within twelve months and 42.9% changed phone numbers, while the email address itself decayed at roughly 3.6% a month. The inbox lingers after the person has left. That is why deliverability, on its own, is a trap: it is the field most likely to still be green when everything else has gone red.

Why records decay, and how fast each field goes

Contact data does not fail all at once; each field has its own half-life, and the fast fields fail first. There is no single agreed decay rate - published figures span a wide band from about 22.5% a year for a blended record up to more than 70% a year in the InsideView study - but the ordering is consistent everywhere: titles and phones go before emails.

The most-cited baseline is MarketingSherpa's measurement of 2.1% a month, which annualizes to about 22.5% for a whole record. Field-level rates run higher because a record is only as fresh as its stalest field. Roughly 30% of professionals change jobs every year, and each move invalidates a title, often a phone, and eventually an email across every database holding that person.

Read this table as a set of per-field pass windows. Because the title decays fastest, role currency is the check most likely to fail on a record that "looks fine," and it is the check a deliverability-first workflow never runs. Do not average these into one number; grade each field against its own rate.

The deliverability check: what each stage proves

Email verification is a fixed five-stage pipeline, and each stage proves one narrow thing. Running only the first stage clears format but leaves up to 30% of addresses bad; running the full pipeline catches 95 to 99% of bad addresses. Knowing what each stage proves - and what it fails to prove - is what lets you assign a defensible verdict instead of a hopeful one.

Syntax proves the address is well-formed and nothing more. DNS and MX prove the domain can receive mail. The SMTP handshake is meant to confirm the mailbox exists, but it is the stage that lies most often. The classification stage is where a binary result must become a tri-state one.

Two limits govern how much you can trust the SMTP result. First, catch-all domains accept any incoming address regardless of whether the mailbox exists, so the handshake returns a 250 accept even for an address you invented. Send to a fake name at a catch-all domain and it passes. Second, Gmail and most modern providers now accept SMTP probes for any address and reject undeliverable mail later, at the message level, rather than at the handshake. So "accepted" is not the same as "deliverable" on the two providers most of your targets use.

The output of the deliverability check is therefore never a binary. It is one of three states: valid (SMTP confirmed on a normal domain), risky (catch-all, greylisted, deferred, or a modern provider that will not commit), or invalid (syntax, DNS, MX, or a clean SMTP rejection). Route each state differently. A risky record is not ready, but it is not dead either.

The record schema every gradeable contact carries

A record is gradeable only if it carries the fields the verdict is built from, including the ones that prove the verdict is still current. No public standard enumerates this set, so this is the schema this document defines: company, name, role or department, email, a secondary channel, the verification result, the data source, a last-checked date, and a ready flag.

The two fields practitioners most often omit are the ones that make the standard reproducible. The verification result must be tri-state, not a checkbox, so a catch-all does not masquerade as valid. And the last-checked date must be present, because a pass verdict has a half-life. At 2.1% blended monthly decay, a record graded 90 days ago is measurably wrong, so a ready flag with no timestamp is worthless.

Log the verification date in its own column, separate from the record's create date. The practical rule that follows: if a list is not used within 30 days of that date, reverify before send. The timestamp is not metadata; it is the field that decides whether the ready flag still means anything.

Finding records that already carry the fields you need to grade - a current role, a resolvable identity, and a listed direct line - saves the pass that would otherwise start from nothing. This is where a search that returns structured, current people rather than a raw list of emails does real work.

I built Refolk so you can ask for people the way you would describe them to a colleague and get current, resolvable profiles back, which turns the identity and reachability tests from research into confirmation.

The pass procedure, step by step

Run the tests in an order that fails cheap checks first and gates the expensive human judgement last. Sources disagree on whether identity or deliverability comes first: deliverability-led vendor guides start at the email, RevOps guides start at identity. I put identity first because a deliverable email on the wrong person is the worst kind of pass, and confirming identity costs a minute.

Steps three through five are automated and take seconds. Steps one, two, six, and seven are where human or policy judgement lives, and they are the steps a tool cannot do for you. The lawful-basis gate is a one-time job per source rather than per record: once you have documented why a source gives you a basis to send, every record from that source inherits it, but every record must still be checked against the suppression list.

How this goes wrong: the false passes to catch

Most bad sends come not from records that fail cleanly but from records that pass falsely, where one green test hides a red one. These are the seven failure modes to design the gate against, each with the check that catches it.

• Catch-all treated as valid. The 250 handshake marks a fake mailbox valid. Check: flag any catch-all domain as risky, isolate it, and test at low volume. Do not auto-pass and do not auto-delete, since both are common errors.
• Fresh email, stale role. The email is still deliverable so the record passes, but the person left. Check: require a role last-checked date inside the pass window, independent of the email result.
• Syntax-only screen mistaken for verification. Format clears 70 to 90%, leaving up to 30% bad. Check: confirm the pipeline ran MX, SMTP, and risk flags, not just format.
• Verified once, sent months later. Decay is continuous, so a 90-day-old valid flag is not valid. Check: reject any ready = true whose timestamp predates cadence, and re-verify within 24 to 48 hours of send.
• Accuracy confused with lawfulness. A clean, deliverable record with no documented lawful basis, or an opt-out flag, passes the data gate but fails GDPR. Check: run a separate lawful-basis and suppression gate before ready = true.
• SMTP probe over-trusted on Gmail and Outlook. Modern providers accept probes and reject later, so accepted is not deliverable. Check: weight risk flags and engagement history, not the handshake alone.
• Bounce alert set too late. By the time visible bounces hit 2%, reputation is already hit. Check: alert at 1.5 to 1.8% and pull unverified segments.

The bottom-right quadrant is the whole reason this standard exists. A deliverability-only gate cannot tell it apart from the top-right, because both show a green email. Only an independent role-currency check with its own timestamp separates them.

Cadence, bounce thresholds, and the geography that changes the gate

A pass is not permanent, so cadence is the load-bearing rule, and the number that governs cadence is the bounce rate your sending reputation can absorb. Keep hard bounces below 2%: above that, most providers restrict sending, and above 5% you risk lasting reputation damage. Gmail's bulk-sender rules are stricter still, expecting spam complaint rates under 0.30% and treating persistent hard bounces above 2% as grounds for deferral and domain-level blocking for senders of more than 5,000 messages a day.

Segment records by how recently they engaged and verify accordingly:

Most teams do far less than this. In one industry report, 69.6% of senders verify monthly or less frequently and 7.4% never verify at all. That is the differentiator: a fixed pre-send re-verification gate materially separates you from most of the field rather than just meeting a baseline.

Geography changes how much weight the lawful-basis gate carries. In Refolk's index of professional profiles, the United States holds 22,595 current SDR profiles against 3,371 in the United Kingdom, a roughly 6.7x gap. Your reader base skews heavily US, but the smaller UK and EU slice sits under stricter accuracy-plus-consent rules, and Germany and Austria are effectively consent-based for B2B cold email.

GDPR splits the two obligations that a single "pass" tends to blur. Article 5(1)(d) is the accuracy principle: personal data must be accurate and, where necessary, kept up to date, with inaccurate data erased or rectified without delay. The UK regulator reads "inaccurate" broadly - data that creates a false impression fails even if no single fact is technically wrong. But accuracy is not lawfulness. Article 5(1)(a) and Article 6 require a documented lawful basis, usually legitimate interest for B2B outreach, and that basis is a separate check. Verifying a record does not grant a right to send it, and the ceiling for getting it wrong is 20 million euros or 4% of global annual turnover.

Adopt it as policy: the pre-send checklist

Turn the standard into a gate your team runs the same way every time by making the ready flag conditional on every box below. Paste this into your CRM as a required-fields rule or into your sequence-entry checklist.

Store the rubric so two graders apply it identically. The template below is the scoring shape: three tri-state states per field feeding one flag.

identity:       [ pass | fail ]        # one current employer, name, role consistent
role_currency:  [ pass | fail ]        # last_checked_role date inside pass window
email:          [ valid | risky | invalid ]   # full pipeline; catch-all = risky
reachability:   [ pass | fail ]        # >=1 secondary channel present
lawful_basis:   [ documented | missing ]  # basis recorded AND not suppressed
last_checked:   YYYY-MM-DD             # reject if predates cadence
--------------------------------------------------
ready = true  ONLY IF:
  identity=pass AND role_currency=pass AND email=valid
  AND reachability=pass AND lawful_basis=documented
  AND last_checked within cadence

Keeping the standard current

Two things in this standard have a half-life of their own: the decay rates and the deliverability mechanics. The decay figures here are published benchmarks, not measurements of your database. The honest move is to measure your own: track what fraction of your records bounce or reach a departed contact each quarter, and set your pass windows against your observed rate rather than the industry band. If your titles turn over faster than 65.8% a year in a high-churn segment, shorten the window there.

The deliverability mechanics shift as providers change how they answer probes. The SMTP handshake is already unreliable on Gmail and Outlook, and that trend runs one way. Re-check quarterly whether your verification vendor still returns meaningful SMTP results on the major providers, and lean harder on engagement history and risk flags as the handshake keeps degrading. The standard itself - four independent tests, a tri-state verdict, a timestamped flag, and a separate lawful-basis gate - holds regardless of which numbers move underneath it.