GMass Email Verifier: Test Classification Accuracy

The GMass email verifier should be tested against a labeled address set before its statuses control a live campaign. GMass documents seven web and API statuses and says its campaign check errs toward sending unless an address definitively fails. That makes status mapping, unknown handling, duplicate control, suppression, and observed post-send outcomes part of the acceptance decision.

Define the GMass email verifier acceptance test

GMass's email verification page describes three paths: verification during a GMass campaign, a web tool, and an API. GMass says the campaign path checks address syntax, whether the domain has a responding MX server, and whether the recipient server gives a definitive invalid response. It also says verification uses SMTP and openly notes that specialist verification products may use additional methods.

That is enough to test a specific workflow. It is not evidence that every mailbox classified Valid exists, every Unknown is safe to send, or every catch-all address reaches a person.

Build a labeled file with an immutable test_id, address, expected class, reason, evidence source, and allowed-send decision. Use domains and mailboxes you control wherever possible. Do not put real third-party addresses into a test merely to see what the verifier says.

Include:

Run enough examples per class to reveal inconsistency. One address can prove a path works, but it cannot estimate classification accuracy.

Our view: the safest default is to quarantine ambiguity. A verifier designed to err toward sending may be convenient for a low-risk mail merge, but it should not silently define eligibility for a sensitive or high-volume campaign.

Map GMass statuses to your own policy

The official capability page lists seven outputs for the web and API paths:

GMass says its web tool's "Include only addresses I should send to" option includes Valid, Blocked, and Unknown. It explains that Blocked may mean the server blocked GMass's AWS-based verifier even though a Gmail or SMTP send could behave differently. That is a vendor recommendation, not a universal risk rule. Define your own eligibility mapping before the run.

The page does not list Catch-all, Risky, or Duplicate as statuses. Do not report those classes as GMass outputs unless the live result actually returns and documents them. Instead:

• label known catch-all addresses in the test set and observe which GMass status they receive;
• define risky as your policy bucket for ambiguous or conditional statuses;
• detect duplicates before verification and test whether the interface preserves, removes, or bills them;
• retain the raw GMass status alongside your normalized decision.

This distinction matters because a policy label such as risky is not the same thing as a product classification.

Run campaign, web, and API modes separately

GMass says verification during a campaign happens address by address before sending and has no verification limit in that context. Its verify-list workflow warns that verification slows sending and is not perfect. The web and API tools are documented with a limit of 5,000 verifications per hour.

Test each path you plan to use:

1. Upload the same ordered address set to the web tool and export or copy the complete result.
2. Submit the set through the API, preserving HTTP status, raw JSON, request ID if available, and time.
3. Connect the set to a controlled GMass campaign with "Verify emails before sending" enabled.
4. Keep the campaign paused or route eligible messages only to addresses you own.
5. If using a Google Sheet, enable reporting writeback and inspect the added values.

Compare raw status, normalized decision, order, duplicates, and errors across the modes. An API response matching the web page is useful, but campaign-mode behavior is the acceptance point if that mode controls live sending.

GMass's Google Sheets integration page says campaign reporting can write Opened, Clicked, Replied, and Bounced columns back to the Sheet. The verification page says verification results can also update the Sheet when reporting-data updates are enabled. Confirm the exact column names, timing, overwrite behavior, and whether a rerun preserves history.

Score classification errors instead of quoting one accuracy rate

Create a confusion table from known outcomes:

Calculate separate rates for the errors that matter:

false-valid rate = known invalid addresses classified into your sendable bucket / known invalid addresses tested

false-invalid rate = known valid addresses classified into your blocked bucket / known valid addresses tested

ambiguous rate = addresses mapped to manual review or retry / all unique addresses tested

Do not collapse these into a single "accuracy" number. A false valid creates bounce and reputation exposure. A false invalid discards a reachable recipient, so the costs are different.

Catch-all domains require special treatment. An SMTP server can accept a probe for an unknown mailbox while the final message later routes, quarantines, or bounces. Score catch-all handling against the policy you need, not against a promise that the mailbox belongs to the named person.

Test duplicate, normalization, and input behavior

Verification quality starts before the network check. Include exact duplicates, mixed case, leading or trailing spaces, plus-address aliases, internationalized domains if relevant, and the same address in two Sheet rows with different merge data.

Record whether GMass:

• normalizes whitespace or case;
• preserves every input row;
• verifies a repeated address once or several times;
• returns results in input order;
• merges conflicting row data;
• sends once or more than once when duplicates reach campaign mode;
• exposes a reason for rejected input.

Do not assume deduplication because the web tool extracts email addresses from pasted text. The official capability page does not define duplicate semantics. If your campaign cannot tolerate repeat sends, deduplicate upstream and use a stable contact ID rather than an email address alone.

Our B2B contact database guide covers source and identity controls before verification. Our email list cleaning tools guide covers the wider hygiene workflow.

Verify suppression wins over verification

A Valid status should never override an unsubscribe, do-not-contact record, prior hard bounce, client exclusion, or internal block. Build controlled collisions:

• Valid plus account unsubscribe;
• Valid plus campaign-specific suppression;
• Unknown plus prior hard bounce;
• duplicate where one row carries a block;
• address added to suppression after scheduling but before send.

GMass's unsubscribe management documentation says future sends are checked against the account Unsubscribe List and documents campaign, domain, and optional global suppression scopes. Its bounce management page describes preventing repeat sends to bounced addresses. The acceptance test must prove precedence in the actual campaign path.

Expected rule:

send eligible = verification policy allows AND every applicable suppression check allows

Log the blocked attempt and source rule. A silent skip may prevent a send, but without a reason it is difficult to reconcile the final audience or fix a false suppression.

Compare verification with observed delivery carefully

For addresses you control and permit to receive, send a small validation campaign after classification. Capture accepted delivery, final bounce class, folder placement, and reply. Do not send to known invalid third-party addresses to create a scorecard.

Delivery does not prove the verifier correctly identified a person. Catch-all infrastructure can accept the message. Placement in spam still means the mailbox server accepted it. A later bounce may reflect a temporary condition that changed after verification. Preserve both the verifier result and the delivery outcome rather than overwriting one with the other.

Repeat transient classes after a defined interval. Set a retry cap for Blocked, Mailbox full, Unknown, and ConnectionFail. If repeated runs alternate between Valid and Invalid with no known infrastructure change, mark the address and product path unstable.

GMass explicitly states that its verification is not perfect and that specialist tools may use SMTP plus other methods. Treat that disclosure as the product-evidence boundary. The public page does not provide an independently validated accuracy rate, a catch-all detection claim, or an error matrix for these seven statuses.

Preserve export and audit evidence

Retain:

• original labeled input with stable IDs;
• exact raw output from every tested mode;
• status-to-policy mapping and version;
• deduplication and normalization log;
• suppression collision results;
• controlled delivery outcomes;
• timestamps, operator, account, and test configuration;
• exceptions and manual decisions.

Test the exit path before relying on the capability. Confirm whether raw verification statuses, reasons, timestamps, and campaign decisions can be exported from the web tool, API, Sheet, and GMass report. A cleaned list without raw statuses is not enough to reproduce the decision later.

Approve the GMass email verifier only for the tested workflow and risk threshold. Hold it when known invalids enter the sendable bucket too often, known valids are discarded without a recoverable review path, catch-all and transient outcomes cannot be isolated, suppression loses precedence, or raw evidence cannot be exported.

LeadHaste can wire verification, suppression, sending, CRM state, and audit evidence across a system of 35+ tools. Engagements start at $2,500 per month with a three-month initial term, then continue month-to-month; sender infrastructure is separate and remains under your ownership. We can turn your labeled sample and error tolerance into an acceptance plan during a free ICP and campaign-fit discovery call. Book your free ICP and campaign-fit discovery call →