Skip to content
Start with 100 free verification credits
Qualisend
Native connector: live

Verify every recipient before Mailjet's Send API ever touches it

Mailjet automatically blocks an address once it hard-bounces or draws a spam complaint, holding it back for 90 days so it can't fail twice - but for a transactional sender that protection only fires after the first bad send, and the first send is exactly where the reputation damage is done. Because Mailjet is an API/SMTP sender, the leverage for transactional mail is verifying every address before the Send API ever touches it. Qualisend closes that gap: verify at the point of capture and again before any batch send, so an invalid address never reaches your sending in the first place. For contacts and lists stored in Mailjet, the native connector verifies them in place and saves each result as a contact property. Here's how, plus the API and no-code options.

MailjetQualisend
Native connector

Connect Mailjet directly, no CSV needed

Connect with an API key

Enter your Mailjet API key and Secret key. Find both in Mailjet under Account settings β†’ REST API β†’ API Key Management.

  • Clean all contacts or a single list
  • Results saved as properties on each contact
  • Or verify and export a clean list
  • Auto-clean every 7, 14 or 30 days
Connect Mailjet

Prefer CSV or the API? Both work too, see below.

Mailjet handles

What Mailjet cleans for you

Mailjet's native hygiene runs on its automatic block. The moment an address hard-bounces - an invalid or non-existent mailbox, or a server Mailjet can't deliver to - it's automatically "preblocked" and held out of every send for 90 days, the idea being to protect your sender reputation by never letting the same address fail twice; addresses that draw a spam complaint are preblocked the same way. That block is global to Mailjet's platform - an address that hard-bounced on another customer's send can be blocked for yours - and, crucially, it applies to everything, including the Send API, so once Mailjet has seen an address fail it won't be mailed again by your transactional stream either. Mailjet also offers a manual Campaign Exclusion List, but that one only holds contacts out of marketing campaigns and automations (automation emails count as marketing) - the Send API still delivers to an excluded address by design - so it does nothing to shield a transactional send. For addresses Mailjet has actually sent to and seen fail, that automatic block is reliable hygiene.

The gap it leaves

What it can't catch

The catch is that every one of those mechanisms is reactive - it needs a send, and then a bounce or complaint, to fire. Never-verified invalids from your signup and checkout forms, disposable addresses, role addresses, and mailboxes that have quietly decayed have never bounced because Mailjet has never sent to them, so there's no block on them - the Send API will happily deliver into a hard bounce on the very first attempt, and only then block the address for 90 days, after the damage is done. Transactional streams are the sharpest case: a password reset or receipt fires automatically to whatever the user typed, and the Campaign Exclusion List can't pre-empt it because it doesn't apply to the Send API. The only thing standing between a mistyped address and a first-send hard bounce is verification before the call.

Why a clean Mailjet list matters

Mailjet bills on the emails you send each month, not on how many contacts you store - its higher plans carry unlimited contacts - so a dead address doesn't inflate a contact tier the way it would on a subscriber-priced platform. The cost of a bad address here is twofold. First, the wasted send: every invalid you deliver to burns one of your monthly sends and, once you're over your allowance, bills as an overage at renewal - you're paying to hard-bounce. Second, and far more important for a transactional sender, is reputation. Transactional mail is your most reputation-sensitive stream - it rides a dedicated IP or a shared pool you depend on for password resets and receipts - and a spike of first-send hard bounces is exactly what Gmail and Yahoo's 2024 sender rules, and Mailjet's own bounce-rate limits, penalize. Push your bounce rate too high and Mailjet will throttle or block your sending outright; when that happens, it's your account emails, not a marketing blast, that stop reaching the inbox. Verifying before the send keeps the bounce off your record entirely.

Prefer CSV or the API? Here's the manual path

Mailjet is a transactional/API sender, and the connector covers only the contacts and lists stored in Mailjet - so for Send API traffic the honest path is to verify every address before the Send API touches it: in real time as it's captured, and again before any batch send.

1

Verify at the point of capture

Call the Qualisend REST API from your signup, checkout, or account form and check the address before it's written to your database. A mistyped or disposable address is rejected at the door, so it never becomes a recipient your app fires transactional mail at - this is the highest-leverage place to catch it.

2

Verify any batch before an API or SMTP send

Before a bulk or triggered send, run the recipient list through Qualisend - upload a file to bulk cleaning (up to 1,000,000 addresses per job, duplicates charged once) or loop it through the API. The free plan's 100 one-time credits, which never expire, cover a first sample.

3

Read the results

Every address returns deliverable, risky, undeliverable, or unknown with a reason code, a 0-100 score, and sub-flags (catch-all, disposable, role, full mailbox), plus the MX provider and probe detail as evidence.

4

Suppress the failures on your side

Add every undeliverable to your own do-not-send list in your app or database - that's what actually keeps it out of the Send API, since Mailjet's Campaign Exclusion List only stops marketing mail, not transactional. Add them to the Campaign Exclusion List too if they also sit in a marketing or automation audience. Suppress on your side and the address never reaches a send, so Mailjet's 90-day block never has to fire.

Or automate it at signup

The highest-leverage option is to verify at the point of capture with the Qualisend REST API - scoped keys, rate limits, and webhooks - so a bad address is caught before your app ever stores it or fires a transactional message at it. No developer time to spare? Wire the same check through Zapier, Make, or n8n so new signups are verified before they're written to your database or synced to Mailjet.

What Qualisend flags on every address

Native connector status

The native Mailjet connector is live. Connect it in Qualisend under Integrations and work with your Mailjet list directly, no CSV needed.

What to do with each result

Every address comes back with a verdict and sub-flags. Here's the action that keeps your Mailjet list clean without throwing away contacts you can still reach.

deliverableSend through the Send API as normal.
deliverable + role flagFine for transactional and system mail (info@, billing@); keep out of any marketing campaign or automation.
risky + catch-all flagSend only high-value transactional mail and watch the bounce webhook; hold back bulk and marketing.
risky + disposable flagAdd to your do-not-send list - the mailbox was built to expire, and a send to it is wasted.
unknownRetry-safe - keep it and re-verify next batch; usually greylisting or rate-limiting, not a verdict on the mailbox.
undeliverableAdd to your app's do-not-send list before it reaches the Send API; don't wait for Mailjet's 90-day block to fire after the bounce.

Mailjet verification FAQ

Yes. Connect Mailjet in Qualisend under Integrations with your API key and Secret key, then clean all your contacts or a single list, with results saved as properties on each contact. It works on stored contacts, not Send API recipients, so for transactional mail verify before the send - call the REST API at signup and before any batch send, or bulk-verify a recipient file.

Because the block is reactive. Mailjet only blocks an address after it hard-bounces on a real send, which means you've already spent the send and taken the reputation hit before the protection kicks in. For a transactional stream that first send is where the damage happens, so verifying before the call is the only way to keep a first-send invalid out of your sending at all.

No - and this trips people up. Mailjet's Campaign Exclusion List only holds contacts out of marketing campaigns and automations; the Send API still delivers to an excluded address by design. So suppressing a bad address for your transactional stream has to live in your own app or database. Mailjet's automatic global block is the only server-side thing that stops a transactional send, and it only fires after the address has already bounced once.

Mailjet bills on emails sent, not on contacts stored, so cleaning won't shrink a contact tier - its higher plans include unlimited contacts anyway. The saving is in wasted sends: every invalid you skip is one of your monthly sends not spent hard-bouncing, and once you're over your allowance those sends bill as an overage. The bigger payoff is avoiding the reputation hit and the throttling that a bounce spike triggers.

Yes - it's the highest-leverage option. Verify at the point of capture through the REST API (scoped keys, rate limits, webhooks), or a Zapier/Make/n8n flow, so a typo or disposable address is rejected before it's ever stored or synced to Mailjet - and never becomes a recipient your app fires transactional mail at.

Clean your Mailjet list in minutes

Start free with 100 credits that never expire - no card required. Connect, verify, and protect your next campaign.