RealMail

RealMail is a single-endpoint email verification API built for SaaS signup flows. Agents check an address at signup and act on the verdict before a fake or disposable email gets into your user base.

Verified 1 action API key available

RealMail website Platform Documentation Capability data verified 2026-08-19

A signup form posts a new account request

Validate Email checks the address and returns every signal behind the verdict

Agent reads the MX record, the active website flag, and the disposable, role and free provider flags

Agent compares the typed domain against the suggestion field for a near miss

Agent posts the held signup to the growth channel with both spellings side by side

An operator decides whether to mail the address as typed, mail the correction, or reject the signup

What This Integration Enables

RealMail ships one action, and that is a position rather than a gap. It is built for the single moment where an address enters your system and you still have the option of not accepting it. FlowRunner agents call it inline at signup, at form submission, or at the point an address is imported from somewhere you do not control, and then act on what comes back instead of waiting for a bounce report to tell them the same thing weeks later.

What makes this connector worth reasoning about carefully is that the headline verdict is not a property of the address. RealMail resolves it against rules you configure in your own dashboard, so the same address can pass today and fail after somebody tightens a toggle. The response carries the underlying signals as well: whether the format holds up under RFC 5322, whether the domain has an MX record and a live website, whether the address is disposable, role based or from a free provider, and a suggested spelling when the domain looks like a typo. Agents that read the signals can carry their own policy in the flow, which is exactly where a policy belongs when different signups deserve different answers. The judgment calls that follow are where FlowRunner's human-in-the-loop design does its work.

Without FlowRunner

Fake addresses walk in The form accepts whatever is typed, and the problem surfaces later as a bounce or an unreachable trial

Typos become lost accounts A near-miss domain looks like a real address, and nobody notices until the welcome email goes nowhere

One rule for every signup A free-provider address on a trial and a role address from a large buyer get treated identically

With FlowRunner

The verdict arrives at the door Every address is checked before the account exists, with the reason recorded next to it

Corrections are surfaced, not applied A suggested domain becomes a question for a person instead of a silent rewrite

Signals route the signup Disposable, role and free provider flags send different signups down different paths

Use Case Scenarios

A signup gate that does not punish real customers

A trial signup arrives. The agent calls Validate Email, and the address comes back with valid syntax, a live MX record, and the disposable flag set. Instead of a blanket rejection, the agent checks the plan being requested. Free trials on a disposable domain are refused with a message telling the visitor to use a work address. Anything attached to a paid intent is held and posted to Slack so a person can look at it. Clean addresses continue: the agent writes the contact into HubSpot, records the signals alongside the record, and the welcome sequence fires.
Cleaning an inherited address column before it costs you

An operations team inherits a table of addresses collected over three years from event forms and spreadsheets. A scheduled agent walks the table in PostgreSQL, calls Validate Email on each row, and writes the verdict, the MX result and the disposable and role flags back as columns rather than deleting anything. The result is a table someone can filter and reason about, not a shorter table with no explanation. Rows flagged as role addresses stay, because a shared billing inbox is often the right contact for an invoice even when it is the wrong contact for a newsletter.
Protecting a payment flow from a wrong receipt

A checkout in Stripe captures an address for the receipt. Before the order confirmation goes out, the agent validates it. When the domain has no MX record at all, the receipt will not arrive no matter how many times it is retried, so the agent flags the order for the support queue instead of quietly failing. When the suggestion field names a near miss, the agent does not correct it. A receipt carries order details, and mailing them to a guessed address is a decision about somebody else's data.

Human-in-Loop Highlight

The suggestion field is the moment worth stopping for. When a visitor types @gmial.com, RealMail names the likely correction, and an agent that acts on it directly is rewriting an address a real person entered and then sending account credentials, a magic link, or a receipt to the corrected version. If the guess is wrong, that mail reaches a stranger, and there is no version of that outcome you can retract. So the agent holds the signup and posts what it has: "Signup from Priya Raman typed p.raman@northwid.co. RealMail suggests northwind.co, which matches the company domain on the form. No MX record on the typed domain. Send the welcome to the typed address, the suggestion, or hold the account?" A person answers in seconds, because they can see the company name on the form and the agent cannot. The check runs on every signup. The rewrite of someone's identity does not.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

1 actions

Verification

Validate Email Checks one address and returns the verdict together with the signals behind it: RFC 5322 syntax, whether the domain has an MX record and an active website, and the disposable, role based and free provider flags. A likely domain typo comes back in the suggestion field. Because the verdict itself follows rules set in your RealMail dashboard, flows that need their own policy read the signals rather than the headline answer.

Frequently Asked Questions

What can FlowRunner do with RealMail?

FlowRunner agents can run Validate Email in RealMail.

Does connecting RealMail to FlowRunner require OAuth?

No. RealMail connects to FlowRunner with an API key, no OAuth flow required.

Can RealMail trigger a FlowRunner workflow automatically?

RealMail doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with RealMail

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us