A null contact email means that a contact record has no stored email value. In a database, the field contains NULL; in a CRM or spreadsheet, the interface may show an empty cell, “unknown”, a dash or no email at all.

That definition sounds simple, but the repair can go wrong quickly. A blank string is not always a true database null. A malformed address is not missing. A bounced address once contained a value. An opted-out contact may still have a valid address that you must retain on a suppression list.

Before you edit or delete anything, identify which state you actually have.

What you see	Likely state	Correct first action
NULL or no property value	No email stored	Trace the record source and stable ID
Empty cell or ""	Empty string	Trim and normalise it consistently
Spaces only	Whitespace value	Trim before testing for emptiness
alex@	Malformed syntax	Ask the contact to correct it
Valid address with a bounce	Delivery failure	Review the bounce and suppression status
Valid address with an opt-out	Permission state	Keep it suppressed; do not replace it
Hidden WHOIS address	Public redaction	Use the registrar’s relay or contact form

What NULL means in contact data

SQL uses NULL to represent an absent or unknown value. It does not behave like ordinary text. You must test it with IS NULL, not = NULL.

The PostgreSQL docs explain that ordinary comparisons with null return an unknown result.

An empty string contains zero characters, while a whitespace-only string contains characters that you cannot easily see.

Some imports convert empty cells to NULL; others preserve them as empty strings. That difference explains why two CRM reports can return different counts for “missing email”.

The field can also carry a literal string such as null, N/A or unknown. Those placeholders are text, not null values. Treating them as addresses can contaminate exports and trigger import errors.

A controlled SQLite test separated the five states before any repair step.

Why null contact emails appear

Most null values enter through one of four paths.

a) A form allowed an incomplete submission

An email field can look important without actually requiring a value. HTML accepts an empty type="email" field unless you also add required. JavaScript errors, conditional form steps and server-side validation gaps can also let incomplete records through.

b) An import mapped the wrong column

A CSV may contain Email address, while the destination expects Email. If the operator skips the mapping or selects another property, the CRM can create a contact from a name or record ID without importing the address.

Platforms apply different rules. HubSpot says a new contact import needs at least a first name, last name or email, and it can use email or Record ID as a unique identifier. Mailchimp requires an email column for email contacts. Check the current HubSpot rules or Mailchimp format before assuming that every tool rejects the same row.

c) An integration created the record too early

A form, checkout or chat tool may create the contact before a later step collects the email. If the second request fails, the CRM retains a partial record. Field-name changes and API payloads that omit optional properties cause the same symptom.

d) A migration changed the data representation

Source and destination systems can disagree about empty cells, whitespace, placeholder text and property types. A migration can also lose the email when the export uses one field but the new CRM maps another.

Diagnose the source before fixing the value

Start with one affected record and follow its history backwards.

• Confirm whether the CRM shows a missing property, an empty string or hidden data.

• Find the creation source, timestamp and import or integration job.

• Identify the stable record ID, customer ID or transaction ID.

• Check whether another authorised system holds the address.

• Review consent, opt-out, bounce and suppression fields separately.

• Count every affected record with the same source and date range.

Do not merge records simply because their names or companies match. Two people can share both. Use a stable ID or another strong identity match before you combine histories.

Find null and blank values with SQL

Use separate conditions so the audit tells you what you need to repair.

-- True SQL nulls
SELECT id, email
FROM contacts
WHERE email IS NULL;

-- Empty or whitespace-only values, excluding true nulls
SELECT id, email
FROM contacts
WHERE email IS NOT NULL
  AND TRIM(email) = '';

Do not write email = NULL. In the controlled test, that query returned zero rows, while email IS NULL returned the deliberate null record.

Syntax checks need their own query or application validator. A simple regular expression can catch obvious mistakes, but email syntax contains more valid forms than many home-grown patterns allow. Use syntax validation as a screen, not proof that the mailbox exists.

Fix each record without inventing data

Choose the action from the evidence you hold.

Recover from an authoritative source

Use an address that the person supplied through your form, account, order or support conversation. Match it through the stable record ID, then record the source and correction date.

If you need the person to supply an address, contact them through an existing permitted channel. Do not guess an address from their name and company or scrape one from an unrelated source.

Keep a non-emailable contact when the record still matters

A contact can represent a customer, transaction, consent event or support history even without email. Retain the record under its stable ID and mark the email state clearly. That approach protects reporting and avoids recreating the same incomplete record.

Merge only after you establish identity

When the same person has two records, choose the surviving record according to your CRM’s merge rules. Preserve activity, consent, opt-out and suppression history. An email match can help identify duplicates, but a null email cannot provide that match.

Delete under a defined retention policy

Remove a record only when you no longer need it, your retention policy supports deletion, and no legal, transactional or suppression reason requires you to keep it. Deleting every null record can erase evidence and allow an opted-out address to return through a later import.

Prevent null values at four control points

1) Validate at capture

Use type="email" with required when the workflow cannot continue without an address. Provide a clear inline error and repeat the check on the server. The MDN reference notes that browser validation checks basic format, not mailbox existence.

<label for="email">Email address</label>
<input id="email" name="email" type="email" required>

The test blocked an empty value and alex@, then accepted the syntax of [email protected]. It did not test delivery or consent.

Do not require email merely to avoid nulls. A phone-only enquiry can remain useful when your process supports it. Make the field mandatory only when email performs a necessary job, such as account recovery or a requested email response.

2) Normalise at the boundary

Trim surrounding whitespace. Convert empty values to one agreed representation. Reject placeholder text such as N/A when the property expects an address. Apply the same rule to forms, CSV imports and API requests.

3) Preserve a stable identifier

Use the CRM’s record ID or another controlled unique key when you update contacts. This prevents a missing email from turning an update into a duplicate record. Preview an import, inspect the mapping and test a small batch before committing the full file.

4) Separate permission and delivery states

Store the address, consent evidence, marketing status, opt-out date, bounce class and suppression reason as distinct fields. This keeps “missing”, “cannot deliver” and “must not contact” from collapsing into one vague status.

UK marketing rules still apply after recovery

Finding an email address fixes a data gap; it does not create permission to send marketing.

The UK Information Commissioner’s Office says organisations should check the origin and accuracy of bought-in lists and only use them for email marketing when the consent specifically covers that organisation and channel. Review the ICO list rules before importing third-party data.

Keep a record of who consented, when, how and what they agreed to receive. Maintain opt-out and suppression data even when you clean or merge contact records. Never treat a guessed, enriched or publicly visible address as proof of consent.

A hidden WHOIS email is a different issue

A domain lookup may hide a registrant email or mark it redacted. That public result does not prove that the registrar’s private contact record contains NULL.

ICANN’s current policy allows redaction and requires registrars applying it to provide a relay address or web form for contact. Use the ICANN lookup or the registrar’s contact method instead of trying to recover the private address.

Your cleanup checklist

• Count true null, empty, whitespace, malformed, bounced and suppressed records separately.

• Trace the source and stable ID before editing.

• Recover only from an authoritative, permitted source.

• Preserve consent, opt-out and suppression history.

• Test form validation in the browser and on the server.

• Preview field mapping before every large import.

• Monitor new null records by source and date.

If your website lacks a reliable home for forms, databases and domain-based mail, review our UK hosting options.

Hosting can support the capture layer and professional email, but your CRM still needs the validation, identity and permission controls above.

---