<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Yasir]]></title><description><![CDATA[Yasir]]></description><link>https://itsmeyasir.hashnode.dev</link><generator>RSS for Node</generator><lastBuildDate>Thu, 05 Nov 2026 07:56:16 GMT</lastBuildDate><atom:link href="https://itsmeyasir.hashnode.dev/rss.xml" rel="self" type="application/rss+xml"/><language><![CDATA[en]]></language><ttl>60</ttl><item><title><![CDATA[Catch-All vs Unknown Email Verification Results]]></title><description><![CDATA[Understand catch-all and unknown email results, how they differ from invalid addresses, and how to review them before a campaign.]]></description><link>https://itsmeyasir.hashnode.dev/catch-all-vs-unknown-email-verification-results</link><guid isPermaLink="true">https://itsmeyasir.hashnode.dev/catch-all-vs-unknown-email-verification-results</guid><category><![CDATA[email]]></category><category><![CDATA[ #deliverability]]></category><category><![CDATA[Tutorial]]></category><category><![CDATA[Beginner Developers]]></category><dc:creator><![CDATA[Yasir]]></dc:creator><pubDate>Tue, 27 Oct 2026 11:25:56 GMT</pubDate><enclosure url="https://cdn.hashnode.com/uploads/covers/6ad9dc81e410549ae677a388/0e7b29ba-356a-4865-9a60-e610a4708694.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>A catch-all result and an unknown result describe different kinds of uncertainty. Neither should automatically be treated as a confirmed, individual mailbox.</p>
<p>A catch-all result indicates that a domain accepts addresses broadly. An unknown result means the verification process could not reach a conclusive assessment. Understanding the difference helps you decide whether to review a contact, recheck it later, or leave it out of a particular campaign.</p>
<h2>What is a catch-all email domain?</h2>
<p>A catch-all domain, also called an accept-all domain, can accept mail addressed to names that are not individually confirmed mailboxes. That behavior limits what acceptance alone can prove about one specific recipient.</p>
<p>For example, a mail system may appear to accept both a known employee address and an invented address at the same domain. The response does not establish that both correspond to real people who will read the message.</p>
<p>This is why a catch-all detection result is useful even though it does not resolve the whole question. It identifies an area where your contact decision needs more context.</p>
<h2>What does unknown mean in email verification?</h2>
<p>An unknown result means that the available checks did not support a conclusive classification. Mail systems can limit the information they provide, and temporary conditions can prevent a definitive answer.</p>
<p>Unknown does not mean invalid. It also does not mean safe. Keeping it as its own category preserves that distinction.</p>
<p>If the contact is important, a later check may provide more information. A later check may also remain unknown. Repeating verification is not a guarantee that the uncertainty will disappear.</p>
<h2>How catch-all, unknown, and invalid differ</h2>
<table>
<thead>
<tr>
<th>Result</th>
<th>What you know</th>
<th>What remains unresolved</th>
</tr>
</thead>
<tbody><tr>
<td>Catch-all</td>
<td>The domain shows broad acceptance behavior</td>
<td>Whether the particular mailbox is confirmed and appropriate for your message</td>
</tr>
<tr>
<td>Unknown</td>
<td>Verification did not reach a conclusive assessment</td>
<td>Whether the address can be classified confidently</td>
</tr>
<tr>
<td>Invalid</td>
<td>The verification assessment identifies the address as invalid</td>
<td>Whether a corrected address exists elsewhere</td>
</tr>
<tr>
<td>Role account</td>
<td>The address is identified as a shared function</td>
<td>Whether that shared inbox is the right contact point</td>
</tr>
<tr>
<td>Safe</td>
<td>The assessment considers the address suitable for sending</td>
<td>Whether a future message will be accepted, placed in the inbox, or welcomed</td>
</tr>
</tbody></table>
<p>The category labels are useful only when the next step respects what they actually mean.</p>
<h2>How to review the results in Apify</h2>
<p>The <a href="https://apify.com/yasir-on-apify/email-verifier-deliverability-checker">Email Verifier &amp; Deliverability Checker</a> returns a <code>status</code> field and additional signals such as <code>is_catch_all</code>, <code>is_deliverable</code>, <code>can_connect_smtp</code>, and <code>overall_score</code>.</p>
<p>Start with the status, then read the relevant signals. A successful SMTP connection tells you that a connection was possible; it does not by itself confirm that a specific mailbox exists or that your campaign will reach the inbox.</p>
<p>Treat missing or inconclusive checks carefully. The existing output can contain <code>"None"</code> values, and missing values can use compatibility defaults. A false flag is not always proof that the corresponding check completed.</p>
<p>The quality score is another signal, not a substitute for the status. A high score should not silently override a catch-all or unknown result.</p>
<h2>Build a review policy that fits the list</h2>
<p>For a general newsletter audience, you may prefer to hold uncertain contacts until they can be reviewed. For a small set of existing business relationships, you may have additional context that helps you decide.</p>
<p>Keep that business context separate from the technical result. An address that was previously useful may have changed, and a technically deliverable address does not establish recipient consent.</p>
<p>A practical review record can include the email, latest status, verification date from your workflow, contact source, and decision. The Actor's 17-field dataset does not add a verification-date column; record run timing separately if you need it.</p>
<h2>Avoid forcing every result into valid or invalid</h2>
<p>A binary spreadsheet column is easy to filter, but it can hide useful information. Preserve the original status when you create a separate campaign-selection column.</p>
<p>For example, a contact can remain <code>unknown</code> in the verification record while your campaign decision says “hold for review.” This keeps the technical finding intact and makes the business decision auditable.</p>
<p>Likewise, a role account can remain <code>role_account</code> while you decide whether a general contact inbox is appropriate for the message.</p>
<h2>Recheck with a purpose</h2>
<p>Before rerunning an uncertain list, decide what new information you expect and how you will use it. Check the current pricing because completed unknown results can still be billable in this Actor.</p>
<p>Keep a record of the previous run so you can compare classifications without losing the original result. If repeated checks stay inconclusive, use another appropriate source of contact context or leave the address out of the campaign.</p>
<p><a href="https://apify.com/yasir-on-apify/email-verifier-deliverability-checker">Run an email list check and review the returned categories</a>.</p>
]]></content:encoded></item><item><title><![CDATA[How to Verify an Email List Before Cold Outreach]]></title><description><![CDATA[Learn how to verify an email list before outreach, review safe and risky results, and export verification data with an Apify email checker.]]></description><link>https://itsmeyasir.hashnode.dev/how-to-verify-an-email-list-before-cold-outreach</link><guid isPermaLink="true">https://itsmeyasir.hashnode.dev/how-to-verify-an-email-list-before-cold-outreach</guid><category><![CDATA[email]]></category><category><![CDATA[marketing]]></category><category><![CDATA[ #deliverability]]></category><category><![CDATA[Tutorial]]></category><dc:creator><![CDATA[Yasir]]></dc:creator><pubDate>Sat, 24 Oct 2026 08:38:06 GMT</pubDate><enclosure url="https://cdn.hashnode.com/uploads/covers/6ad9dc81e410549ae677a388/a5e5a0e7-c61a-4ab6-b59e-be26f82c522b.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>Before you start an outreach campaign, check the email addresses you plan to use. An email verification tool can identify invalid addresses and flag other categories that need review, including disposable emails, shared inboxes, catch-all domains, and inconclusive results.</p>
<p>A useful verification workflow goes beyond running a check. You also need to interpret the results, connect them to the right contact records, and keep your campaign rules intact.</p>
<p>The <a href="https://apify.com/yasir-on-apify/email-verifier-deliverability-checker">Email Verifier &amp; Deliverability Checker on Apify</a> provides a Console interface and an API for this process. You submit addresses and receive verification statuses, scores, and individual flags.</p>
<h2>Start with the list you actually intend to contact</h2>
<p>Prepare the email addresses for the specific campaign. Keep a copy of the original contact records, including the identifiers you will need when updating a spreadsheet or CRM.</p>
<p>The Actor accepts an email list, rather than a whole contact database. If your source is a spreadsheet, extract the email column first. If another tool collected the contacts, pass the resulting addresses into the verifier.</p>
<p>Prepare spelling and formatting before submission. The Actor forwards the supplied strings without a separate trimming, deduplication, or typo-correction step.</p>
<h2>Submit a small batch first</h2>
<p>Open the Actor, paste a small selection of addresses, review the applicable pricing, and start the run. This gives you an opportunity to understand the output before processing the rest of the list.</p>
<p>The input accepts up to 1,000 entries per run. Larger lists should be split into separate runs. Account rules and spending limits can affect how much of a batch is processed, so keep a record of each run and the addresses submitted.</p>
<p>If you already use Apify, the <a href="https://apify.com/yasir-on-apify/email-verifier-deliverability-checker/examples/bulk-email-verifier-for-cold-email-outreach">cold outreach example task</a> is a convenient starting point. Replace the demonstration addresses with your campaign list.</p>
<h2>Read the verification status before choosing contacts</h2>
<p>The main result category is in the <code>status</code> field. Other fields provide context, including the overall score, syntax result, disposable flag, role-account flag, and deliverability signals.</p>
<p>A practical review separates the results into three working groups:</p>
<table>
<thead>
<tr>
<th>Working group</th>
<th>Examples</th>
<th>What to do next</th>
</tr>
</thead>
<tbody><tr>
<td>Candidates for your normal selection rules</td>
<td>safe</td>
<td>Apply your existing campaign and contact requirements</td>
</tr>
<tr>
<td>Results needing separate review</td>
<td>catch_all, unknown, role_account, inbox_full</td>
<td>Decide whether to hold, recheck, or handle them separately</td>
</tr>
<tr>
<td>Results generally unsuitable for the active outreach list</td>
<td>invalid, disabled, spamtrap</td>
<td>Exclude them until there is a justified correction or reassessment</td>
</tr>
</tbody></table>
<p>Disposable addresses should be handled according to the purpose of your list. Their temporary nature may make them unsuitable for a lasting business relationship, even if they can receive a message at the time of checking.</p>
<p>A role account may belong to a legitimate shared inbox. A catch-all result describes domain behavior and does not confirm a particular person's mailbox. Avoid turning these distinct results into a single "valid" category.</p>
<h2>Use the score as supporting information</h2>
<p>The Actor returns <code>overall_score</code> on a scale from 0 to 100. Use it alongside the status and flags.</p>
<p>Do not interpret a score of 90 as a 90% probability of inbox placement. A missing score can also fall back to zero. Your selection rule needs to consider the available evidence rather than a score alone.</p>
<p>Some flags can contain an inconclusive value such as "None". If you use an automated filter, make sure that it understands those values instead of treating every nonempty string as true.</p>
<h2>Export and join the results carefully</h2>
<p>Export CSV or Excel for manual review, or retrieve JSON through the API. Apify datasets support <a href="https://docs.apify.com/api/v2/dataset-items-get">these export formats</a>.</p>
<p>Keep the verification fields alongside the correct contact record when updating your source system. Do not join rows only by their position: the response may contain fewer rows than the submitted list, and its ordering should not be assumed to match your original contact table.</p>
<p>Preserve unsubscribes and existing suppression rules when preparing the final campaign audience. A technical verification result does not tell you whether someone has asked to stop receiving messages.</p>
<h2>Check whether the batch completed</h2>
<p>Before calling a list "verified," review the run's status, saved results, and summary. A spending limit or interruption can leave a partial result set.</p>
<p>Avoid immediately submitting the full list again when you see fewer results. First determine what was saved and which contacts still need attention. A new run can create new charges.</p>
<h2>Keep verification close to the decision</h2>
<p>An email assessment reflects the time it was performed. Addresses and mailbox conditions can change, particularly when you are working with an older contact list.</p>
<p>When the list has been sitting for a while, reassess the contacts you actually plan to use. Choose the timing based on how quickly your data changes and how soon the campaign will run.</p>
<p>Address verification can help you identify avoidable address problems. Sending quality still depends on the wider campaign, including your relationship with recipients and how the sending system is operated.</p>
<p><a href="https://apify.com/yasir-on-apify/email-verifier-deliverability-checker">Verify your next email list on Apify</a>.</p>
]]></content:encoded></item><item><title><![CDATA[Email Verification API on Apify: A Practical Guide]]></title><description><![CDATA[Send an email list to Apify, check the run status, and retrieve JSON verification results. Learn the input format, limits, and export options.]]></description><link>https://itsmeyasir.hashnode.dev/email-verification-api-on-apify-a-practical-guide</link><guid isPermaLink="true">https://itsmeyasir.hashnode.dev/email-verification-api-on-apify-a-practical-guide</guid><category><![CDATA[api]]></category><category><![CDATA[email]]></category><category><![CDATA[Tutorial]]></category><category><![CDATA[webdev]]></category><dc:creator><![CDATA[Yasir]]></dc:creator><pubDate>Thu, 22 Oct 2026 10:39:40 GMT</pubDate><enclosure url="https://cdn.hashnode.com/uploads/covers/6ad9dc81e410549ae677a388/f774ebc8-5b56-4ec4-9abd-4e35d3718c2b.webp" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>An email verification API lets your application submit addresses and receive structured verification results. With the <a href="https://apify.com/yasir-on-apify/email-verifier-deliverability-checker">Email Verifier &amp; Deliverability Checker</a>, you can build that step around an Apify Actor run.</p>
<p>The Actor accepts a single input field, <code>emails</code>, and saves its available results to a dataset. This makes it suitable for background contact checks, batch processing, and workflows that review a list before another system uses it.</p>
<p>The examples below illustrate the documented API sequence. They have not been executed against a paid live run as part of this article.</p>
<h2>Prepare the email-list input</h2>
<p>Send an array of between 1 and 1,000 strings:</p>
<pre><code class="language-json">{
  "emails": [
    "person@example.com",
    "team@example.org"
  ]
}
</code></pre>
<p>The addresses above demonstrate the payload format. Replace them with the addresses you intend to verify.</p>
<p>The Actor accepts neither a CSV file URL nor complete CRM contact objects. Extract the email values first and retain any contact identifiers in your own system.</p>
<h2>Start one Actor run</h2>
<p>Store your Apify API token securely in the environment as <code>APIFY_TOKEN</code>. The following request starts a run and returns its run object. Running it incurs the Actor's applicable charges.</p>
<pre><code class="language-bash">curl --fail-with-body --silent --show-error \
  --request POST \
  'https://api.apify.com/v2/actors/yasir-on-apify~email-verifier-deliverability-checker/runs' \
  --header "Authorization: Bearer $APIFY_TOKEN" \
  --header 'Content-Type: application/json' \
  --data '{"emails":["person@example.com","team@example.org"]}'
</code></pre>
<p>Save <code>data.id</code> from the response. The response also includes storage identifiers such as <code>data.defaultDatasetId</code>. The <a href="https://docs.apify.com/api/v2/actors-runs-post">asynchronous start endpoint</a> returns before the verification work finishes.</p>
<p>Use the configured Actor run options and an appropriate spending limit for your job. Keep the token in server-side code or your automation platform's credential store.</p>
<h2>Check the same run</h2>
<p>Put the saved run ID in <code>APIFY_RUN_ID</code>, then request that run:</p>
<pre><code class="language-bash">curl --fail-with-body --silent --show-error \
  "https://api.apify.com/v2/actor-runs/$APIFY_RUN_ID" \
  --header "Authorization: Bearer $APIFY_TOKEN"
</code></pre>
<p>Inspect <code>data.status</code>. Continue checking that run at a reasonable interval while it is active. Once it reaches a terminal state, handle the outcome: <code>SUCCEEDED</code>, <code>FAILED</code>, <code>TIMED-OUT</code>, or <code>ABORTED</code>. Use the returned <a href="https://docs.apify.com/api/v2/actor-run-get">run information</a> when reporting errors.</p>
<p>Do not create another run just to check whether the first one has finished. Keep the run ID in your job record so a lost connection does not cause unnecessary resubmission.</p>
<p>For this Actor, a successful platform run can still have a partial application summary because a spending or access limit was reached. Review the <code>SUMMARY</code> record in the default key-value store and the saved results before marking the entire input batch complete.</p>
<h2>Retrieve the verification dataset</h2>
<p>After the run finishes, put the returned default dataset ID in <code>APIFY_DATASET_ID</code>:</p>
<pre><code class="language-bash">curl --fail-with-body --silent --show-error \
  "https://api.apify.com/v2/datasets/$APIFY_DATASET_ID/items?format=json&amp;offset=0&amp;limit=1000" \
  --header "Authorization: Bearer $APIFY_TOKEN"
</code></pre>
<p>The dataset response is an array of result objects. Each result uses the existing 17-field structure, including <code>email</code>, <code>status</code>, <code>overall_score</code>, and the verification flags.</p>
<p>Apify supports JSON, CSV, and Excel dataset exports, among other formats. The API <a href="https://docs.apify.com/api/v2/dataset-items-get">supports pagination</a> when you need to retrieve more data. For this Actor's current per-run input limit, the request above asks for up to 1,000 items.</p>
<h2>Interpret fields before automating decisions</h2>
<p>A <code>safe</code> status, a <code>role_account</code> status, and an <code>unknown</code> status should not be treated as interchangeable. Preserve the original category and apply the contact rules for your workflow.</p>
<p>The output retains compatibility values. A check can be a boolean, a number, or a string such as <code>"None"</code>. Avoid programming shortcuts that treat every nonempty value as a positive result.</p>
<p>Likewise, an integer score is not a calibrated delivery probability. Use the score with the status and available checks.</p>
<h2>Join results back to your source records</h2>
<p>Keep the input batch and the original contact identifiers in your application. Match using an appropriate email comparison rule and preserve any one-to-many relationship when several records share an address.</p>
<p>Do not attach results to CRM contacts by array position alone. The result count may be smaller than the input count, and the returned order should not be assumed to preserve your original contact-table ordering.</p>
<p>The Actor does not perform a separate input deduplication or canonicalization step. Any cleanup or contact merging in your application is a separate workflow decision.</p>
<h2>Choose an appropriate execution pattern</h2>
<p>A background run is a practical default for bulk verification. It allows your application to track progress without keeping one request open for the entire job.</p>
<p>Apify also provides a <a href="https://docs.apify.com/api/v2/actor-run-sync-get-dataset-items-post">synchronous run-and-dataset endpoint</a>, but its documented HTTP wait limit is 300 seconds. Longer runs can exceed that limit. Do not assume that an HTTP timeout means the underlying work never started.</p>
<p>For an interactive signup form, measure latency and design fallback behavior before relying on a complete Actor run in the user's request path.</p>
<h2>Use the same contract with connected agents</h2>
<p>Connected agents can call eligible Actors through <a href="https://docs.apify.com/mcp">Apify's MCP server</a>. Provide the exact Actor identifier, the email list, the input limit, and the meaning of uncertain results. Ask the agent to retrieve the actual dataset before summarizing outcomes.</p>
<p>For example:</p>
<blockquote>
<p>Use the Apify Actor yasir-on-apify/email-verifier-deliverability-checker to verify the email list I provide. Show the applicable cost and input before starting the run. After it completes, summarize the returned statuses and provide the dataset link. Keep catch-all and unknown results separate from safe results.</p>
</blockquote>
<p>This prompt works only in an environment with an appropriate Apify connection and authorization. It does not install a connector or make the tool available in every AI application.</p>
<p><a href="https://apify.com/yasir-on-apify/email-verifier-deliverability-checker/api">Open the Actor's API examples</a></p>
]]></content:encoded></item></channel></rss>