Airtable is where a lot of teams keep their contacts — a sign-up form feeds a base, an Interface collects leads, a CSV import drops in last week's event list. But Airtable's email field only checks that an address looks right; it can't tell you whether the mailbox actually exists, whether it's a throwaway, or whether it will hard-bounce your very first send. This guide shows two practical ways to verify emails from Airtable with Qualisend: in real time, with an automation that runs a short script on every new record, and in bulk, by exporting a view to CSV. Neither needs a native plugin — there isn't one yet — just Airtable's built-in automations or its export button.
The short answer#
Pick the path that matches when you need the answer:
- Real time — build an Airtable Automation with a Run a script action.
On every new (or updated) record it reads the email, calls the Qualisend API
with
fetch, and writes the verdict back into a field on the same row. The record now carries astatusandscoreyou can filter, group, and route on. - Bulk — export a table or view to CSV, run it through Qualisend's bulk verification, and re-import the cleaned file to backfill a status column across everything already sitting in your base.
Why Airtable's email field isn't enough#
Airtable's Email field type runs a format check — it makes sure there's an @,
a domain, and no obvious garbage. That's the same class of check a regex does,
and it fails for the same reasons:
format is not deliverability.
jane@gmial.com passes the format check. So does throwaway@mailinator.com, and
so does a real-looking address at a domain that quietly shut down last year.
None of those are caught until you send — and by then a dead address is a hard bounce that chips at your bounce rate and sender reputation. Real verification adds the layers a spreadsheet can't: a DNS/MX lookup and an SMTP mailbox probe, plus flags for disposable, role, and catch-all addresses. If that pipeline is new to you, what email verification actually checks is the primer.
Two ways to verify emails from Airtable#
The important constraint first: verification happens after a row exists, not as an inline gate on the form or Interface that created it. Airtable has no supported way to block a submission mid-entry on an external API call, so you verify the record the moment it lands and then act on the verdict — that shapes both paths below.
| Path | When it runs | Best for |
|---|---|---|
| Automation script | Instantly, per new/updated record | Live intake — verify and tag each address as it arrives |
| Bulk CSV | On demand, in batches | Existing records and periodic list hygiene |
Most teams end up doing both: a script on live intake, plus an occasional list clean to catch addresses that have gone stale since they were first added.
Path 1: real-time with an Airtable automation#
Airtable Automations can run a JavaScript snippet with a Run a script action,
and that snippet can call an external API with fetch — everything you need to
verify a record without leaving Airtable.
1. Choose the trigger. In Automations, create one and pick a trigger:
- When a record is created — the simplest choice for a form or Interface that appends new rows.
- When a record matches conditions (e.g. Email status is empty) — good for skipping rows you've already verified.
- When a record enters a view — point it at a view filtered to
Email status = emptyso re-runs never double-charge you for the same address.
2. Add the "Run a script" action and configure two input variables in the
action's left panel: map email to the triggering record's email field, and
recordId to the record's Airtable record ID. The script reads them through
input.config().
3. Write the script. It calls Qualisend, then writes the verdict back onto the same row. Confirm the exact endpoint and request shape in the developer docs — the placeholders below are yours to fill in:
// Airtable automation → "Run a script" action.
// Input variables (set in the action's left panel):
// email → the triggering record's email field
// recordId → the triggering record's record ID
let { email, recordId } = input.config();
let table = base.getTable("Contacts");
try {
let response = await fetch("https://api.qualisend.com/v1/verify", {
method: "POST",
headers: {
// Use a scoped, verify-only key — see the note below on key safety.
"Authorization": "Bearer YOUR_API_KEY",
"Content-Type": "application/json",
},
body: JSON.stringify({ email }),
});
// Response shape: { result: { status, score, reason, sub_flags } }
let { result } = await response.json();
await table.updateRecordAsync(recordId, {
"Email status": result.status, // text: deliverable / risky / undeliverable / unknown
"Email score": result.score, // number: 0–100
});
} catch (err) {
// Fail open: never lose a contact if the API is briefly unreachable.
await table.updateRecordAsync(recordId, { "Email status": "unknown" });
}
A few things make this robust and safe:
- Use a scoped key. Airtable automation scripts store the key in the script text, where any base collaborator can read it, and there's no server-side secret store for a snippet like this. So mint a verify-only scoped key for this automation rather than a full-access one — if it ever leaks, it can only verify addresses, nothing else. The developer docs show how to scope a key. This is the Airtable equivalent of the "key stays server-side" rule in the serverless verify-at-signup pattern.
- Fail open. If the request errors or times out, don't drop the record — the
catchblock writesunknownso a human (or a later re-run) can pick it up. A verification API is a quality filter, not an authentication gate; a transient outage should never delete a real lead. - Avoid re-trigger loops. If your trigger is When a record is updated, watch a specific field (the email field) — not "any field" — or the write-back above will re-fire the automation on itself. Triggering on record creation or a filtered view sidesteps this entirely.
- Match your field types. Writing to a single-line text field takes the status
string as-is. If you'd rather use a single-select, pass
{ name: result.status }and pre-create the four options (deliverable,risky,undeliverable,unknown) so the write doesn't fail.
The verification call itself is language-agnostic — the same request works from a
Typeform webhook or a
Zapier Custom Request if part of your stack
lives outside Airtable. Only the input.config() / updateRecordAsync glue above
is Airtable-specific.
Path 2: bulk-verify a CSV export#
If you already have a base full of contacts, or you'd rather clean on a schedule than run a script per row, go in batches. This is also the right call when a per-record automation would burn through your plan's run quota.
- Export a view to CSV. In the grid, open the view menu → Download CSV (or select a filtered view first so you only export the rows you care about). You'll get one row per record with the email in its own column.
- Run the file through bulk verification and let Qualisend apply the full pipeline — MX, SMTP, and the disposable / role / catch-all flags — across every row.
- Download the annotated file. Each address comes back with a
status, areasoncode, and a 0–100score. - Re-import to Airtable. Bring the cleaned CSV back in, matching on the email column, to backfill a status field across the base. Then suppress the undeliverables before your next send and handle the risky rows with care — the end-to-end routine is in how to clean an email list.
Bulk is the right tool for a backlog, but it's cleanup, not prevention: an address you catch here has usually already been sitting in your base. Pair a periodic bulk pass with the Path 1 automation so new bad addresses are flagged the moment they arrive.
Acting on the verdict#
Whichever path delivers the result, the shape is the same — a status, a
reason, a score, and the sub_flags. Map each to an action:
| Result | What to do in Airtable |
|---|---|
deliverable | Accept — let the record flow into your sync, list, or send. |
undeliverable | Suppress. Filter it out of your send view; check the reason
to see whether it's a bad domain or a dead mailbox. |
risky / catch-all | Accept but segment into its own view. A catch-all domain can't confirm the individual mailbox, so send cautiously. |
unknown | Re-check later — the infrastructure didn't answer, so never drop a real contact over it. |
disposable sub-flag | Reject or tag, depending on how strict your funnel is — see role, disposable & free addresses. |
Because the verdict lives in a field, everything downstream becomes a plain
Airtable filter — a "clean list" view of Email status = deliverable, a suppression
view for undeliverable. For the full picture of how the pipeline reaches each
status, see how email verification works.
Frequently asked questions#
Is there a native Qualisend integration for Airtable?#
Not right now. Qualisend's native platform integrations are being rebuilt, so there's no one-click extension to install from Airtable yet — it's on the roadmap. Until it ships, the supported way to verify emails from Airtable is the built-in Run a script automation action pointed at the Qualisend API, exactly as this guide describes. That approach is also more flexible: you control the request, the field write-back, and the trigger conditions.
Do I need a paid Airtable plan to verify emails automatically?#
You need automations, which every plan includes — but the number of automation runs is capped by your tier, and each verified record uses one run. On the free plan a per-record script is fine for low volume; at scale, either move to a plan with more runs or lean on the bulk CSV path, which verifies a whole export in one job instead of one run per row.
Can Airtable verify email addresses on its own?#
Only the format. Airtable's Email field type confirms an address is well-formed
— it has an @ and a domain — but it doesn't resolve MX records or probe the
mailbox, so a typo'd or disposable address that looks valid still gets through.
Real verification needs the DNS and SMTP layers a service like Qualisend adds on
top of the format check.
Should I use the automation script or the CSV export?#
Use the script when timing matters — you want each address verified and tagged the moment its record is created. Use the CSV export when you're cleaning a backlog, running periodic hygiene, or watching your automation run quota. Most teams do both: the script keeps new records clean, and an occasional bulk pass catches anything that slipped through or aged out.
Ready to wire it up? Grab a scoped, verify-only key and the exact request format in the developer docs, sanity-check a single address in the free email checker, or start with the 100 free credits on every plan to test both paths end to end before you commit.