Back to blog
Security

Blocking Disposable Emails in OpenClaw

Josselin Liebe
Josselin Liebe

OpenClaw makes it easy to build automated workflows that process user data. If any step in your workflow collects or uses an email address - a lead form, a signup trigger, a webhook from another tool - that email may be disposable. This guide shows how to add a disposable email check directly inside an OpenClaw workflow using the Veille API.

Why this matters in automation workflows

When a workflow processes a disposable email address, several things can go wrong downstream:

  • Outreach sequences send emails to inboxes that no longer exist, increasing bounce rates.
  • CRM records fill up with contacts that will never convert.
  • Trial provisioning and referral credits are triggered for fake accounts.
  • Reporting becomes inaccurate because fake signups are counted as real leads.

Catching the issue at the workflow level - before any of those steps run - is simpler than cleaning up the data afterward.

For a deeper look at how disposable emails are used in account fraud, see How disposable emails are used in account fraud.

How the check works

The Veille Email Validation API accepts a single email address and returns a structured response that includes:

  • disposable - true if the domain is a known disposable provider
  • risk_score - a score from 0 (safe) to 100 (high risk)
  • dns.mx - whether the domain has a configured mail server
  • smtp_valid - whether the specific inbox can receive email

A single HTTP GET request is all that is needed. No SDK, no library. Any OpenClaw HTTP node can make this call.

Setting up the workflow in OpenClaw

Step 1 - Trigger

Start with any trigger that provides an email address. Common sources:

  • Form submission (webhook or native form trigger)
  • CRM event (new contact added)
  • Webhook from a third-party tool such as Stripe, Typeform, or Notion

The trigger output should include an email field that you can reference in later steps.

Step 2 - HTTP Request node (Veille API call)

Add an HTTP Request node and configure it as follows:

Field Value
Method GET
URL https://api.veille.io/v1/intelligence/email
Query parameter - query {{trigger.email}} (your email variable)
Header - x-api-key Your Veille API key

The node returns a JSON response. The fields you need most are disposable and risk_score.

Step 3 - Condition node

Add a Condition node after the HTTP Request. Set up the following logic:

IF disposable == true  →  Branch: Block
IF risk_score >= 75    →  Branch: Block
ELSE                   →  Branch: Continue

You can use a single condition with OR logic, or two separate branches depending on how your OpenClaw version handles conditions.

Step 4 - Block branch

In the block branch, choose what happens to rejected entries:

  • Stop the workflow with no further action (simplest option)
  • Add a tag or label to the contact in your CRM to mark it as invalid
  • Move the record to a separate list or spreadsheet for manual review
  • Send an internal notification so your team is aware of the activity

Step 5 - Continue branch

In the continue branch, the workflow proceeds normally: provision the account, send the welcome email, update the CRM, notify the team, or whatever your normal flow does.

Graduated response using risk_score

The disposable field catches known disposable providers. The risk_score adds coverage for domains that are not on any blocklist but show suspicious signals - newly registered domains, missing mail servers, unusual patterns.

A graduated approach based on risk_score:

risk_score Action
0–49 Continue normally
50–74 Continue, add a review flag
75–100 Block

This avoids hard blocking every borderline case while still removing the most obvious risk.

Handling privacy relay addresses

Services like Apple Hide My Email, Firefox Relay, SimpleLogin, and addy.io generate forwarding addresses that may look unusual. These belong to real users who have chosen to protect their privacy.

To avoid blocking them by mistake, add a Condition node before the Veille API call that checks whether the domain matches a known privacy relay:

IF email domain is one of:
  privaterelay.appleid.com
  relay.firefox.com
  simplelogin.co
  addy.io
  anonaddy.com
→ Skip the Veille check and go directly to Continue

The Veille API also assigns low risk_score values to addresses from known privacy relay providers, so even without a manual allowlist, they are unlikely to be blocked by the score threshold.

Full workflow structure

[Trigger: form / webhook / CRM event]
        ↓
[Condition: is domain a privacy relay?]
   YES ↓            NO ↓
[Continue]   [HTTP Request: Veille API]
                     ↓
            [Condition: disposable OR risk_score ≥ 75?]
               YES ↓            NO ↓
            [Block branch]   [Continue branch]

Example API response

When you call the Veille API for a disposable address, you receive something like this:

{
  "email": "user@mailinator.com",
  "disposable": true,
  "risk_score": 95,
  "role_account": false,
  "dns": {
    "mx": true
  },
  "smtp_valid": false
}

For a legitimate address:

{
  "email": "contact@example.com",
  "disposable": false,
  "risk_score": 12,
  "role_account": false,
  "dns": {
    "mx": true
  },
  "smtp_valid": true
}

Common use cases in OpenClaw

Lead enrichment workflow - a contact is added to your CRM from a form. Before the contact goes into your outreach sequence, check the email with Veille. Only contacts with disposable: false and risk_score < 75 enter the sequence.

Trial signup automation - a new user signs up for a free trial. The signup webhook triggers an OpenClaw workflow that calls Veille. If the email is disposable, the provisioning step is skipped and the record is flagged.

Referral program processing - a referral submission is received. Before the referral credit is applied, Veille checks the email. High-risk emails trigger a manual review instead of automatic credit.

Waitlist validation - a batch workflow runs on your waitlist before your launch. Each email is checked against the Veille API. Disposable entries are moved to a separate sheet before invites are sent.

Related articles