كيف يعمل التحقق من البريد الإلكتروني.
بقلم Argorant
Three checks stack on top of each other: syntax, DNS, and a live SMTP conversation. Each one proves something specific, and none of them proves everything. Here’s the whole picture.
الطبقة الأولى: صحة الصيغة
The simplest check is the one that never touches a network. A syntax check asks whether a string is even shaped like an email address: one @ sign, a plausible local part, a domain with at least one dot, no illegal characters. It also catches the mechanical junk that creeps into any list: trailing whitespace, swapped characters from manual entry, “.con” instead of “.com”, and role patterns like noreply@ that you probably never want to mail.
ما يثبته فحص الصيغة: العنوان مكتوب بشكل صحيح. وما لا يستطيع إثباته: أن النطاق موجود، أو أنه يستقبل البريد، أو أن صندوق البريد حقيقي. فالعنوان المكتوب بشكل مثالي على نطاق مهجور منذ 2019 يجتاز فحص الصيغة بسهولة. تعامل مع هذه الطبقة كمرشّح للشوائب، لا كحكم على قابلية التسليم.
الطبقة الثانية: سجلات DNS وMX
The second layer asks the domain name system a simple question: if I wanted to deliver mail to this domain, where would I send it? A domain that receives email publishes MX (mail exchanger) records: the hostnames of the servers willing to accept its mail. If those records resolve, the domain participates in email at all. If they don’t, every address at that domain is dead, and you can reject the whole batch without ever contacting a server.
عمليات البحث في سجلات MX سريعة، وليس لها آثار جانبية، وتستبعد في مرحلة واحدة الشركات المتوقفة بالكامل والنطاقات التي بها أخطاء إملائية والمواقع المركونة. لكن حدّها واضح بالقدر نفسه: سجل MX يثبت فقط أن النطاق يستقبل البريد في مكان ما، ولا يقول شيئًا عما إذا كان j.smith@ على ذلك النطاق شخصًا حقيقيًا لديه صندوق بريد فعّال. كثير من المزوّدين يتوقفون هنا ويسمّون النتيجة “موثّقة”. وهي ليست كذلك.
الطبقة الثالثة: استعلام SMTP
The only way to test a specific mailbox is to ask the server that owns it. An SMTP probe opens a real delivery conversation with the domain’s mail server (HELO, MAIL FROM, then RCPT TO with the exact address in question) and reads the server’s answer. A 250 response means the server is prepared to accept mail for that mailbox; a 550 means it isn’t. The probe then disconnects before any message is transmitted. Nothing lands in an inbox, and the mailbox owner never knows the check happened.
This is categorically stronger evidence than the first two layers because it interrogates the same system that will ultimately accept or bounce your campaign. It’s also the layer where honest vendors and dishonest ones diverge, because SMTP answers are not always clean, which brings us to catch-alls and greylisting. For exactly how Argorant runs this conversation, see how we verify.
مشكلة Catch-all
Some domains are configured to accept mail for every address, real or invented. Probe jane.doe@ such a domain and the server says yes; probe xkcd9931@ and it says yes to that too. These are catch-all (or accept-all) domains, and they are common in mid-size companies whose IT teams route everything to a central filter. On a catch-all domain, a per-mailbox verdict is structurally impossible from the outside. Any vendor claiming a definitive “valid” on a catch-all address is reporting a guess with confident formatting.
The honest behavior is to flag catch-alls as their own category and let the buyer decide. Many catch-all addresses do deliver (the domain accepting everything doesn’t mean the person is fake), but they carry residual bounce risk that valid-status addresses don’t. Argorant treats them as opt-in at export: excluded by default, included only when you choose, charged like a valid contact when you do.
القائمة الرمادية (Greylisting) وخانة “غير معروف”
Mail servers defend themselves. Greylisting is the classic tactic: the server answers a first-time connection with a temporary failure (“try again later”) on the theory that real mail servers retry and spam cannons don’t. Other servers throttle probes, answer ambiguously, or time out under load. A verification engine that probes such a server gets no usable verdict on the first pass.
تعيد المحركات الجيدة المحاولة بفواصل زمنية مناسبة ومن بنية تحتية موثوقة، وهو ما يحل معظم حالات القائمة الرمادية (greylisting). وما يتبقى يذهب إلى خانة “غير معروف”. والطريقة الصحيحة للتعامل مع النتائج غير المعروفة هي الحذر: لا تسلّمها على أنها صالحة، ولا تحتسب رسومًا عليها، ولا تضمّها بصمت إلى العدد الصالح لتضخيم إحصائية الدقة. وعند تقييم أي أداة تحقق، اسأل عن نسبة النتائج التي تعود غير معروفة وكيف تُفوتر تلك الصفوف. فالإجابة تخبرك أكثر مما تخبرك به الصفحة التسويقية. (إذا كانت مصطلحات مثل greylisting جديدة عليك، فإن المسرد يشرحها.)
نتائج التحقق تتقادم. وبسرعة.
A verification verdict is a photograph, not a property. People change jobs, companies migrate mail systems, IT departments retire mailboxes. And the address that probed valid in January hard bounces in June. Industry estimates put B2B email decay around 2-3% per month, which compounds: a list verified a year ago can carry a quarter to a third dead weight, while still wearing its “verified” label.
ولهذا فإن متى تم التحقق من السجل لا يقل أهمية عن النتيجة نفسها. إجابة Argorant هي التحقق لحظة التصدير: يُفحص كل عنوان مباشرة مع خادم البريد لدى المستلم قبل وصوله إلى ملفك مباشرة، بحيث تعكس النتيجة الحالة الحالية لصندوق البريد، لا وقت إضافة السجل.
التحقق عند التصدير يتفوق على التحقق عند الجمع
Here is the architectural decision that separates data providers. Most verify at collection: an address is checked when it enters the database, stamped “verified,” and sold under that stamp for as long as it sits in inventory (months, often years). The stamp was true once. Decay makes it progressively less true every week, and the buyer pays for the gap in bounces.
Verify-at-export inverts this: the probe runs at the moment you download, against the mail server as it exists today. The verdict you pay for is at most minutes old (or inside a disclosed freshness window). The practical difference shows up exactly where it hurts: your bounce rate, and therefore your sender reputation. If you take one heuristic from this guide: when a vendor says “verified,” ask when. A vendor that can’t answer per-row is describing the past.
الاقتصاديات: الدفع مقابل الصالح فقط
Verification timing also determines what honest pricing can look like. If verification happens at export, the seller knows, before charging you, which rows are valid, which are invalid, which are catch-all, and which are unknown. There is no longer an excuse to bill them all the same. Argorant’s model follows directly: invalid and unknown rows are filtered out and cost zero credits; you pay per deliverable contact delivered (valid by default, with catch-all and risky as explicit opt-ins). Across 630.7M contacts in 202 countries, the economics stay simple because the risk of a stale verdict sits with the seller, where it belongs.
Compare that with paying per record regardless of outcome: every dead address is margin for the vendor and a bounce for you. When you model cost, ignore the per-credit sticker and compute cost per deliverable contact: pricing structures change ranking dramatically once you do. Plans start under $100/month, and the free tier is enough to test the verification behavior on a real segment before spending anything.
شاهد نتيجة SMTP مباشرة
على شريحتك الخاصة.
ابحث، وابنِ عينة مخصصة من 25 عميلًا محتملًا، وادفع فقط مقابل جهات الاتصال القابلة للتسليم.
