Kurumsal Kontrol Listesi: QA/UAT'ta Geçici e-posta Kullanırken OTP Riskini Azaltma

Özet

• OTP güvenilirliğini, başarı oranı ve TTFOM (p50/p90, p95) dahil olmak üzere ölçülebilir bir SLO olarak ele alın.
• İtibarın ve analizlerin bozulmasını önlemek için QA/UAT trafiğini ve alan adlarını üretimden ayırın.
• Yeniden gönderme pencerelerini standartlaştırın ve rotasyonları sınırlandırın; yalnızca disiplinli yeniden denemelerden sonra rotasyon yapın.
• Gelen kutusu stratejisini test türüne göre seçin: regresyon için yeniden kullanılabilir, kısa süreli yoğun testler için kısa ömürlü.
• Gönderici×alan adı metriklerini arıza kodlarıyla izleyin ve üç aylık kontrol incelemelerini zorunlu kılın.

Geçici e-posta kullanan işletmeler için QA/UAT'ta OTP riskini azaltma kontrol listesi

İşin şaşırtıcı yanı şu: Test ortamlarında OTP güvenilirliği yalnızca bir "posta meselesi" değildir. Bu güvenilirlik; zamanlama alışkanlıkları, gönderici itibarı, gri listeye alma, alan adı seçimleri ve ekiplerinizin stres altında nasıl davrandığının etkileşiminden oluşur. Bu kontrol listesi, bu karmaşayı ortak tanımlara, koruyucu kurallara ve kanıtlara dönüştürür. Geçici gelen kutularında yeniyseniz, önce Temp Mail'in terimleri ve temel davranışları öğrenmek için temel bilgilere göz atın.

1) QA/UAT'ta OTP Riskini Tanımlayın

QA, güvenlik ve ürün ekiplerinin OTP güvenilirliği hakkında aynı dili konuşması için ortak terminoloji belirleyin.

"OTP Başarı Oranı" Ne Anlama Gelir?

OTP Başarı Oranı, politika pencereniz içinde geçerli bir kodun alınması ve kullanılmasıyla sonuçlanan OTP isteklerinin yüzdesidir (örneğin, test akışları için on dakika). Bu oranı gönderen uygulamaya/siteye ve alıcı alan adı havuzuna göre izleyin. Olay analizinin seyrelmesini önlemek için kullanıcıların süreci terk ettiği durumları ayrıca değerlendirme dışı bırakın.

Ekipler için TTFOM p50/p90

"Kod gönder"den ilk gelen kutusuna kadar olan saniyeleri İlk OTP Mesajına Kadar Geçen Süre (TTFOM)—"Kodu gönder" anından mesajın ilk kez gelen kutusuna ulaşmasına kadar geçen saniyelerdir. p50 ve p90'ı (stres testleri için p95'i de) grafik üzerinde gösterin. Bu dağılımlar, varsayımlara dayanmadan kuyruk oluşumunu, hız sınırlamasını ve gri listeye almayı ortaya çıkarır.

Yanlış Negatifler ve Gerçek Başarısızlıklar

Bir kod alındığı hâlde test akışı kodu reddettiğinde, genellikle uygulama durumu, sekmeler arasında geçiş yapılması veya süresi dolmuş zamanlayıcılar nedeniyle bir "yanlış negatif" oluşur. Pencere içinde hiç mesaj ulaşmaması ise "gerçek başarısızlık"tır. Bunları sınıflandırmanızda ayrı tutun; yalnızca gerçek başarısızlıklar rotasyon yapılmasını gerektirir.

Staging Teslim Edilebilirliği Çarpıttığında

Staging uç noktaları ve sentetik trafik kalıpları genellikle gri listelemeyi veya düşük önceliklendirmeyi tetikler. Temel ölçümleriniz üretimden daha kötü görünüyorsa bu beklenen bir durumdur: insan kaynaklı olmayan trafik farklı şekilde dağıtılır. Kısa bir genel bakış için, testler sırasında geçici gelen kutusu modellerinin teslim edilebilirliği nasıl etkilediğini anlatan kısa bir açıklama olan Temp Mail in 2025 genel bakınız.

2) Yaygın arıza türlerini modelleyin

En yüksek etkili teslimat tuzaklarını belirleyin; böylece politika ve araçlarla bunları önceden engelleyebilirsiniz.

Gri Listeleme ve Gönderici İtibarı

Gri listeleme, gönderenlerin daha sonra yeniden denemesini ister; ilk denemeler gecikebilir. Yeni veya "soğuk" gönderici havuzları da itibarları oluşana kadar sorun yaşayabilir. Yeni bir derlemenin bildirim hizmetinin ilk saatlerinde p90 sıçramaları bekleyin.

ISS Spam Filtreleri ve Soğuk Havuzlar

Bazı sağlayıcılar soğuk IP'leri veya alan adlarını daha sıkı inceler. Yeni bir havuzdan çok sayıda OTP gönderen QA çalışmaları kampanyalara benzeyebilir ve kritik olmayan iletileri yavaşlatabilir. Isınma dizileri (düşük ve düzenli hacim) bunu azaltır.

Hız Sınırları ve Yoğunluğun Zirve Yaptığı Anlar

Yeniden gönderme taleplerini art arda ve kısa sürede göndermek hız sınırlarını tetikleyebilir. Yük altında (ör. indirim etkinlikleri veya oyun lansmanları) gönderici kuyrukları uzar ve TTFOM p90 değeri yükselir. Kontrol listeniz, kendi kendinize yarattığınız yavaşlamaları önlemek için yeniden gönderme pencerelerini ve yeniden deneme sınırlarını tanımlamalıdır.

Akışları Bozan Kullanıcı Davranışları

Sekmeler arasında geçiş yapmak, bir mobil uygulamayı arka plana almak ve yanlış takma adı kopyalamak, iletiler teslim edilmiş olsa bile reddedilmeye veya sürenin dolmasına neden olabilir. Testler için kullanıcı arayüzündeki mikro metinlere "sayfada kalın, bekleyin, bir kez yeniden gönderin" ifadesini ekleyin.

3) Ayrı Ortamlar, Ayrı Sinyaller

Gönderici itibarını ve analizleri olumsuz etkilememek için QA/UAT'ı üretimden izole edin.

Staging ve Üretim Alan Adları

Staging amacıyla farklı gönderici alan adları ve reply-to kimlikleri kullanın. Test OTP'leri üretim havuzlarına sızarsa yanlış sonuçlar çıkarabilir ve üretim dağıtımının itibarın önemli olduğu bir anda itibarınızı zedeleyebilirsiniz.

Test Hesapları ve Kotalar

Adlandırılmış test hesapları oluşturun ve bunlara kotalar atayın. Frekans sezgisel kurallarını tetikleyen yüzlerce gelişigüzel hesap yerine, disiplinli birkaç test kimliği kullanmak daha etkilidir.

Sentetik Trafik Pencereleri

Sentetik OTP trafiğini yoğunluğun düşük olduğu zaman aralıklarında oluşturun. Kötüye kullanıma benzeyen bitmek bilmeyen sel baskınları yerine, gecikmeyi ölçümlemek için kısa süreli ani trafik artışları kullanın.

E-posta Ayak İzinin Denetlenmesi

Testlerinizin temas ettiği alan adlarını, IP'leri ve sağlayıcıları envantere kaydedin. Staging kimlikleri için SPF/DKIM/DMARC yapılandırmalarının tutarlı olduğunu doğrulayarak kimlik doğrulama hatalarını teslim edilebilirlik sorunlarıyla karıştırmaktan kaçının.

4) Doğru Gelen Kutusu Stratejisini Seçin

Test sinyallerini istikrarlı hâle getirmek için adresleri ne zaman yeniden kullanacağınıza, ne zaman kısa ömürlü gelen kutuları tercih edeceğinize karar verebilir misiniz?

Regresyon için Yeniden Kullanılabilir Adresler

Uzunlamasına testler (regresyon paketleri, şifre sıfırlama döngüleri) için yeniden kullanılabilir bir adres sürekliliği ve istikrarı korur. Token tabanlı yeniden açma, günler ve cihazlar arasındaki gürültüyü azaltarak birden fazla derlemede benzer sonuçları karşılaştırmak için ideal bir çözüm sunar. Operasyonel ayrıntılar için, tam gelen kutusunu güvenli bir şekilde nasıl yeniden açacağınıza ilişkin talimatlar için 'Geçici Posta Adresini Yeniden Kullan' talimatlara bakın.

Yoğun Testler için Kısa Ömürlü Gelen Kutuları

Tek seferlik yoğunluklar ve keşif amaçlı QA için kısa ömürlü gelen kutuları kalıntıları en aza indirir ve liste kirliliğini azaltır. Ayrıca senaryolar arasında temiz sıfırlamaları teşvik eder. Bir test yalnızca tek bir OTP gerektiriyorsa, 10 Minute Mail kısa ömürlü bir model gayet uygundur.

Token Tabanlı Kurtarma Disiplini

Yeniden kullanılabilir bir test gelen kutusu önemliyse, Access Token'ı bir kimlik bilgisi gibi değerlendirin. Token'ı, test paketinin etiketi altında rol tabanlı erişimle bir şifre yöneticisinde saklayabilirsiniz.

Adres Çakışmalarını Önleme

Takma adları rastgeleleştirmek, temel ASCII kullanmak ve hızlı bir benzersizlik kontrolü yapmak, eski test adresleriyle çakışmaları önler. Her test paketi için takma adların nasıl adlandırılacağını ve saklanacağını standartlaştırın.

5) İşe Yarayan Yeniden Gönderim Pencereleri Belirleme

Zamanlama davranışlarını standartlaştırarak "öfkeyle yeniden gönderme" ve yanlış hız kısıtlamalarını azaltın.

Yeniden Göndermeden Önce Minimum Bekleme Süresi

İlk isteğin ardından tek bir yapılandırılmış yeniden deneme için 60–90 saniye bekleyin. Bu, gri listenin ilk geçişinde başarısız olmanızı önler ve gönderici kuyruklarını temiz tutar.

Tek Yapılandırılmış Yeniden Deneme

Test betiğinde bir resmi yeniden denemeye izin verin, ardından duraklayın. Belirli bir günde p90 süresi uzamış görünüyorsa, herkesin sonuçlarını bozacak yeniden denemeleri spamlamak yerine beklentileri ayarlayın.

Uygulama Sekmeleri Arasında Geçişi Yönetme

Kullanıcılar uygulamayı arka plana aldığında veya uygulamadan ayrıldığında kodlar genellikle geçersiz hale gelir. QA betiklerine açık bir adım olarak "ekranda kal" ifadesini ekleyin; işletim sistemi ve arka plana alma davranışlarını loglara kaydedin.

Zamanlayıcı Telemetrisini Kaydetme

Tam zaman damgalarını kaydedin: istek, yeniden gönderme, gelen kutusuna ulaşma, kod girişi ve kabul/red durumu. Olayları gönderici ve alan adı bilgileriyle etiketleyin; böylece daha sonra adli inceleme yapılabilir.

6) Alan Adı Rotasyonu Politikasını Optimize Etme

Gözlemlenebilirliği parçalamadan gri listeyi aşmak için akıllıca rotasyon yapın.

Gönderici Başına Dönüş Sınırları

Otomatik dönüş ilk başarısızlıkta tetiklenmemeli. Eşikleri göndericiye göre tanımlayın: örneğin, aynı gönderici×alan çifti için iki pencere başarısız olduktan sonra dönüş yapın—itibarı korumak için oturumları ≤2 dönüşle sınırlayın.

Havuz Hijyeni ve TTL'ler

Yaşlı ve taze alanların karışımından oluşan alan havuzları oluşturun. p90 değeri kötüleştiğinde veya başarı düştüğünde "yorgun" alanları dinlendirin; iyileşme sonrasında yeniden kullanıma alın. Gelen kutusunun görünürlüğünün inceleme pencerenizle uyumlu olması için TTL'leri test sıklığıyla hizalayın.

A/B için Yapışkan Yönlendirme

Yapıları karşılaştırırken yapışkan yönlendirmeyi koruyun: aynı gönderici, tüm varyantlarda aynı alan ailesine yönlendirilsin. Bu, metriklerin çapraz kirlenmesini önler.

Dönüşüm Etkinliğini Ölçme

Dönüşüm bir tahmin meselesi değildir. Aynı yeniden gönderme pencereleri altında dönüşüm kullanılan ve kullanılmayan varyantları karşılaştırın. Daha ayrıntılı gerekçe ve koruma önlemleri için bu açıklamadaki OTP için Alan Dönüşümü bölümüne bakın: OTP için Alan Dönüşümü.

7) Doğru Metrikleri Ölçme

Gecikme dağılımlarını analiz edip kök neden etiketleri atayarak OTP başarısını ölçülebilir hâle getirin.

Gönderici × Alan Bazında OTP Başarısı : Üst düzey SLO, sorunun site/uygulamadan mı yoksa kullanılan alandan mı kaynaklandığını ortaya koyan gönderici × alan matrisi temelinde ayrıştırılmalıdır.

TTFOM p50/p90, p95

Ortanca ve kuyruk gecikmeleri farklı şeyler anlatır. p50 günlük sağlığı gösterirken p90/p95 stres, hız sınırlaması ve kuyrukta beklemeyi ortaya çıkarır.

Yeniden Gönderme Disiplini %'si

Resmî yeniden gönderme planına uyan oturumların payını takip edin. Çok erken yeniden gönderim yapıldıysa bu denemeleri teslim edilebilirlik sonuçlarını değerlendirirken hesaba katmayın.

Başarısızlık Sınıflandırma Kodları

Şu kodları benimseyin: ), RT (hız sınırlaması), BL (engellenmiş alan adı; kullanıcı etkileşimi/sekme değiştirme) ve OT (diğer). Olay notlarında kodları zorunlu tutun.

8) Yoğunluk Zirveleri için QA Rehberi Oluşturun

Oyun lansmanlarındaki veya fintech geçişlerindeki trafik patlamalarını kodları kaybetmeden yönetin.

Etkinliklerden Önce Isınma Çalışmaları

Zirveden 24–72 saat önce, bilinen göndericilerden düşük hızda ve düzenli OTP gönderimleri yaparak itibarı ısıtın. Isınma boyunca p90 eğilimlerini ölçün.

Riske Göre Geri Çekilme Profilleri

Risk kategorilerine geri çekilme eğrileri ekleyin. Sıradan siteler için birkaç dakika içinde iki yeniden deneme uygulayın. Yüksek riskli fintech işlemlerinde daha uzun bekleme aralıkları ve daha az yeniden deneme, daha az uyarı tetiklenmesini sağlar.

Canary Rotasyonları ve Uyarıları

Bir etkinlik sırasında OTP'lerin %5–%10'unu bir canary alan adı alt kümesi üzerinden yönlendirin. Canary'lerde p90'ın yükseldiği veya başarı oranının düştüğü görülürse ana havuzu erkenden döndürün.

Bildirim ve Geri Alma Tetikleyicileri

Sayısal tetikleyiciler tanımlayın—örneğin OTP başarı oranı 10 dakika boyunca %92'nin altına düşerse veya TTFOM p90 değeri 180 saniyeyi aşarsa—nöbetçi ekibe bildirim gönderin, pencereleri genişletin ya da dinlenmiş bir havuza geçiş yapın.

9) Güvenli Kullanım ve Gizlilik Kontrolleri

Düzenlemeye tabi sektörlerde test güvenilirliğini sağlarken kullanıcı gizliliğini koruyun.

Yalnızca Alım Yapan Test Gelen Kutuları

Kötüye kullanım vektörlerini sınırlamak ve giden ileti riskini azaltmak için yalnızca alım yapan geçici e-posta adresi kullanın. Ekler yalnızca kapsam dışı değildir — bir Tmailor gelen kutusu dosyaları hiçbir şekilde alamaz, çünkü gelen her ek varışta kaldırılır. Test edilen akış herhangi bir şeyi dosya olarak gönderiyorsa burada doğrulanamaz.

24 Saatlik Görünürlük Pencereleri

Test mesajları geldikleri andan itibaren yaklaşık 24 saat görünür olmalı, ardından otomatik olarak silinmelidir. Bu süre inceleme için yeterince uzun, gizlilik içinse yeterince kısadır. Politika özeti ve kullanım ipuçları için Temp Mail Guide ekipler için güncelliğini koruyan temel bilgileri derler.

GDPR/CCPA Hususları

Akışın izin verdiği her durumda gerçek kişisel verileri test e-postalarından uzak tutun. Bir test bunları gerçekten gerektiriyorsa verileri yalnızca o testin ihtiyaç duyduğu bilgilerle sınırlayın, saklama süresini kısa tutun ve kayıtları, ekran görüntülerini ve kopyalanan kodları hemen ardından temizleyin. Kısa saklama süreleri, temizlenmiş HTML ve görüntü proxy'leme maruziyeti azaltır — ancak paylaşılan, kimlik doğrulamasız bir gelen kutusunu kişisel veriler için güvenli hâle getirmez. Geçici e-posta adresi kontrollü bir veri deposu değildir: adrese sahip olan herkes gelenleri okuyabilir ve gelen kutusunda spam klasörü veya filtre bulunmadığından her gelen mesaj doğrudan gösterilir.

Kayıtların Maskelenmesi ve Erişim

Access Token'ları ve kodları kayıtlardan temizleyin; gelen kutuları için Access Token'lara rol tabanlı erişimi tercih edin. Hangi test gelen kutusunu kimin ne zaman yeniden açtığına ilişkin denetim izlerini tutun. Access Token'ı tek hata noktası olarak ele alın: bu bir şifre değil, kurtarma anahtarıdır; başkalarının adrese erişmesini engellemez ve kaybedilen bir token, Tmailor dahil hiç kimse tarafından yeniden oluşturulamaz.

10) Yönetişim: Kontrol Listesinin Sorumlusu Kim?

Bu belgedeki her kontrol için sorumluluk, uygulama sıklığı ve kanıt belirleyin.

OTP Güvenilirliği için RACI

Sorumlu sahibi (çoğunlukla QA), Hesap verebilir sponsoru (güvenlik veya ürün), Danışılan (infra/e-posta) ve Bilgilendirilen (destek) kişiyi belirtin. Bu RACI'yi repo'da yayınlayın.

Üç Aylık Kontrol İncelemeleri

Her çeyrekte bir, yeniden gönderme pencerelerinin, rotasyon eşiklerinin ve metrik etiketlerinin hâlâ uygulandığını doğrulamak için kontrol listesine göre örnek çalışmalar yapılır.

Kanıt ve Test Materyalleri

Her kontrole ekran görüntüleri, TTFOM dağılımları ve gönderici×alan adı tabloları ekleyin—access token'ları, hizmet verdikleri test paketine referanslarla güvenli bir şekilde depolayın.

Sürekli İyileştirme Döngüleri

Olaylar olduğunda, runbook'a bir uygulama/anti-pattern ekleyin. Eşikleri ayarlayın, alan adı havuzlarını yenileyin ve testçilerin gördüğü metinleri güncelleyin.

Karşılaştırma Tablosu — Rotasyon ve Rotasyon Olmaması (QA/UAT)

Bu tablo mühendislik rehberliğidir, kıyaslama verisi değil. Kasıtlı olarak gecikme veya başarı oranı rakamları taşımıyor: bunlar gönderen platforma, alıcı alana, yapıya ve günün saatine bağlıdır; bu yüzden burada verilen herhangi bir sayı yeniden üretemeyeceğiniz bir sayı olur. Yukarıda tanımlanan metrikleri ölçün ve kendi temel düzeyinizi belirleyin — ardından aşağıdaki satırları kullanarak bu konuda ne yapacağınıza karar verin.

Senaryo	Rotasyon ile	Rotasyon olmadan	Ne izlenmeli?
Gri listeye alınma şüphesi	Bir tam yeniden gönderme penceresi bekleyin, yeniden denemeyi kaydedin, ardından tek bir alternatif alan adıyla karşılaştırın	Tek bir uzatılmış gözlem penceresi boyunca aynı adreste kalın	Erken rotasyon karşılaştırmayı bozar: artık değişen şeyin bekleme mi yoksa alan adı değişikliği mi olduğunu anlayamazsınız
Gönderici kuyruklarının en yoğun olduğu dönemler	Yalnızca bir alıcı alan adı, aynı gönderici yükü altında daha kötü davranıyorsa rotasyon yapın	Bekleme penceresini genişletin ve alan adını sabit tutun	Kuyruk tıkanıklığı genellikle gönderici tarafındadır; bu nedenle alan adını değiştirmek, asıl nedene dokunmadan gürültü yaratır
Soğuk gönderici havuzu	Göndericiyi ısıtın ve küçük bir canary alt kümesini yönlendirin	Yalnızca sabit bir alanda ısıtma yapın	Isıtma disiplini geçiş yapmaktan daha önemlidir; yapıları karşılaştırmadan önce ısıtma dönemini kaydedin
Sabit gönderici	Oturum başına 0–1 rotasyonla sınırlayın	Rotasyon yapmamayı tercih edin	Gereksiz değişiklikler kanıtları parçalar ve sağlıklı bir kontrol akışını bulanıklaştırır
Bir alıcı alan adı işaretlendi	Bir alternatif alan adı deneyin — bu, teslimat hatası için olağan bir sorun giderme adımıdır	Aynı alan adını yeniden denemeye devam edin ve hataları kaydedin	Hangi gönderici × alan adı çiftinin başarısız olduğunu kaydedin; böylece sonuç anekdot niteliğinde değil, yeniden üretilebilir olur
Sitenin politikası tek kullanımlık e-postayı yasaklıyor	Rotasyon yapılacak bir şey yok. Durun.	Geçici e-posta test akışını burada durdurun	Bu bir politika sınırıdır, teslimat sorunu değildir. Akışı gerçek veya şirketin kontrolündeki bir posta kutusuna taşıyın; kabul edilmeye zorlamak için tek kullanımlık e-posta adreslerini dönüşümlü kullanmak, politikayı aşma girişimidir ve QA bunu yapmamalıdır

Nasıl yapılır

OTP testi, gönderici disiplini ve ortamların ayrılması için yapılandırılmış bir süreç; QA, UAT ve üretim izolasyonu için kullanışlıdır.

1. Adım: Ortamları İzole Edin

Ayrı QA/UAT gönderici kimlikleri ve alan adı havuzları oluşturun; bunları üretimle asla paylaşmayın.

2. Adım: Yeniden Gönderme Zamanlamasını Standartlaştırın

Tek bir yeniden deneme yapmadan önce 60–90 saniye bekleyin; oturum başına toplam yeniden gönderme sayısını sınırlayın.

3. Adım: Rotasyon Sınırlarını Yapılandırın

Yalnızca aynı gönderici×alan adı için eşik aşıldıktan sonra rotasyon yapın; oturum başına ≤2 rotasyon.

4. Adım: Token Tabanlı Yeniden Kullanımı Benimseyin

Regresyon ve sıfırlama işlemleri için aynı adresi yeniden açmak üzere access token kullanın; access token'ları bir parola yöneticisinde saklayın.

5. Adım: Metrikleri Ölçümleyin

OTP Başarısı, TTFOM p50/p90 (ve p95), Yeniden Gönderme Disiplini % ve Hata Kodlarını günlüğe kaydedin.

6. Adım: Yoğunluk Provalarını Gerçekleştirin

Göndericileri ısıtın; sapmaları erken yakalamak için uyarılarla canary rotasyonları kullanın.

Adım 7: Gözden Geçirme ve Onaylama

Her kontrolü ekli kanıtlarla birlikte gözden geçirip onaylayın.

SSS

OTP kodları QA sırasında neden geç geliyor da üretimde geç gelmiyor?

Hazırlık ortamı trafiği alıcılara daha gürültülü ve daha soğuk görünür; gri listeleme ve hız sınırlaması, havuzlar ısınana kadar p90'ı genişletir.

"Kodu yeniden gönder" seçeneğine dokunmadan önce ne kadar beklemeliyim?

Yaklaşık 60–90 saniye. Ardından yapılandırılmış tek bir yeniden deneme yapın; daha fazla yeniden gönderim çoğu zaman kuyrukları daha da kötüleştirir.

Alan adı rotasyonu her zaman tek bir alan adı kullanmaktan daha mı iyidir?

Hayır. Rotasyonu yalnızca eşikler aşıldığında yapın; aşırı rotasyon itibara zarar verir ve metrikleri belirsizleştirir.

TTFOM ile teslimat süresi arasındaki fark nedir?

TTFOM, ilk mesajın gelen kutusu görünümünde belirene kadar geçen süreyi ölçer; teslimat süresi, test pencerenizin ötesindeki yeniden denemeleri de içerebilir.

Yeniden kullanılabilir adresler testlerde teslim edilebilirliği olumsuz etkiler mi?

Kendi başına etkilemez. Karşılaştırmaları istikrarlı hâle getirir, Access Token'ları güvenle saklar ve telaşlı yeniden denemeleri önler.

Farklı göndericiler arasındaki OTP başarısını nasıl takip edebilirim?

Metriklerinizi gönderici × alan adı bazında matrisleyerek sorunların bir site/uygulamada mı yoksa bir alan adı ailesinde mi olduğunu ortaya çıkarın.

Geçici e-posta adresleri QA sırasında GDPR/CCPA ile uyumlu olabilir mi?

Evet—yalnızca alım, kısa görünürlük pencereleri, temizlenmiş HTML ve görsel proxy kullanımı gizlilik odaklı testleri destekler.

Gri listeleme ve ısınma, OTP'nin güvenilirliğini nasıl etkiler?

Gri listeleme ilk denemeleri geciktirir; soğuk havuzlar istikrarlı bir ısınma süreci gerektirir. Her ikisi de çoğunlukla p90'ı etkiler, p50'yi değil.

QA ve UAT posta kutularını üretimden ayrı mı tutmalıyım?

Evet. Havuzların ayrılması, hazırlık ortamı gürültüsünün üretim itibarını ve analizlerini bozmasını önler.

OTP başarısı denetimleri için en önemli telemetri hangisidir?

OTP Başarı Oranı, TTFOM p50/p90 (stres testleri için p95), Yeniden Gönderim Disiplini Oranı ve zaman damgalı kanıtlarla birlikte Hata Kodları. Hızlı başvuru için Temp Mail SSS'ye bakınız.