Node.js'de E-posta Doğrulama: Regex'in Ötesinde Teslim Edilebilirlik Kontrolleri

E-posta doğrulama için bir Node.js servis akışı: yerel format taraması, sunucu tarafında teslim edilebilirlik kontrolü ve her sonucun net bir şekilde işlenmesi.

Node.js'de e-posta doğrulama, sunucuda iki katmanlı olarak en iyi şekilde çalışır. İlk olarak, girdiyi normalleştirin ve formatını yerel olarak tarayın; böylece bariz yazım hataları işleminizden asla çıkmaz. İkinci olarak, sunucu kodundan bir zaman aşımı ile EmailCheckPro'nun POST /api/v1/check gibi bir teslim edilebilirlik kontrolünü çağırın ve sonucu üç dalda değerlendirin: Teslim edilebilir, Teslim edilemez veya Belirlenemedi. Yalnızca bir Regex, bir adresin doğru görünüp görünmediğini söyler; teslim edilebilirlik kontrolü ise, ona hiçbir şey göndermeden, kontrol anında posta alıp alamayacağını bildirir. Onay bağlantıları, rıza ve sahiplik için ayrı bir adım olarak kalmaya devam eder.

Node.js'de e-posta doğrulama genellikle ne anlama gelir?

Bu konuyu arattığınızda çoğu eğitim ya bir Regex ya da bir onay bağlantısı e-postası gönderen bir Express rotası gösterir. Her ikisi de yararlıdır ancak farklı sorulara yanıt verirler ve bunları karıştırmak hatalara yol açar.

Bu kılavuz, siz hiçbir şey göndermeden önce çalışan ilk iki katmanı kapsamaktadır. Bunlar, bir onay akışının yerini almaz, onu tamamlarlar. Bu model, diğer framework'lerdeki servis katmanı doğrulamalarını yansıtır: tarayıcı hızlı ipuçları verebilir, ancak karar API anahtarının ve saklanan sonucun bulunduğu sunucuya aittir.

1. Adım: formatı normalleştirin ve tarayın

Küçük ve öngörülebilir bir fonksiyonla başlayın. Boşlukları kırpın, kopyalanan metinlerden sıkça sızan sondaki noktalama işaretlerini kaldırın, alan adını küçük harfe çevirin ve yerel kısmı yazıldığı gibi bırakın. Ardından sonucu geniş bir desenle test edin.

// type="email" girdileri için WHATWG HTML standardından desen
const EMAIL_PATTERN = /^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/;

export function normalizeEmail(raw) {
 const trimmed = String(raw ?? '').trim().replace(/[.,;:]+$/, '');
 const at = trimmed.lastIndexOf('@');
 if (at < 1 || at === trimmed.length - 1) return null;
 const email = trimmed.slice(0, at) + '@' + trimmed.slice(at + 1).toLowerCase();
 return EMAIL_PATTERN.test(email) ? email : null;
}

Bu desen, tarayıcıların type="email" alanlarına uyguladığı kuralın aynısı olan WHATWG HTML standardından gelir, böylece istemci ve sunucu uyumlu olur. Bakımı yapılan bir paket tercih ederseniz, validator.js içindeki isEmail yaygın bir seçimdir; tek bir doğruluk kaynağı seçin ve her yerde onu kullanın.

Bu katmandaki yaygın hatalar:

• Aşırı katı desenler: + etiketlerini, uzun üst düzey alan adlarını veya alt alan adlarını reddeden desenler. OWASP rehberliği, çok çeşitli geçerli formatların kabul edilmesini ve yalnızca açıkça hatalı girdilerin reddedilmesini önerir.
• Adresin tamamını küçük harfe çevirmek: Alan adları büyük/küçük harfe duyarlı değildir, ancak yerel kısmı değiştirmek kullanıcının yazdığını bozar.

2. Adım: teslim edilebilirlik kontrolünü sunucudan çağırın

Node.js 18 ve sonrası sürümler yerleşik bir fetch ile gelir, bu nedenle HTTP kütüphanesine gerek yoktur. Çağrı sunucuda çalışmalıdır: API anahtarı hesap bakiyesini harcar ve asla tarayıcı koduna ulaşmamalıdır.

const API_BASE = process.env.EMAILCHECK_API_BASE; // API dokümantasyonundan

export async function checkDeliverability(email) {
 try {
 const res = await fetch(`${API_BASE}/api/v1/check`, {
 method: 'POST',
 headers: buildHeaders(), // tam olarak dokümante edildiği gibi yetkilendirme başlıkları
 body: buildCheckBody(email), // tam olarak dokümante edildiği gibi istek gövdesi
 signal: AbortSignal.timeout(4000) // kendi form bütçeniz
 });
 return await toOutcome(res); // 'deliverable' | 'undeliverable' | 'undetermined'
 } catch (err) {
 return 'not_completed'; // TimeoutError, ağ hatası vb.
 }
}

buildHeaders, buildCheckBody ve toOutcome, EmailCheckPro API dokümantasyonuna göre yazdığınız basit yardımcılardır; böylece kimlik doğrulama ve alan detayları tek bir yerde kalır ve yayınlanan sözleşmeye uyar. toOutcome, ham yanıt nesnelerini kod tabanınızda dolaştırmak yerine düz kelimeler döndürmelidir.

AbortSignal.timeout(), seçtiğiniz bütçeden sonra isteği iptal eder ve bir TimeoutError yükseltir; bu, yavaş bir ağın kayıt formunu dondurmasını engeller. Node.js fetch referansı, desteklenen seçenekleri listeler. Zaman aşımını kendi formunuzun toleransına göre seçin; yukarıdaki değer bir örnek olup servis rakamı değildir.

E-posta Teslim Edilebilirlik Kontrolü, neredeyse her alan adındaki adresleri kabul eder. Ürünün herkese açık profil fotoğraflarına ihtiyacı varsa, E-posta Profil Fotoğrafı Kontrolü yalnızca Gmail, Yandex ve Mail.ru alan adlarıyla sınırlıdır, bu nedenle diğer alan adlarını teslim edilebilirlik ürününe yönlendirin.

3. Adım: teslim edilebilir, teslim edilemez ve belirlenemedi durumlarını işleyin

Sonucu küçük bir durum kümesi olarak modelleyin ve formun oradan karar vermesini sağlayın:

export async function screenSignupEmail(raw) {
 const email = normalizeEmail(raw);
 if (!email) return { ok: false, message: 'Lütfen e-posta formatını kontrol edin.' };

 const outcome = await checkDeliverability(email);
 await saveCheck({ email, outcome, checkedAt: new Date() });

 switch (outcome) {
 case 'deliverable': return { ok: true, email };
 case 'undeliverable': return { ok: false, message: 'Bu adres posta alamıyor. Lütfen başka bir tane kullanın.' };
 default: return { ok: true, email, flagged: true }; // belirlenemedi veya tamamlanmadı
 }
}

Her dalın neden bu şekilde davrandığı:

• Teslim edilebilir, adresin kontrol anında posta alabildiği anlamına gelir. Devam edin ve tarihi sonuçla birlikte saklayın.
• Teslim edilemez, adresin posta alamadığı anlamına gelir. Dostça bir dille başka bir adres isteyin; kullanıcıyı sahte adres girmekle suçlamayın.
• Belirlenemedi, catch-all adresleri gibi her iki şekilde de sonuçlandırılamayan adresleri kapsar. Gerçek zamanlı API, bunlar için sonuç yerine bir iş kodu döndürür ve bunlar ücretlendirilmez. Tahmin etmek yerine adresi bir işaretle (flag) kabul edin.
• Tamamlanmadı, zaman aşımlarını ve ağ hatalarını kapsar. Kullanıcının bir işaretle devam etmesine izin vermek, geçici bir sorunun gerçek bir kaydı engellemesini önler.

Arka plan işi daha sonra işaretlenmiş satırları yeniden kontrol edebilir ve zaten gönderdiğiniz onay e-postası bunların birçoğunu çözecektir.

Node.js'den birden fazla adresi kontrol etme

Kayıt formları tek bir adresi kontrol eder, ancak yönetici araçları ve içe aktarma işlemleri genellikle çok sayıda adres içerir. İki dokümante edilmiş yol bunları kapsar.

Tek seferde 100 adrese kadar. POST /api/v1/batch-check, 1–100 arası adresi kabul eder ve sonuçları aynı yanıtta, giriş sırasıyla döndürür. Daha büyük dizileri 100'lük parçalara bölün ve her yanıtı konumuna göre parçasıyla eşleştirin. Her öğe, tamamlanmış bir sonucun var olup olmadığını belirtir; sonucu olmayan bir öğe, belirlenemedi veya tamamlanmadı dalına aittir, asla teslim edilemez dalına değil.

Hazırlanmış dosyalar. Dışa aktarmalar ve geçişler için, satır başına bir tam adres içeren bir TXT veya CSV dosyası yazın ve bunu POST /api/v1/bulk-tasks ile gönderin. Görev asenkron olarak çalışır, bu nedenle durumu bir istek işleyicisinden değil, bir işçiden (worker) sorgulayın:

const sleep = (ms) => new Promise((r) => setTimeout(r, ms));

async function waitForTask(taskRef) {
 for (;;) {
 const status = await getTaskStatus(taskRef); // GET /api/v1/bulk-tasks/{id}
 if (status.done) return status; // başarı veya başarısızlık
 await sleep(30_000); // bundan daha hızlı asla sorgulamayın
 }
}

Başarılı bir görev, 12 saat boyunca geçerli olan bir indirme bağlantısında bir sonuç CSV'si sağlar; aynı görevi tekrar sorgulamak yeni bir bağlantı döndürür. Geçersiz ve yinelenen satırlar hazırlık sırasında kaldırılır, bu nedenle sonuçları satır numarasına göre değil, e-posta adresine göre birleştirin. Ürün bazlı görev limitleri API dokümantasyonunda listelenmiştir.

Node.js entegrasyonu için üretim kontrol listesi

• Gizli bilgiler: API anahtarını ortam değişkenlerinden veya bir gizli yönetici aracından okuyun ve günlüklerden (logs) ve hata raporlarından uzak tutun.
• Önbelleğe alma: sonucu tarihiyle birlikte saklayın ve kendi yeniden kontrol pencereniz içinde yeniden kullanın, böylece bir profil adını düzenlemek yeni bir çağrıyı tetiklemez.
• Kendi uç noktanız: uygulama bir adres kontrol rotası sunuyorsa, hız sınırlaması (rate limiting) ve tutarlı yanıtlar ekleyin, böylece hangi hesapların var olduğunu araştırmak için kullanılamaz.
• Kuyruklar: işaretlenmiş satırların yeniden kontrollerini, istek içinde tekrar denemek yerine, gecikmeli ve deneme sınırlamalı bir iş kuyruğundan çalıştırın.
• Test etme: normalizeEmail fonksiyonunu artı etiketleri, alt alan adları, sondaki boşluklar ve eksik alan adları ile birim testine tabi tutun ve UI metninin lansmandan önce gözden geçirilmesi için her sonuç dalını taslak bir checkDeliverability ile test edin.
• Yapay zeka araçları: yapay zeka asistanlarıyla çalışan ekipler, tekli kontroller ve 100 adrese kadar olan işlemler için https://emailcheckpro.com/mcp adresindeki MCP uç noktasını kullanabilir, dosya tabanlı görevler ise REST API'de kalır.

SSS

Node.js'de e-posta doğrulama için Regex yeterli midir?

Bir Regex, hatalı girdileri yakalamak için yeterlidir ve hiçbir maliyeti olmadığı için ilk sırada çalışmalıdır. Bir adresin teslim edilebilir olup olmadığını bilmesi gereken ekipler, Regex'ten sonra sunucu tarafında bir kontrol ekler ve rıza ile sahiplik için onay bağlantısını korur.

Teslim edilebilirlik kontrolü tarayıcıda mı yoksa sunucuda mı çalışmalı?

Sunucuda. API anahtarı paylaşılan hesap bakiyesini harcar, bu nedenle onu ön uç kodunda açığa çıkarmak herkesin kullanmasına izin verir. Bir sunucu rotası ayrıca kendi hız sınırlarını uygulayabilir, sonucu bir tarihle saklayabilir ve belirlenemeyen veya zaman aşımına uğrayan kontrollerin nasıl ele alınacağına karar verebilir. Tarayıcı, aynı WHATWG desenini kullanarak anlık format ipuçları göstermeye devam edebilir.

Ekipler, bir kontrol belirlenemediğinde gerçek kullanıcıları engellemekten nasıl kaçınabilir?

Adresi reddetmek yerine bir işaretle (flag) kabul edin. Catch-all adresleri gibi belirlenemeyen sonuçlar, bir adresin kötü olduğuna dair kanıt değildir ve ücretlendirilmezler. İşaretlenmiş bir hesap yine de onay e-postasını alabilir; daha sonraki bir iş onu yeniden kontrol edebilir ve gönderim hatları, tamamlanmış bir sonuç veya onay tıklaması kaydedilene kadar işaretlenmiş satırları bekletebilir.

Daha Fazla Bilgi

İş akışınızdaki bir sonraki adıma uygun ürün bilgisini seçin.

• Ürün dokümantasyonunu görüntüleyin →
• Ekiple görüşün →