List hygiene SOP: the exact fields to enforce

Cold email isn’t hard because writing is hard. It’s hard because lists rot.

You can have the best offer and a decent copy. But if your CSV is sloppy, you get bounces, blocks, spam placement, weird personalization failures, and you end up “testing” the wrong things. Deliverability tanks and you blame the subject line. Been there.

This is a practical SOP you can hand to someone on your team (or future you) and say: enforce these fields, in this format, every single time. No exceptions. And yeah, it’s detailed. That’s the point.

If you use a cold outreach platform like PlusVibe later, the same structure makes everything easier: bulk verification, inbox rotation, throttling, personalization, reporting. The list stops being a mystery box.

What “list hygiene” actually means (in plain terms)

List hygiene is not just about verifying emails. It's a comprehensive process that involves data hygiene best practices:

making sure every row represents a real, reachable person
standardizing naming so personalization doesn’t break
capturing enough context to target and segment
enforcing consent and suppression logic so you do not email the wrong people
tracking provenance so you can audit, fix, and improve sources

Also, list hygiene is a system, not a one-time clean. Your list is either getting cleaner every week or it’s quietly decaying.

The SOP at a glance

Here’s the flow you want:

Ingest leads from source (scraper, Apollo, Clay, LinkedIn, manual, event list, inbound form).
Normalize fields (trim, casing, company naming, location, titles).
Enrich missing critical fields (domain, LinkedIn URL, role, company size, etc).
Verify email using best email validation and list cleaning services and tag the result (deliverable, risky, unknown, invalid).
Deduplicate at person level and at company level.
Suppress against blocklists and do not contact rules.
Score and segment based on ICP and campaign fit.
Export to outreach tool with enforced schema.
Monitor bounce, complaint, unsubscribe, reply patterns; feed back into suppression + scoring.

This article focuses mainly on steps 2 through 8 - detailing the fields required for building an effective email list, exact formats to be used during email list cleaning, and the rules to follow for optimal results.

The schema philosophy: required vs conditional vs optional

If you force everything to be “required,” people will invent data. That’s worse than null.

So we split fields into:

Required: must exist for every row, otherwise it does not enter outreach.
Conditionally required: required if a condition is true (like “if country is US, require state” or “if you personalize by job function, require department”).
Optional: nice to have, but not a blocker.

Also, every field needs:

a type (string, integer, boolean, enum, date)
an allowed format
an example
a validation rule
a source or provenance tag (how did we get it)

You will see that below.

The exact fields to enforce (master list)

How to read this section

Each field includes:

Field name (suggested)
Type
Required?
Format
Validation
Example
Notes

Use these names exactly if you can. If you already have your own names, map them. But be consistent across tools.

A) Identity fields (person)

These are the core “who is this” fields. If these are inconsistent, everything downstream breaks.

1) `lead_id`

Type: string (UUID preferred)
Required: yes
Format: UUIDv4 or a stable hashed ID
Validation: unique per row
Example: 8c6c2b7a-2d5b-4d11-8df0-9b1b7f2d9d63
Notes: Do not use email as your ID. Emails change. People change jobs.

2) `first_name`

Type: string
Required: yes (unless you have a strict reason)
Format: title case, no extra whitespace
Validation: 1 to 50 chars, no emojis, no placeholder like “Friend”
Example: Priya
Notes: If first name is missing, a lot of personalization tokens will render empty and your emails look like spam.

3) `last_name`

Type: string
Required: no (but recommended)
Format: title case
Validation: 0 to 60 chars
Example: Sharma

4) `full_name`

Type: string
Required: no (derive if you can)
Format: first_name + space + last_name
Validation: should match first/last if present
Example: Priya Sharma
Notes: This helps when you import from sources that only give full name.

5) `linkedin_url`

Type: string (URL)
Required: conditionally required (highly recommended for B2B)
Format: must be a valid LinkedIn profile URL, normalized
Validation: starts with https://www.linkedin.com/in/
Example: https://www.linkedin.com/in/priya-sharma-12345/
Notes: LinkedIn URL is one of the best dedupe anchors besides email.

6) `job_title`

Type: string
Required: yes
Format: raw title as on LinkedIn, trimmed
Validation: 2 to 120 chars
Example: Head of Revenue Operations
Notes: Don’t over-normalize into weird internal labels. Keep raw, then add a normalized field too.

7) `job_title_normalized`

Type: enum / string
Required: conditionally required (if you route by role)
Format: controlled vocabulary you define
Validation: must be one of allowed values
Example: RevOps_Leader
Notes: This is what you use for segmentation, not raw job_title.

8) `department`

Type: enum / string
Required: conditionally required (if you personalize by function)
Format: controlled vocabulary
Validation: allowed values only
Example: Revenue Operations
Suggested values: Sales, Marketing, RevOps, Finance, HR, IT, Security, Engineering, Product, Customer Success, Operations, Legal, Founder

9) `seniority`

Type: enum
Required: conditionally required (if you target seniority bands)
Format: one value
Validation: allowed values only
Example: Director
Suggested values: Owner, C-Level, VP, Director, Head, Manager, IC, Intern, Partner

10) `persona`

Type: enum/string
Required: no but useful
Format: your internal persona tags
Example: RevOps_Director_SaaS

B) Contact fields (email, phone)

This is where deliverability lives or dies.

11) `email`

Type: string
Required: yes
Format: lowercase, trimmed
Validation: valid email syntax, no spaces, no disposable domains
Example: priya@acme.com
Notes: Store lowercase. Always. It's also beneficial to consider email scrubbing, a process that can improve the quality of your email list and enhance deliverability.

12) `email_domain`

Type: string
Required: yes (derive from email if present)
Format: lowercase domain
Validation: must match portion after @
Example: acme.com

13) `email_verification_status`

Type: enum
Required: yes
Format: one of your verification outputs
Validation: must be allowed value
Example: deliverable
Suggested values: deliverable, risky, unknown, invalid, catch_all, role_based, disabled, blocked
Notes: Catch-all is not the same as invalid. But you should treat it carefully.

14) `email_verification_date`

Type: date (ISO 8601)
Required: yes
Format: YYYY-MM-DD
Validation: must be a real date
Example: 2026-02-10
Notes: Verification expires. If it’s older than 30 to 60 days, recheck.

15) `email_verification_provider`

Type: string
Required: yes
Format: vendor name
Example: PlusVibe
Notes: You want traceability when results differ across providers.

16) `email_type`

Type: enum
Required: conditionally required (recommended)
Format: allowed values
Example: personal
Suggested values: personal, role_based, group, alias, unknown
Notes: Role based emails like info@, sales@ should usually be suppressed for cold outbound unless you explicitly run those plays.

17) `phone`

Type: string
Required: no
Format: E.164 if possible
Validation: starts with + country code
Example: +14155550123

18) `do_not_call`

Type: boolean
Required: no (but if you have phone, this matters)
Example: true

C) Company fields

A lot of bad lists fail because company data is messy. “Acme Inc”, “ACME”, “Acme, LLC”. Then your dedupe fails, your enrichment fails, and your personalization sounds wrong.

19) `company_name`

Type: string
Required: yes
Format: trimmed, keep proper capitalization
Validation: 2 to 120 chars
Example: Acme

20) `company_name_normalized`

Type: string
Required: yes
Format: lowercase, remove suffixes and punctuation
Validation: stable normalization rules
Example: acme
Notes: This is your dedupe key alongside domain.

21) `company_domain`

Type: string
Required: yes
Format: lowercase, no protocol, no path
Validation: valid domain, not a free email domain
Example: acme.com
Notes: Domain is the best company identifier. If you don’t have this, fix that before outreach.

22) `company_linkedin_url`

Type: string (URL)
Required: no but recommended
Format: https://www.linkedin.com/company/...
Example: https://www.linkedin.com/company/acme/

23) `company_size`

Type: enum
Required: conditionally required (if ICP depends on size)
Format: standard buckets
Example: 51-200
Suggested values: 1-10, 11-50, 51-200, 201-500, 501-1000, 1001-5000, 5001-10000, 10000+

24) `company_industry`

Type: string/enum
Required: conditionally required
Format: controlled list if possible
Example: Computer Software
Notes: Don’t let people type random things like “SaaS-ish”. Choose a taxonomy.

25) `company_country`

Type: string (ISO 3166-1 alpha-2)
Required: yes (for compliance, sending windows, routing)
Format: US, GB, DE
Validation: must be valid ISO code
Example: US

26) `company_region`

Type: string
Required: no
Example: North America

27) `company_state`

Type: string
Required: conditionally required (if company_country=US or if you route by state)
Format: 2 letter state code
Example: CA

28) `company_city`

Type: string
Required: no
Example: San Francisco

29) `company_timezone`

Type: string (IANA tz)
Required: conditionally required (if you schedule by local time)
Format: America/Los_Angeles
Example: America/New_York
Notes: If you do outbound at scale, send time matters. If you use a platform that schedules by timezone, this field becomes money.

30) `company_website_url`

Type: URL
Required: no (domain covers it)
Format: https://acme.com
Example: https://acme.com

D) Address fields (optional but good hygiene)

31) `company_address_line1`

Type: string
Required: no

32) `company_postal_code`

Type: string
Required: no

33) `company_country_name`

Type: string
Required: no (derive from ISO)
Example: United States

E) Source and provenance fields (do not skip these)

This is the part most teams ignore, until they get a spam spike and can’t figure out why.

34) `lead_source`

Type: enum/string
Required: yes
Format: controlled values
Example: apollo
Suggested values: apollo, linkedin_manual, event_sponsor_list, website_signup, partner_referral, clay, csv_import, plusvibe_prospecting

35) `lead_source_detail`

Type: string
Required: no
Example: Apollo export 2026-02-01, filter: RevOps, US, 51-200

36) `lead_import_batch_id`

Type: string
Required: yes
Format: stable batch identifier
Example: import_2026_02_10_revops_us_v1
Notes: This is how you roll back a bad batch.

37) `lead_created_at`

Type: datetime (ISO 8601)
Required: yes
Example: 2026-02-10T14:22:09Z

38) `lead_last_enriched_at`

Type: datetime
Required: no

39) `data_confidence_score`

Type: integer (0-100)
Required: no but recommended
Example: 82
Notes: Aggregate your own confidence: recent verification, LinkedIn match, domain match, etc.

F) Compliance and suppression fields (this is your safety net)

Not legal advice, but practically speaking you need internal controls. And you definitely need suppression logic.

40) `consent_status`

Type: enum
Required: yes
Example: legitimate_interest
Suggested values: unknown, consented, legitimate_interest, opted_out, do_not_contact
Notes: Most B2B outbound teams operate under legitimate interest depending on region and context. But you still need to track opt outs, always.

41) `unsubscribed`

Type: boolean
Required: yes
Example: false

42) `unsubscribed_at`

Type: datetime
Required: conditionally required (if unsubscribed=true)

43) `suppression_reason`

Type: string/enum
Required: conditionally required (if consent_status is opted_out or do_not_contact)
Example: unsubscribed_via_link

44) `suppression_list`

Type: string
Required: no
Example: global_dnc

45) `gdpr_country_flag`

Type: boolean
Required: no (derive from country)
Example: true

46) `do_not_email`

Type: boolean
Required: yes
Example: false
Notes: This is your final kill switch field. If true, your sending tool should never send.

47) `do_not_email_reason`

Type: string
Required: conditionally required (if do_not_email=true)
Example: previous_spam_complaint

48) `previous_contacted`

Type: boolean
Required: no
Example: true

49) `previous_contacted_at`

Type: datetime
Required: conditionally required (if previous_contacted=true)

G) Campaign readiness fields (so your outreach tool behaves)

50) `campaign_id`

Type: string
Required: no (until assigned)
Example: cmp_revops_q1_2026_v2

51) `sequence_name`

Type: string
Required: no
Example: RevOps pain point: deliverability + reporting

52) `sending_language`

Type: enum
Required: no
Example: en
Suggested values: en, en-GB, de, fr, es

53) `send_window_local`

Type: string
Required: no
Format: HH:MM-HH:MM
Example: 09:30-16:30

54) `priority`

Type: integer
Required: no
Example: 3
Notes: If you throttle and rotate across inboxes, priority helps decide who goes first.

H) Personalization fields (keep them clean or don’t use them)

Personalization is where list hygiene gets “visible.” It’s also where lists embarrass you.

55) `personalization_line_1`

Type: string
Required: no
Validation: max 200 chars, no brackets, no tokens
Example: Noticed you’re hiring for RevOps and scaling outbound at the same time.

56) `personalization_reference`

Type: string
Required: no
Example: Job post for Senior RevOps Analyst

57) `recent_event`

Type: string
Required: no
Example: Raised Series B

58) `icebreaker_source_url`

Type: URL
Required: conditionally required (if you use recent_event claims)
Example: https://acme.com/blog/series-b-announcement

59) `account_pain_hypothesis`

Type: enum/string
Required: no
Example: deliverability_spam_risk

I) Dedupe and matching fields (boring, critical)

60) `person_dedupe_key`

Type: string
Required: yes (derive)
Format: stable hash of linkedin_url if present else email else full_name+company_domain
Example: sha1:9f2c...

61) `company_dedupe_key`

Type: string
Required: yes (derive)
Format: company_domain if present else normalized company name
Example: acme.com

62) `match_confidence`

Type: integer (0-100)
Required: no
Example: 91

J) Deliverability control fields (your list should carry these)

If you scale outbound, your list should contain the stuff that helps you avoid sending to risky profiles.

63) `free_email_domain_flag`

Type: boolean
Required: yes (derive)
Example: false
Notes: If someone has an email from a free domain like Gmail, it could indicate a different approach is needed, especially in a B2B context. It's crucial to manage such email lists effectively to maintain deliverability and avoid spam risks. For more insights on this topic, refer to this article on email list management.

64) `disposable_email_flag`

Type: boolean
Required: yes (derive)
Example: false

65) `role_account_flag`

Type: boolean
Required: yes (derive)
Example: false

66) `catch_all_flag`

Type: boolean
Required: yes (from verification)
Example: true

67) `spamtrap_risk_flag`

Type: boolean
Required: no (if your verifier provides it)
Example: false

Suggested images to add (placeholders you can swap with screenshots)

You said this is going on WordPress, so here are image slots that make sense. Replace with your own screenshots from your spreadsheet template, your enrichment tool, or PlusVibe screens.

Image 1: “Hygiene pipeline overview”

Image 2: “Example schema in Google Sheets”

Image 3: “Verification status mapping table”

Image 4: “Suppression logic flow”

If you don’t have these images yet, keep the placeholders as a production to do. Or replace them with screenshots from your actual process. Real screenshots convert better anyway.

The validation rules (the part people skip, then regret)

You can have the right fields and still have a dirty list because nobody enforced formatting.

Here are the rules that matter most.

Rule 1: Trim everything

Remove leading/trailing spaces from every string.
Collapse multiple spaces inside names and titles.

Why it matters: tokens break. Dedupes fail. You get weird “Hello Priya”.

Rule 2: Lowercase emails and domains

email and company_domain must be lowercase.

Why it matters: most tools treat them case-insensitive, but your dedupe might not. Don’t risk it.

Rule 3: Enums only for segmentation fields

Fields like seniority, company_size, consent_status, email_verification_status should be dropdown values, not free text.

Why it matters: “VP” and “V.P.” are not two segments. But they become two segments in your reporting.

Rule 4: ISO standards for dates and country codes

Dates: YYYY-MM-DD
Datetimes: ISO 8601
Countries: ISO alpha-2

Why it matters: consistent filters and compliance logic.

Rule 5: Null over lies

If you do not know the timezone, keep it blank. Do not guess. If you do not know industry, do not force “SaaS”.

Why it matters: wrong segmentation hurts more than missing segmentation.

Rule 6: Verification recency policy

Set an internal rule like:

if email_verification_date > 45 days ago, re-verify before sending
if catch_all_flag=true, throttle and test with smaller volume first
if risky, either suppress or run in a separate low volume campaign

This is where a deliverability first platform like PlusVibe helps, because verification and deliverability controls are not an afterthought. But even if you do it elsewhere, you need the policy written down.

Dedupe SOP (person and company)

You need two dedupe passes:

Pass 1: Person level dedupe

Prefer this order of uniqueness:

linkedin_url (if present)
email
(full_name + company_domain)
(first_name + last_name + company_name_normalized) as a last resort

If duplicates exist:

keep the row with the most recent verification date
keep the row with the highest data confidence
merge missing fields from the other row if they don’t conflict
log the merge (even a simple “merged_into_lead_id” field works)

Pass 2: Company level dedupe

Use:

company_domain
else company_name_normalized + country

Why: multiple employees from the same company is fine. But if you have 14 variants of the company name, your analytics and account based routing becomes garbage.

Suppression SOP (global, campaign, and inbox safety)

Suppression is not “unsubscribes only.”

You should maintain at least three layers:

1) Global suppression list

A lead is suppressed from all sends if:

unsubscribed=true
do_not_email=true
consent_status in (opted_out, do_not_contact)
previous spam complaint (if you track it)
internal rule (competitors, partners, existing customers depending on your policy)

2) Campaign suppression

Even if globally allowed, suppress from a specific campaign if:

already in that campaign
already replied in the last X days
already booked a meeting
already disqualified for that specific offer

3) Deliverability suppression

Suppress or isolate into a special low volume queue if:

email_verification_status=invalid
disposable_email_flag=true
spamtrap_risk_flag=true
high bounce risk patterns

Write this down. Then implement it in your CRM + outreach tool logic. If you are using something like PlusVibe with multi inbox rotation and deliverability controls, you still need the list to carry the right flags so your segmentation is accurate.

Segmentation fields that actually matter (and which ones are fluff)

You do not need 40 segmentation fields.

You need the 8 to 12 that affect:

fit
message angle
send timing
volume and throttling

My usual “worth it” list:

job_title_normalized
department
seniority
company_size
company_industry
company_country (and timezone if used)
email_verification_status
catch_all_flag
lead_source
data_confidence_score

Everything else is usually gravy.

The minimum viable hygiene checklist (print this)

A lead is allowed into outreach only if:

first_name present and not garbage
job_title present
company_name present
company_domain present and not a free email domain
email present, lowercase, syntax valid
email_verification_status is acceptable (you decide)
unsubscribed=false
do_not_email=false
lead_source and lead_import_batch_id present
verification date within your allowed window

That’s it. That alone will save you from a shocking amount of pain.

A concrete spreadsheet template (columns in order)

If you want an opinionated column order for Google Sheets or Airtable, use this. It follows how humans scan.

lead_id
first_name
last_name
email
email_verification_status
email_verification_date
catch_all_flag
role_account_flag
job_title
seniority
department
linkedin_url
company_name
company_domain
company_size
company_industry
company_country
company_timezone
lead_source
lead_import_batch_id
lead_created_at
consent_status
unsubscribed
do_not_email
do_not_email_reason
personalization_line_1
icebreaker_source_url
campaign_id
priority

Keep the rest in hidden columns if needed.

Common failure modes (and the fixes)

Failure mode 1: “We verified, but bounces are still high”

Usually:

verification is old
you’re sending to catch-all at high volume
you deduped poorly and are hitting aliases or role accounts
your domain mapping is wrong (company_domain mismatch)

Fix:

enforce verification recency
isolate catch-all sends
enforce role account suppression
add domain matching checks (email_domain should match company_domain most of the time in B2B)

Failure mode 2: “Personalization tokens are breaking”

Usually:

first_name has junk (like “.” or “-”)
job_title is blank
you have weird characters
you’re mixing UTF encodings from CSV sources

Fix:

set validation that rejects first_name values under 2 chars
implement “fallback tokens” rules in your sending tool
normalize encoding to UTF-8

Failure mode 3: “Reporting is useless”

Usually:

industries are free text
seniority values are inconsistent
company size is missing for half the list
sources are unknown so you can’t compare quality

Fix:

enforce enums
enforce lead_source + import_batch_id
create a “data confidence score” and use it to compare vendors and filters

Where PlusVibe fits (subtle, practical)

If you are already enforcing a schema like this, a deliverability focused platform becomes way more effective because it can actually act on clean inputs.

With PlusVibe, the obvious wins are:

bulk email verification and hygiene at scale
deliverability controls that depend on clean flags (catch-all, risky, etc)
multi inbox management with rotation and throttling, which benefits from clean segmentation and timezone
cleaner personalization and A/B testing when your fields are consistent

The tool does not replace the SOP, though. The SOP makes the tool work.

Final SOP you can copy into your internal doc

Frequency

Run normalization, dedupe, and suppression on every import.
Re-verify emails every 30 to 60 days if not yet contacted.
Refresh enrichment for active segments monthly.

Owner

List Ops (or RevOps) owns schema + suppression.
SDR manager owns campaign segmentation rules.
Whoever imports data must follow checklist.

Definition of done (before sending)

Required fields present
Verification status acceptable
Suppression logic applied
Dedupe complete
Batch ID and source set
A small sample (20 to 50 rows) manually spot checked

Audit trail

Keep lead_import_batch_id
Keep email_verification_provider and date
Log suppression reasons
Keep merge history for dedupes (even if it’s basic)

Wrap up

If you enforce the fields above, your cold email becomes boring in the best way. Fewer surprises. Fewer bounces. More reliable experiments. Better deliverability over time.

And if you want the same deliverability first mindset on the sending side, that’s where something like PlusVibe is worth a look. Clean list in, clean sending out. That’s the loop.

FAQs (Frequently Asked Questions)

Why is cold email outreach challenging despite good copy and offers?

Cold email outreach is challenging not because writing is difficult, but because email lists degrade over time. Sloppy or outdated CSV lists lead to bounces, blocks, spam placements, and personalization failures, which harm deliverability and result in ineffective campaigns.

What does 'list hygiene' mean in the context of cold email outreach?

'List hygiene' refers to a comprehensive process that ensures every contact in your list is real and reachable. It involves standardizing data formats, capturing sufficient context for targeting and segmentation, enforcing consent and suppression rules to avoid emailing wrong contacts, tracking data provenance for audits, and continuously maintaining the list's cleanliness rather than treating it as a one-time task.

What are the key steps in the standard operating procedure (SOP) for maintaining cold email lists?

The SOP includes: 1) Ingesting leads from various sources; 2) Normalizing fields like trimming whitespace and standardizing company names; 3) Enriching missing critical data such as domain and LinkedIn URLs; 4) Verifying emails using validation services; 5) Deduplicating at person and company levels; 6) Suppressing contacts based on blocklists; 7) Scoring and segmenting leads based on ideal customer profile (ICP); 8) Exporting to outreach tools with enforced schema; and 9) Monitoring bounce, complaint, unsubscribe, and reply patterns to refine suppression and scoring.

How should fields in an email list be categorized for effective data management?

Fields should be split into three categories: Required (must exist for every row), Conditionally Required (required only if certain conditions apply, e.g., state required if country is US), and Optional (nice to have but not mandatory). Each field should also have a defined type, format, example value, validation rules, and source or provenance information to ensure consistency across tools.

Why is it important to use unique IDs like UUIDs instead of emails as lead identifiers?

Using unique IDs such as UUIDv4 instead of emails as lead identifiers is crucial because emails can change over time when people switch jobs or update their addresses. A stable unique ID ensures consistent tracking of each contact regardless of changes to their email or other details.

What are best practices for personal identity fields in an email list?

Identity fields like first name should be in title case without extra whitespace or emojis. First name is usually required since missing it can cause personalization tokens to fail. Last name is recommended but optional. Full name can be derived by combining first and last names if needed. Including normalized LinkedIn URLs is highly recommended for B2B deduplication and verification purposes.

Explore most secure Warm-Up process

Smart Warm-Up for Every Inbox

List hygiene SOP: the exact fields to enforce

Cold Outreach Academy

100+ Cold Email Templates

Start 14-day Free Trial

Subscribe to Our Newsletter!

List hygiene SOP: the exact fields to enforce

What “list hygiene” actually means (in plain terms)

The SOP at a glance

The schema philosophy: required vs conditional vs optional

The exact fields to enforce (master list)

How to read this section

A) Identity fields (person)

1) lead_id

2) first_name

3) last_name

4) full_name

5) linkedin_url

6) job_title

7) job_title_normalized

8) department

9) seniority

10) persona

B) Contact fields (email, phone)

11) email

12) email_domain

13) email_verification_status

14) email_verification_date

15) email_verification_provider

16) email_type

17) phone

18) do_not_call

C) Company fields

19) company_name

20) company_name_normalized

21) company_domain

22) company_linkedin_url

23) company_size

24) company_industry

25) company_country

26) company_region

27) company_state

28) company_city

29) company_timezone

30) company_website_url

D) Address fields (optional but good hygiene)

31) company_address_line1

32) company_postal_code

33) company_country_name

E) Source and provenance fields (do not skip these)

34) lead_source

35) lead_source_detail

36) lead_import_batch_id

37) lead_created_at

38) lead_last_enriched_at

39) data_confidence_score

F) Compliance and suppression fields (this is your safety net)

40) consent_status

41) unsubscribed

42) unsubscribed_at

43) suppression_reason

44) suppression_list

45) gdpr_country_flag

46) do_not_email

47) do_not_email_reason

48) previous_contacted

49) previous_contacted_at

G) Campaign readiness fields (so your outreach tool behaves)

50) campaign_id

51) sequence_name

52) sending_language

53) send_window_local

54) priority

H) Personalization fields (keep them clean or don’t use them)

55) personalization_line_1

56) personalization_reference

57) recent_event

58) icebreaker_source_url

59) account_pain_hypothesis

1) `lead_id`

2) `first_name`

3) `last_name`

4) `full_name`

5) `linkedin_url`

6) `job_title`

7) `job_title_normalized`

8) `department`

9) `seniority`

10) `persona`

11) `email`

12) `email_domain`

13) `email_verification_status`

14) `email_verification_date`

15) `email_verification_provider`

16) `email_type`

17) `phone`

18) `do_not_call`

19) `company_name`

20) `company_name_normalized`

21) `company_domain`

22) `company_linkedin_url`

23) `company_size`

24) `company_industry`

25) `company_country`

26) `company_region`

27) `company_state`

28) `company_city`

29) `company_timezone`

30) `company_website_url`

31) `company_address_line1`

32) `company_postal_code`

33) `company_country_name`

34) `lead_source`

35) `lead_source_detail`

36) `lead_import_batch_id`

37) `lead_created_at`

38) `lead_last_enriched_at`

39) `data_confidence_score`

40) `consent_status`

41) `unsubscribed`

42) `unsubscribed_at`

43) `suppression_reason`

44) `suppression_list`

45) `gdpr_country_flag`

46) `do_not_email`

47) `do_not_email_reason`

48) `previous_contacted`

49) `previous_contacted_at`

50) `campaign_id`

51) `sequence_name`

52) `sending_language`

53) `send_window_local`

54) `priority`

55) `personalization_line_1`

56) `personalization_reference`

57) `recent_event`

58) `icebreaker_source_url`

59) `account_pain_hypothesis`

60) `person_dedupe_key`

61) `company_dedupe_key`

62) `match_confidence`

63) `free_email_domain_flag`

64) `disposable_email_flag`

65) `role_account_flag`

66) `catch_all_flag`

67) `spamtrap_risk_flag`