How to Send Email From Bouncer With Volanea

Bouncer is an email-verification platform, not an event-driven email sender—but you can still send email from Bouncer verification workflows with Volanea. The reliable pattern is to let a form, CRM, or database event start the automation, use Bouncer to verify the address, and only then send through Volanea when the verification result meets your policy.

The important limitation: Bouncer does not trigger outbound email sends

There is no native Volanea app, marketplace listing, or direct outbound-webhook configuration in Bouncer that can call Volanea after a verification completes. Bouncer’s public API is designed for verification requests and results, including real-time single-email verification, asynchronous batch verification, and batch/sync processing. (docs.usebouncer.com)

That changes what “send email from Bouncer” means in practice. Bouncer is the verification step in the workflow, not the source of a lifecycle event such as a record created, form submitted, or deal stage changed.

The concrete trigger must come from the system where the email address first appears. For example:

1. A visitor submits a lead form.
2. Your form tool sends the submission to a Make custom webhook.
3. Make runs Bouncer’s Verify Single Email module against the submitted email address.
4. A filter allows only approved Bouncer results through.
5. Make posts the approved result to your server-side relay.
6. The relay calls POST https://api.volanea.com/v1/send to send the transactional email.

Make’s Bouncer app provides modules including Verify Single Email, Check Credits, and Make an API Call. Its published module list does not identify a Bouncer “new verification completed” trigger, so do not build this around an assumed Bouncer event or webhook. (apps.make.com)

This architecture is useful because it makes the actual business event explicit. The form submission, CRM record, ecommerce order, or application signup starts the flow. Bouncer contributes the verification decision. Volanea sends the message only after that decision has been evaluated.

The recommended Bouncer-to-Volanea architecture

The safest production design has three boundaries:

• The event source owns the original customer action, such as a submitted signup form.
• Make orchestrates Bouncer verification and applies routing rules.
• A server-side relay owns the Volanea secret key, idempotency logic, message construction, and audit trail.

This avoids treating an email-verification result as a marketing consent record. A Bouncer result can tell you whether an address appears deliverable; it cannot establish whether the person opted into a campaign, whether the message is legally permitted, or whether the message is relevant to the event that produced the address.

For transactional messages, a typical policy is straightforward: send a signup confirmation, account-access link, or requested resource only when the form submission has a valid transaction context and the Bouncer result is acceptable. For promotional or nurture email, require a separate consent field and retain the consent record in your source system.

Bouncer’s real-time verification endpoint returns the best result it can gather within the selected timeout. Bouncer documents that the real-time method is intended for synchronous checks and can produce more unknown outcomes than a full batch integration. (docs.usebouncer.com) That means your workflow needs an explicit policy for unknown, not just a yes-or-no filter.

Why use a relay rather than call Volanea directly from Make?

You can make an HTTP request from Make, but putting the Volanea secret directly in an automation step expands access to anyone who can inspect or edit that scenario. A relay lets you keep the credential in a server-side environment variable, limit what Make is allowed to submit, and issue one stable idempotency key per customer event.

It also creates a clean place to add business controls that are awkward in a visual workflow:

• Verify a signed request from your automation platform.
• Reject unrecognized message types.
• Ensure the recipient comes from an approved field.
• Escape untrusted form values before placing them in HTML.
• Store a durable send ledger before calling the email API.
• Return a quick response to Make while longer work happens in a queue.

Volanea’s REST API uses the https://api.volanea.com base URL, its single-message endpoint is POST /v1/send, and safe retries are supported with the Idempotency-Key header. (volanea.com)

What actually triggers the workflow

Because Bouncer does not provide the outbound trigger for this use case, choose a trigger from the system that collects the address. The most common pattern is a form submission.

For a website form, the event is:

A form submission is received by a Make custom webhook.

That is the trigger that starts the scenario. The initial webhook payload might look like this:

{
  "eventId": "signup_01JQ8Y0D7RFD2M9Q3K4X",
  "eventType": "newsletter_request",
  "submittedAt": "2026-09-30T14:08:31.021Z",
  "email": "alex@example.com",
  "firstName": "Alex",
  "consent": true,
  "source": "pricing-page-form"
}

The Make scenario then maps email into Bouncer’s Verify Single Email module. Bouncer performs the check and returns a verification object. The real-time Bouncer response shape includes email, status, reason, domain information, account information, DNS details, provider, score, toxicity status, and toxicity value. (docs.usebouncer.com)

An example response is:

{
  "email": "alex@example.com",
  "status": "deliverable",
  "reason": "accepted_email",
  "domain": {
    "name": "example.com",
    "acceptAll": "no",
    "disposable": "no",
    "free": "no"
  },
  "account": {
    "role": "no",
    "disabled": "no",
    "fullMailbox": "no"
  },
  "dns": {
    "type": "MX",
    "record": "mx.example.com."
  },
  "provider": "example-mail-provider.com",
  "score": 100,
  "toxic": "unknown",
  "toxicity": 0
}

That object is a Bouncer API result, not an outbound Bouncer webhook payload. In Make, it becomes output data from the Bouncer module that later steps can map into a filter and an HTTP request.

A practical filter policy

Do not filter on only one field unless your policy is deliberately simple. For a form-confirmation email, a conservative filter could require:

• status equals deliverable.
• account.disabled does not equal yes.
• The original event has the required consent or transactional context.
• The original email equals Bouncer’s returned email after normalization.
• Your source event has not already been processed.

Be careful with acceptAll domains. An accept-all configuration can mean the destination domain accepts mail for unknown local parts, so it is weaker evidence of mailbox existence than a direct acceptance result. It does not necessarily mean “never send”; it means your business rule should treat the address with the appropriate level of caution.

For unknown, choose one of these policies before launch:

• Strict: do not send; ask the person to correct or confirm the address.
• Transactional fallback: send only the requested transactional message, then monitor bounces.
• Deferred review: store the submission and attempt batch verification later.
• Risk-based: permit the message only if the event is high-intent and the address otherwise passes your own fraud and consent checks.

Build the Make scenario step by step

The exact source module differs by form or CRM, but the core scenario remains the same.

Step 1: Receive the originating event

Start with the app that owns the event. A web form commonly uses a Make custom webhook. A CRM can use its own “record created” or “contact updated” trigger. An ecommerce tool can start from an order-created event.

Capture an immutable identifier at this stage. If your source does not provide one, generate one before sending to Make. This identifier becomes the seed for your idempotency key and lets you distinguish a real new request from a repeated delivery of the same event.

At minimum, carry these fields through the scenario:

source event ID
email address
customer or contact ID, if available
first name, if collected
message type
consent or transactional reason
submission timestamp
source name or form name

Do not use a person’s email address alone as the idempotency key. Someone may legitimately request a second login link, a second receipt, or another copy of a confirmation. The key must identify the business event, not merely the recipient.

Step 2: Add Bouncer’s Verify Single Email module

Create a Bouncer connection in Make using a Bouncer API key. Make’s Bouncer documentation says that its connection requires an active Bouncer account and API key; Bouncer’s own quick-start documentation describes generating the key from the API area and authenticating API calls with the x-api-key header or HTTP Basic authentication. (apps.make.com)

Map the inbound email field to Verify Single Email. Keep the Bouncer key scoped to verification only; it should not be confused with the Volanea sending key.

Use test addresses and non-production message routes while building. Verification behavior can vary by mailbox provider and destination configuration, so a successful test proves your mapping works, not that every real-world address will receive the same status.

Step 3: Filter on Bouncer output and business rules

Place a filter after the Bouncer module. This is where you join technical verification and business eligibility.

A good filter names the decision rather than hiding it in a complex expression. For example, conceptually:

Send requested confirmation only when:
- original consent is true
- Bouncer status is deliverable
- Bouncer account is not disabled
- source event ID exists
- event has not been sent already

The final condition should not rely only on Make execution history. Store the event ID in your database, key-value store, or relay’s send ledger. Automation histories expire, can be replayed, and do not always provide the durable semantics you need for customer-facing messages.

Step 4: Post an approved payload to your relay

Send a small, explicit payload to the relay—not the entire raw form submission and not a Volanea API key. Include Bouncer fields that are genuinely useful for a decision audit.

{
  "eventId": "signup_01JQ8Y0D7RFD2M9Q3K4X",
  "messageType": "newsletter-confirmation",
  "recipient": {
    "email": "alex@example.com",
    "firstName": "Alex"
  },
  "consent": true,
  "bouncer": {
    "email": "alex@example.com",
    "status": "deliverable",
    "reason": "accepted_email",
    "score": 100,
    "acceptAll": "no",
    "disposable": "no",
    "disabled": "no",
    "toxic": "unknown",
    "toxicity": 0
  }
}

The relay should reject a payload if recipient.email and bouncer.email do not agree after trimming whitespace and normalizing the domain portion. This protects against accidental mapping errors where a verification result for one address is used to send a message to another.

The working Volanea send call and field mapping

Volanea’s send endpoint accepts authenticated JSON requests at POST /v1/send. The API uses a Bearer secret key, JSON content, and supports Idempotency-Key to make retries safe. (volanea.com)

The following Cloudflare Worker-style relay receives the mapped Make payload, enforces the verification policy again, and sends a confirmation through Volanea. Store VOLANEA_API_KEY as a server-side secret, not in browser code, a form configuration, or the visible payload that travels through the workflow.

export default {
  async fetch(request, env) {
    if (request.method !== "POST") {
      return new Response("Method Not Allowed", { status: 405 });
    }

    // Optional but recommended: authenticate Make to this relay.
    const relayToken = request.headers.get("x-relay-token");
    if (!relayToken || relayToken !== env.MAKE_RELAY_TOKEN) {
      return new Response("Unauthorized", { status: 401 });
    }

    const input = await request.json();
    const recipientEmail = String(input?.recipient?.email || "").trim();
    const verifiedEmail = String(input?.bouncer?.email || "").trim();
    const firstName = String(input?.recipient?.firstName || "there").trim();
    const eventId = String(input?.eventId || "").trim();

    const approved =
      input?.messageType === "newsletter-confirmation" &&
      input?.consent === true &&
      input?.bouncer?.status === "deliverable" &&
      input?.bouncer?.disabled !== "yes" &&
      recipientEmail &&
      verifiedEmail &&
      recipientEmail.toLowerCase() === verifiedEmail.toLowerCase() &&
      eventId;

    if (!approved) {
      return Response.json(
        { accepted: false, reason: "Verification or message policy failed" },
        { status: 422 }
      );
    }

    // In production, write eventId to a durable send ledger before the API call.
    // If it already exists for this message type, return the stored result instead.
    const idempotencyKey = `newsletter-confirmation:${eventId}`;

    const volaneaResponse = await fetch("https://api.volanea.com/v1/send", {
      method: "POST",
      headers: {
        "Authorization": `Bearer ${env.VOLANEA_API_KEY}`,
        "Content-Type": "application/json",
        "Idempotency-Key": idempotencyKey
      },
      body: JSON.stringify({
        from: "Updates <updates@notifications.example.com>",
        to: [recipientEmail],
        subject: "Confirm your email address",
        text: `Hi ${firstName},\n\nPlease confirm that you want to receive updates.\n\nIf you did not request this, you can ignore this email.`,
        html: `<p>Hi ${escapeHtml(firstName)},</p><p>Please confirm that you want to receive updates.</p><p>If you did not request this, you can ignore this email.</p>`
      })
    });

    const responseBody = await volaneaResponse.text();

    return new Response(responseBody, {
      status: volaneaResponse.status,
      headers: { "Content-Type": "application/json" }
    });
  }
};

function escapeHtml(value) {
  return value.replace(/[&<>'"]/g, character => ({
    "&": "&amp;",
    "<": "&lt;",
    ">": "&gt;",
    "'": "&#39;",
    "\"": "&quot;"
  }[character]));
}

The field mapping in that code is deliberate:

Use a sending address from a domain you have authenticated in Volanea before testing with real recipients. Volanea’s documentation describes adding and verifying sending domains and returning the required DNS records for the configured sending domain. (volanea.com) For endpoint details, authentication, and supported message fields, use the Volanea API reference and setup guides.

Where the Volanea API key belongs

The Volanea API key does not belong in Bouncer. Bouncer has no native outbound Volanea integration or webhook setting where that credential should be stored.

It also should not live in:

• Front-end JavaScript.
• A publicly visible form configuration.
• A mobile application bundle.
• A Git repository.
• An email template.
• The JSON payload posted from a browser to Make.
• A Bouncer custom field or uploaded list.

Volanea requests authenticate with Authorization: Bearer <key>, and Volanea’s documentation explicitly treats that secret as a credential that can send mail from your account. (volanea.com) Anyone who obtains it could potentially send messages using your sending configuration.

Put the key in a server-side secret store. In the example above, that is the Worker secret named VOLANEA_API_KEY. The Make scenario stores only a separate relay authentication token, such as MAKE_RELAY_TOKEN, which is limited to calling your relay. If that token leaks, you can rotate it without granting the attacker direct access to Volanea.

This separation has a second benefit: the relay can allow only a short list of message types. Even if someone gets access to the Make scenario, they cannot turn the flow into an arbitrary email-sending console if the relay only accepts newsletter-confirmation and refuses all other message types.

When this breaks: Bouncer, Make, and email delivery failures

Every automation that crosses multiple services can fail in more than one place. Treat the Bouncer-to-Volanea route as an at-least-once workflow: a step can be repeated after a timeout even when the previous request actually succeeded.

Retries can create duplicate sends

A webhook client may retry when it does not receive a response quickly. Make can retry failed work. Your relay can time out while Volanea has already accepted the request. Without idempotency, each retry may create another customer email.

Use the same Idempotency-Key for every retry of the same logical message. Volanea documents this header specifically for safe retries; a repeated key replays the stored response instead of creating another send. (volanea.com)

The key should include both a stable event identifier and the message type. For example:

newsletter-confirmation:signup_01JQ8Y0D7RFD2M9Q3K4X

Do not include the current time, Make execution ID, or random UUID in the retry key. Those values differ on each attempt and defeat deduplication.

Webhook and relay timeouts

The event source may retry if Make takes too long to acknowledge the form submission. Make may consider a relay call failed if your relay waits on a slow downstream request. Bouncer’s real-time API itself can take time because verification depends on remote mail infrastructure; Bouncer documents real-time verification with a default timeout of 10 seconds and a maximum of 30 seconds. (docs.usebouncer.com)

The practical answer is to keep the browser-facing path fast. Return a success response after the submission has been safely recorded, then verify and send asynchronously. If your product needs an immediate answer—such as blocking an obviously invalid address at signup—call Bouncer in the server-side form handler, but still separate the user-facing response from the eventual send operation.

For higher-volume imports, do not force every address through a long sequence of synchronous runs. Bouncer provides batch and batch/sync paths, and its integration guidance discusses handling batch status and results separately. (docs.usebouncer.com) Queue the sendable results after the batch completes rather than holding an HTTP request open while a large list is verified.

Payload fields may be absent, changed, or unavailable in a connector

Do not assume every Bouncer-related field appears in every automation context. The Make Bouncer module documentation names the supported modules, but it is not a guarantee that every output field from every Bouncer endpoint will always be exposed as an individually mappable token. (apps.make.com)

Your relay should therefore treat risk fields as optional unless your policy requires them. For example, score, toxicity, acceptAll, or account metadata may be missing, represented differently, or not applicable to a particular workflow. Use defaults deliberately:

• Require email and status for any send decision.
• Require consent or a transactional event reason from the source system.
• Treat missing optional risk data as “not evaluated,” not as a safe value.
• Log the raw verification response only if your privacy policy permits it.
• Version your relay payload so changes can be introduced safely.

A simple schema version protects you from accidental breakage:

{
  "schemaVersion": 1,
  "eventId": "signup_01JQ8Y0D7RFD2M9Q3K4X",
  "messageType": "newsletter-confirmation"
}

When you later add a field or change a policy, the relay can support both versions while you update scenarios.

The address verified, but the email was not delivered

Verification and delivery are separate outcomes. Bouncer’s result helps decide whether an address is suitable to attempt. It does not prove that a later message was accepted by the receiving provider, landed in the inbox, or was read.

A successful API response also should not be interpreted as inbox placement. Track Volanea delivery events, bounces, complaints, and suppressions in your application. If a recipient hard-bounces, let the sending platform’s suppression handling protect future sends and update your own contact state so you do not keep feeding the same bad address back into Bouncer and Volanea.

Your filter sends mail without valid consent

This is a logic failure, not an API failure. A Bouncer deliverable status is not permission to send marketing email. Maintain consent and purpose fields in the original source. In the relay, require the exact message type and consent state appropriate for that message.

For example, a password reset does not require marketing consent but does require a valid password-reset request. A newsletter confirmation needs an opt-in context. A receipt needs an order reference. Keeping these distinct prevents a “verified email” field from becoming an overly broad authorization signal.

Operational checks before you turn the flow on

Run a small controlled test matrix before putting the automation in production. Use a dedicated test sender and a small number of internal addresses.

Test at least these cases:

1. A deliverable address with valid consent sends exactly one message.
2. An undeliverable address does not send.
3. An unknown result follows your documented fallback rule.
4. A disabled address does not send.
5. A payload whose original and verified emails differ is rejected.
6. The same event submitted twice produces one logical Volanea send because of the idempotency key.
7. A relay timeout followed by a retry does not create another message.
8. A missing optional Bouncer field does not silently turn into an approval.
9. An invalid relay token receives a 401 response.
10. A Volanea API failure is logged with the source event ID and can be retried safely.

Keep a correlation ID across all hops. The best candidate is the originating event ID. Add it to structured logs, your send ledger, Make execution notes where appropriate, and any internal support tooling. When a customer says “I got two confirmations,” you should be able to answer whether the duplicate came from the source event, the automation retry, the relay, or the sending API.

Also review sending volume before launch. An address-verification workflow can suddenly produce far more messages when a bulk import, CRM migration, or broken form resubmits old contacts. Review transactional email pricing and sending limits alongside your expected traffic, then apply source-side rate limits and relay-side message-type limits.

Alternatives to the Make middleware route

Make is a sensible route when your event source already connects to Make and your team wants a visual workflow. Bouncer publishes a Make integration, and Make provides Bouncer verification modules for connected scenarios. (usebouncer.com)

It is not the only valid design.

Call Bouncer and Volanea from your own backend

If you control the form or application server, the cleanest approach is often direct server-side code:

1. Receive the signup or account event.
2. Call Bouncer’s real-time verification API.
3. Apply your policy in code.
4. Queue the Volanea message with a stable idempotency key.
5. Process delivery events back into your database.

This reduces the number of systems in the critical path and gives you stronger access control. It also means you own retry handling, observability, and operational maintenance.

Use batch verification for imported lists

For a large CSV, CRM export, or data-cleaning job, do not turn every row into an immediate transactional send. Submit the list through Bouncer’s batch workflow, obtain the completed results, select records that satisfy your policy, and then enqueue messages through Volanea in controlled batches. Bouncer’s batch result endpoint returns JSON records containing the verification fields needed for a downstream decision. (docs.usebouncer.com)

This approach is safer for campaigns because it creates a review point between verification and sending. It also lets you reconcile counts: submitted addresses, duplicate inputs, deliverable results, suppressed recipients, queued messages, accepted sends, and final delivery events.

Use the verification result as enrichment, not an immediate send trigger

Sometimes the best action after verification is not email. You may update a CRM contact property, flag a record for review, prevent a sales sequence from enrolling the contact, or prompt the visitor to correct the address. This is especially appropriate for unknown, accept-all, disposable, or high-risk cases.

The central principle is simple: let Bouncer determine address quality, then let your business workflow decide what the next action should be. Volanea is the sending component only when that action is a permitted and useful email.

Conclusion

To send email from Bouncer workflows with Volanea, do not look for a nonexistent direct Bouncer outbound webhook or native Volanea plugin. Start from the real event in your form, CRM, or application; run Bouncer verification in Make; filter the result against consent and message rules; and pass an approved, minimal payload to a server-side relay.

That relay should keep the Volanea secret key private, validate the mapping, construct the message, and send through POST /v1/send with a stable Idempotency-Key. The extra boundary is worth it: it gives you safer credentials, fewer duplicate messages, clearer logs, and a workflow that treats verification as one important signal rather than a substitute for permission or delivery tracking.

FAQ

Can Bouncer send an email directly to Volanea?

No. Bouncer is an email-verification service, and its documented API and Make modules focus on verification operations rather than a native Volanea sending action or outbound result webhook. Use an event source plus Make and a relay, or call both services from your own backend. (docs.usebouncer.com)

What is the Bouncer trigger for this automation?

There is no Bouncer verification-completed trigger to use as the starting event in this setup. The trigger is the originating event, such as a form submission received by a Make custom webhook, a CRM contact creation, or an application signup. Bouncer is the verification action that follows.

Should I send when Bouncer returns unknown?

It depends on the message and your risk policy. For marketing email, the safer default is not to send until you have a stronger result. For a requested transactional message, you may choose to attempt delivery, but you should document that choice and monitor bounces. Bouncer notes that real-time verification can produce more unknown results than full batch processing. (docs.usebouncer.com)

Where should I store the Volanea API key?

Store it only in a server-side secret manager or runtime secret, such as VOLANEA_API_KEY in your middleware environment. Do not put it in Bouncer, browser code, a public form, or a client-visible Make payload. Volanea uses Bearer authentication, so the key must be handled like a password that can send mail. (volanea.com)

How do I stop duplicate emails when Make retries?

Build an idempotency key from a stable source event ID and message type, then send it as Volanea’s Idempotency-Key header. Reuse that exact key on every retry of the same logical message. (volanea.com)