Airtable automations: do the emails actually reach anyone?

Airtable automations are an easy win for small teams: a record changes, an email fires, a human gets notified. The whole thing configures in four clicks. The problem is that the Airtable run log shows "Success" the moment the mail server accepts the message, and from that moment on the team assumes the email reached the recipient. It often does. Sometimes it doesn't, and you find out a week later because a deal stalled.

How Airtable sends email

The native "Send email" automation action sends through Airtable's own mail infrastructure. TheFrom header looks like automations@airtable.com with a Reply-To you can customise. Important consequences:

• You do not own the sending domain. SPF / DKIM / DMARC are Airtable's. You cannot add your own DNS records to fix placement — there's nothing to add.
• You share reputation with every other Airtable base. Which means if another Airtable customer is abusing automations, your placement can slip without any change on your side.
• Branding is limited. The recipient seesAirtable-branded From, not your company. Gmail often reads this as bulk/automation by default.
• Rate limits apply. Airtable throttles automation email volume per workspace.

Why "Success" in the log is misleading

The Airtable run log shows "Success" when the downstream mail server accepted the handoff. That is not the same as:

• "The recipient's server accepted the message"
• "The message reached the Inbox"
• "The recipient saw it"

In reality, an Airtable automation email can pass the log and still land in Gmail's Spam or Promotions tab, be rejected by Microsoft 365 ATP as bulk, or be quarantined by a corporate gateway. The log doesn't know. Placement tests do.

Swap to SMTP via Zapier or Make

When native placement isn't good enough — especially for anything that looks like outreach, reminders, or onboarding — the fix is to route the email through your own sending identity via a proper ESP. The simplest path doesn't require leaving your existing Airtable base.

1. In Airtable, change the automation from Send email toRun a script or Send to Zapier / Make webhook.
2. In Zapier / Make, the next step is Send email via SMTP or Send email via SendGrid / Postmark / Mailgun / SES.
3. Configure that ESP with your own domain, SPF, DKIM, and a DMARC record.
4. The email now goes out withFrom: hello@yourdomain.com instead ofautomations@airtable.com — and you own the reputation.

; DNS for the new sending domain (SendGrid example)
; SPF — merged with any existing record
yourdomain.com.  TXT  "v=spf1 include:sendgrid.net ~all"

; DKIM — provided by SendGrid in the setup wizard
s1._domainkey.yourdomain.com.  CNAME  s1.domainkey.u12345.wl.sendgrid.net.
s2._domainkey.yourdomain.com.  CNAME  s2.domainkey.u12345.wl.sendgrid.net.

; DMARC
_dmarc.yourdomain.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

This approach costs you one webhook call and a small ESP bill, and it returns: owned domain reputation, per-message placement data, DMARC reports, bounce handling, suppression lists — the whole set of things a real mail system gives you.

When native Airtable email is fine

Native send-email is genuinely adequate for:

• Internal notifications where the recipient is your own colleague, not a customer.
• One-off admin alerts ("a record changed, check it").
• Low-volume, low-stakes reminders where Promotions tab is acceptable.

It is not fine for: customer-facing confirmations, onboarding sequences, billing alerts, outreach, or anything where the cost of a spam-folder landing exceeds the cost of one Zapier step.

Seed-test through a dummy record

1. Create a dummy row in the table that triggers the automation. Use seed-mailbox addresses in the "recipient" field — one per major provider.
2. Let the automation fire. Watch the run log for "Success" — expected.
3. Check each seed inbox for placement: Inbox, Promotions, Spam, or no-delivery.
4. Read the headers. For native Airtable sending, look for the Airtable DKIM signature. For custom SMTP, look for your own.
5. Repeat once you switch paths, so you have an apples-to-apples comparison.

Short checklist

1. Decide per-automation: is this internal-low-stakes or customer-facing?
2. Customer-facing automations route through Zapier / Make → ESP with your own domain.
3. Own-domain SPF / DKIM / DMARC are in place before go-live.
4. A seed test has actually been run on the flow — don't trust the run log.
5. Re-run the seed test quarterly. Placement drifts on shared infrastructure.

FAQ