Gönderdiğiniz teklif geri dönüyor, sipariş bildirimi kuyrukta bekliyor veya şifre sıfırlama e-postası kullanıcıya ulaşmıyor. Böyle bir olayda ilk iş bütün DNS kayıtlarını değiştirmek değil, hangi gönderimin hangi aşamada durduğunu belirlemektir. 550, 554 veya 421 yanıtı incelemeyi yönlendirir; tek başına kök nedeni ve doğru müdahaleyi seçmez.
Bu rehber, e-posta teslim sorununu kayda alma, sorumlu sistemi bulma, kanıta göre düzeltme ve yeniden denemeyi doğrulama sırasını izler. Kodların tek tek standart anlamları ve DSN alanlarının ayrıntılı açıklaması için SMTP kodları ve bounce referansını kullanın. Buradaki örnekler varsayımsaldır; DCHost müşteri vakası veya yapılmış test sonucu değildir.
1. Gönderim olayını ve kullanıcı etkisini kaydedin
Önce beklenen kullanıcı sonucunu yazın: fatura mı ulaşmadı, yalnızca bir alıcı mı etkilendi, yoksa bütün bildirimler mi gecikti? Uygulamanın “gönderildi” durumu yalnız SMTP sunucusuna teslimi ifade edebilir. Mesajın son veri yanıtıyla kabul edilmesi, gelen kutusunda görünmesi ve okunması ayrı sonuçlardır.
Olay kaydına başlangıç zamanı ve saat dilimini, gönderici uygulamayı, kullanılan SMTP hizmetini, etkilenen zarf alıcısını, kuyruk veya sağlayıcı ileti kimliğini ve tam hata yanıtını ekleyin. Aynı kullanıcı birkaç kez gönder düğmesine bastıysa her denemeyi ayrı kaydedin. Bir uygulama kaydı ile MTA kaydının aynı iletiyi anlattığını doğrulamadan bunları tek olay saymayın.
- Yanıttan önce hangi komut vardı: AUTH, MAIL FROM, RCPT TO, DATA veya veri sonu?
- Yanıtı hangi sunucu verdi; uygulamanın bağlandığı submission hizmeti mi, uzak alıcı MX’i mi?
- Bir alıcı, bir domain, bir uygulama veya tüm çıkış trafiği mi etkileniyor?
- Son değişiklik neydi: parola, SMTP hesabı, gönderim kaynağı, DNS, ek boyutu, yazılım veya gönderim hacmi?
- İleti hâlâ kuyrukta mı, sonlandırıldı mı, kabul edildi mi, yoksa sonuç belirsiz mi?
Destek için yalnız gerekli kayıtları paylaşın. Parola, AUTH verisi, API anahtarı ve sıfırlama bağlantısı göndermeyin; kişisel içerik ve adresleri gereksiz yere açığa çıkarmayın. Tam ham kaydı erişimi kısıtlı yerde koruyup paylaşılacak kopyayı maskeleyin. Hata metnindeki bağlantıları da sağlayıcının bilinen sitesi üzerinden doğrulayın.
2. Yeniden denemeden önce alıcının durumunu belirleyin
4xx geçici başarısızlıktır; mesajı kabul etmiş bir MTA çoğunlukla kendi kuyruğundan yeniden dener. 5xx, mevcut komut veya deneme için kalıcı başarısızlıktır ve aynı koşullarla tekrar gönderilmemelidir. Bu ayrım, bütün 5xx alıcılarının geçersiz olduğu veya bütün 4xx olaylarının birkaç dakika içinde çözüleceği anlamına gelmez.
SMTP yanıtı ile bounce aynı şey değildir. Uygulama submission aşamasında doğrudan hata alabilir; bir MTA önceden kabul ettiği iletinin uzak reddi veya kuyruk süresinin dolması nedeniyle sonradan bildirim üretebilir. DSN, görünen From’dan farklı olabilen zarf dönüş adresine yönelir. Bildirim alınmaması tek başına başarılı teslim kanıtı değildir.
| Doğrulanan durum | İlk karar | İzlenecek sonuç |
|---|---|---|
| Kuyrukta, geçici erteleme | Mevcut kuyruğun sahibini ve tekrar zamanını belirleyin; uygulamadan yeni kopya üretmeyin. | Aynı alıcı için kabul, yeni erteleme veya kuyruk ömrü sonunda başarısızlık. |
| Action: failed | Bu alıcıya denemeler bırakılmıştır. Status ve açıklamaya göre nedeni düzeltin. | Gerekliyse ve hâlâ geçerliyse yeni, izlenebilir gönderim. |
| Veri sonunda başarı yanıtı | Bu SMTP aktarımı kabul edilmiştir; sonrasındaki teslim durumunu inceleyin. | Sağlayıcı teslim kaydı, alıcı doğrulaması veya sonradan oluşan bildirim. |
| Veri sonu gönderildi, son yanıt alınamadı | Kabul sonucu belirsizdir; gönderici ve mümkünse alıcı kayıtlarını uzlaştırın. | Yinelenen teslim riski gözetilerek tek sorumlunun yönettiği devam kararı. |
Bir mesajda birden çok alıcı bulunabilir. Bazı RCPT TO komutları kabul edilirken başka alıcılar reddedilebilir veya ertelenebilir. Son veri yanıtını da dikkate alarak her alıcının durumunu ayrı tutun; başarısız bir alıcı nedeniyle başarılı olanların tamamına tekrar gönderim yapmayın.
DSN’den olay kararına: kısa örnek
Aşağıdaki metin varsayımsal bir message/delivery-status parçasıdır; tam MIME e-posta değildir. İleti alanı ve alıcı alanları boş satırla ayrılır:
Reporting-MTA: dns; mail.example.com Final-Recipient: rfc822; alici@example.net Action: failed Status: 5.1.1 Remote-MTA: dns; mx.example.net Diagnostic-Code: smtp; 550 5.1.1 User unknown
Örnekte denemeler belirtilen alıcı için sona ermiştir ve uzak sunucu bulunamayan posta kutusu bildirmiştir. Bunu kendi kuyruk kaydınızla eşleştirip adresi doğrulayın. Yalnız Action: failed görülseydi geçersiz adres sonucuna varamazdınız; boyut veya politika reddi de nihai başarısızlık yaratabilir. DSN alanları sahte olabileceğinden doğrulanmamış raporla otomatik liste değişikliği yapmayın.
3. Müdahalenin hangi sisteme ait olduğunu bulun
Uygulama ile submission sunucusu arasındaki AUTH hatası ve submission sonrasında uzak MX’in verdiği ret farklı olaylardır. İlkinde uygulamanın sunucu adı, portu, TLS seçimi ve hesap yetkisi incelenir; ikincisinde gönderici MTA’nın uzak teslim kaydı gerekir. Uzak alıcı MX’ine kendi posta hesabınızın parolasını vermeye çalışmayın.
| Kanıtın gösterdiği aşama | İnceleme sahibi | Hedefli kontrol |
|---|---|---|
| Uygulama submission hizmetine bağlanamıyor veya AUTH reddediliyor | Uygulama/posta hesabı yöneticisi ve hizmet sağlayıcısı | Doğru uç nokta, TLS modu, etkin hesap, kimlik bilgisi ve yetki. |
| Yerel MTA DNS, disk veya filtre hatası kaydediyor | O MTA’nın işletmecisi | Etkin resolver, depolama, filtre ve kuyruk durumu. |
| Uzak MX belirli alıcıyı veya politikayı reddediyor | Gönderici işletmecisi; gerektiğinde alıcı yöneticisi | Tam uzak yanıt, alıcı kaydı ve gönderilen iletinin kimliği. |
| SMTP kabul edilmiş, kullanıcı iletinin olmadığını söylüyor | Alıcı/posta hizmeti ve gönderici olay sahibi | Sonraki teslim, karantina, klasör/filtre ve varsa yönlendirme kayıtları. |
AUTH sonrasında 535 5.7.8 geçersiz veya yetersiz kimlik bilgisine işaret eder; hesabı ve sağlayıcının desteklediği yöntemi kontrol edin. AUTH sonrasında 454 4.7.0 geçici sunucu arızasıdır; yalnız bu yanıt yüzünden parolayı değiştirmek doğru teşhis değildir. STARTTLS sonrasındaki 454 ise farklı bir TLS bağlamıdır. “Relaying denied” için doğru submission hizmeti ve relay yetkisini inceleyin; bu mesaj tek başına open relay bulunduğunu göstermez.
Paylaşımlı hizmette panel teslim raporu, kuyruk erişimi ve SSH yetkisi plana bağlıdır. Görünmeyen kaydı sağlayıcıdan isteyin. Kendi sunucunuzda bile IP/PTR ve çıkış portu yetkilerinin sağlayıcı tarafından yönetilmesi mümkündür; olayın her adımı için erişim ve sorumluluğu açıkça belirleyin.
Etkin log hedefini doğrulayın: Postfix bazı kurulumlarda /var/log/mail.log, /var/log/maillog veya journal üzerinden izlenir; Exim mainlog/rejectlog konumları kuruluma bağlıdır. Varsayılan loglar bütün SMTP konuşmasını içermeyebilir. Kuyruk kimliği, alıcı, zaman, relay ve hata açıklamasını arayın; eksik ayrıntı için kimlik bilgilerini kaydeden geniş loglamayı gelişigüzel açmayın.
530 için tam yanıtı komutla eşleştirin: işlem kimlik doğrulama gerektiriyor olabilir veya sunucu önce STARTTLS istiyor olabilir. 530 yanıtının AUTH ve STARTTLS bağlamları bu ayrımı açıklar. Doğru, güvenilen submission hizmetini ve TLS modunu doğrulayın; gerekli TLS kurulup doğrulanmadan kimlik bilgisi göndermeyin.
4. Kanıtın gösterdiği düzeltme dalını izleyin
Adres veya alıcı yönlendirmesi
Doğrulanmış 550 5.1.1 User unknown için alıcının yazımını ve yetkili kayıt kaynağını kontrol edin. Kendi domaininizde posta kutusu, alias, yönlendirme ve yerel/uzak teslim seçimini inceleyin. Hatalı adrese otomatik gönderimi durdurun; düzeltilip yeniden doğrulanmadan tekrar denemeyin. Bir adres hatasını tüm domainin veya tüm müşteri listesinin hatası olarak yorumlamayın.
Domain ve bağlantı hatasında alıcı domainin MX kayıtlarını, seçilen MX adlarının A/AAAA yanıtlarını ve gönderen sistemin gördüğü DNS sonucunu inceleyin. Kullanılabilir MX varken alıcı domainin kendisinde A/AAAA olmaması tek başına arıza değildir. MX yokluğunda örtük MX kuralı uygulanabilir; MX 0 . ise domainin posta kabul etmediğini açıkça bildirir. NXDOMAIN, geçici DNS hatası ve erişilemeyen MX aynı durum değildir.
DNS kayıtları rehberi ile gerçek zone verisini karşılaştırın. MX gelen postanın yolunu belirler; başka sunucudan gönderme yetkisi sağlamaz. Registrar transferiyle aynı anda nameserver veya zone değiştiyse ilgili değişikliği araştırın; transferin kendisini otomatik neden saymayın. 553 5.1.3 gibi sözdizimi tanısı ile 5.1.2 hedef domain tanısını da ayırın.
Posta kutusu kotası, sistem depolaması veya mesaj boyutu
“Mailbox full” ile “mailbox disabled” farklıdır: X.2.2 posta kutusu doluluğunu, X.2.1 devre dışı posta kutusunu anlatır. Sistem depolaması ise ayrı bir katmandır. 452 için standart açıklama yetersiz sistem depolamasıdır; ancak RCPT TO sırasında uygulama kaynaklı alıcı sayısı sınırına ulaşıldığında da bu kod kullanılır. Yerel disk doluluğu kanıtlandıysa disk ve inode kullanımı, log/yedek büyümesi ve filtre kuyrukları incelenir; uzak sunucunun dolu diskini kendi VPS’inizde alan açarak düzeltemezsiniz.
Alıcı posta kutusu sizdeyse, saklama yükümlülüklerine ve doğrulanmış arşiv/yedek sürecine uygun biçimde kapasite veya kota düzenleyin. Uzak alıcıdaysa uygun başka bir kanaldan alıcı yöneticisine durumu iletin. Her kota reddini kalıcı geçersiz adres sayıp abonelik kaydını silmeyin; etkin kuyruk ve nihai bildirim durumunu izleyin.
552 5.3.4 ileti başına boyut sınırına işaret eder. Ölçü, ek dosyanın diskteki boyutu değil başlıklar ve MIME kodlaması dahil toplam iletidir. İmzaları ve gömülü görselleri sadeleştirin, ekleri küçültün veya alıcı yetkisi ve uygun süre sınırı bulunan paylaşım bağlantısı kullanın. Hassas belgeyi boyut sınırını aşmak için herkese açık yayımlamayın.
Sınır yerel MTA’ya aitse kapasiteye uygun değişiklik değerlendirilebilir; kendi limitinizi yükseltmek uzak alıcının limitini değiştirmez. Alıcı sayısı sınırı ayrı bir durumdur: kabul edilmiş alıcıları koruyarak kalanları ürünün kuyruk davranışına göre ayırın. Eski 552 “too many recipients” yanıtı bu özel uyumluluk bağlamında geçici başarısızlık olarak ele alınmalıdır; bunu 552 5.3.4 boyut reddiyle karıştırmayın.
Gönderici kimliği, politika veya itibar
550 5.7.1 ve politika açıklaması taşıyan 554 yanıtlarında hangi kontrolün başarısız olduğunu tam metin ve alıcı belgesiyle daraltın. 554 tek başına spam veya IP kara listesi kanıtı değildir; 5.7.26 da hangi mekanizmalar olduğunu belirtmeden birden çok ileti kimliği kontrolünün başarısızlığını bildirir. DNS kaydının var olması, gönderilen iletinin alıcıda o kayda göre geçtiğini göstermez.
- SPF: Alıcıya gerçekten bağlanan çıkış IP’sini ve MAIL FROM/uygun durumda HELO kimliğini bulun. Görünen From alanına bakarak SPF sonucu çıkarılmaz. Değerlendirilen kimlik için tek seçilebilir SPF politikası ve iç içe değerlendirmeler dahil DNS sorgusu doğuran 10 terimlik sınır kontrol edilir.
- DKIM: Gerçek iletideki imzanın alıcıda doğrulanma sonucunu, imzalayan domaini ve seçiciyi inceleyin. İmza varlığı başarı değildir; DKIM güvenli içerik garantisi vermez.
- DMARC: Görünen From domainiyle hizalı başarılı SPF veya DKIM kimliklerinden en az biri gerekir. Tek mekanizmanın başarısızlığı tek başına DMARC başarısızlığı değildir. Genel 5.7.1 yüzünden politikayı gevşetmeden meşru kaynağı ve hizalamayı düzeltin.
- PTR/HELO: Gerçek bağlantı IP’sinin PTR ve ileri DNS tutarlılığını, giden HELO adını ve alıcının şartlarını kontrol edin. Relay hizmeti kullanılıyorsa ilgili IP, uygulama sunucunuzun IP’sinden farklı olabilir.
Panelden yürütülecek işlem için cPanel’de e-posta doğrulama, küçük işletmelerde kaynak envanteri için temel SPF/DKIM/DMARC planı ve IP/DNS ilişkisi için teslim edilebilirlik rehberi yardımcı olur. Gerçek DNS değişikliğini kaydın yetkili olduğu yerde yapın; ilgisiz zone’u düzenlemeyin.
Yönlendirme sırasında SPF veya DKIM sonucu değişebilir. SRS zarf gönderenini yeniden yazsa da görünen From ile DMARC hizalamasını tek başına sağlamaz; doğrudan ve yönlendirilmiş yolu ayrı değerlendirin. DMARC rapor analizi meşru kaynak ve hizalama hatalarını ayırmaya yardımcı olur. Her sağlayıcının rapor göndereceğini varsaymayın; ayrıntılı başarısızlık raporlarında kişisel veri bulunabilir.
Yanıt belirli bir bloklisteyi veya sağlayıcı politikasını işaret ediyorsa gerçekten kullanılan IP/domain için ilgili kanalı kontrol edin. Ele geçirilmiş posta hesabı, web formu veya uygulama bulunduysa önce yetkisiz çıkışı durdurup erişimi ve açığı düzeltin. Sonra ilgili listenin kaldırma sürecini izleyin; bir listeden çıkmak tüm alıcıların kabul edeceği anlamına gelmez. E-posta itibarı kurtarma rehberi bu ayrı iyileştirme sürecini ele alır.
İçerik filtresi kanıtında bozuk MIME/HTML, riskli URL, zararlı ek veya gerçek politika ihlalini inceleyin. Sabit bir “spam kelimeleri” listesi, metin biçimine geçmek ya da IP değiştirmek kabul garantisi vermez. Paylaşımlı çıkışta başka hesaplar da araştırılabilir; kanıt olmadan komşu kullanıcıyı suçlamayın. Dedicated IP ve yeni domain, alıcı reddini aşmak için kullanılacak çözüm değildir.
TLS, ağ veya geçici sunucu arızası
421 hizmetin kullanılamadığını ve bağlantının kapandığını bildirir; her 421 oran sınırı değildir. 450/451 açıklamaları posta kutusu, politika veya işleme arızası gibi farklı nedenlere işaret edebilir. Aynı zaman aralığında etkilenen hedefleri karşılaştırın. Çok sayıda domainde sorun varsa ortak çıkış, resolver, ağ veya yerel filtreyi; tek hedefteyse o hedefe özgü yolu ve yanıtı araştırın.
TLS arızasında başarısız adımı ve yönü belirleyin. Uzak MX’in sertifikası veya STARTTLS desteği hatalıysa kendi gelen posta sertifikanızı yenilemek bu uzak hatayı çözmez. MTA-STS/DANE için gönderenin etkin politikası ve hedefe ilişkin doğrulama kaydı; REQUIRETLS için gerekli aktarım desteği incelenir. Zorunlu TLS’yi kapatarak gönderimi tamamlamaya çalışmayın.
Yanıt açıkça oran sınırı söylüyorsa hedefe giden toplam hacmi, eşzamanlı bağlantıları ve ani kampanya artışını inceleyin. Greylisting ile hacim sınırı aynı mekanizma değildir; belirli sayıda deneme veya sabit birkaç dakika sonra kabul sözü verilemez. Postfix’te default_destination_rate_delay, default_destination_concurrency_limit ve transport’a özel karşılıklarının gerçek kapsamını kontrol edin; alıcı limiti ayarı hedefin domain mi alıcı mı sayılacağını etkileyebilir.
5. Kuyruk ve yeniden deneme için tek sorumlu belirleyin
Geçici hata sürerken MTA kuyruğu ile uygulamanın tekrar mekanizmasının birbirinden habersiz çalışması kopya e-posta oluşturabilir. İletiyi hangi sistemin yeniden denediğini, kuyruk ömrünü ve hedefe göre bekleme süresini kaydedin. Bir sağlayıcı kuyruğu yönetiyorsa onun belgelenmiş davranışını esas alın; başka MTA’nın varsayılanını uygulamayın.
RFC 5321 genel modelde denemeler arasında en az 30 dakika ve vazgeçmeden önce en az 4–5 günlük süre tarif eder; nedene duyarlı değişken stratejiler ve bazı bildirimler için daha kısa sınırlar mümkündür. Bunlar her ürünün varsayılanı değildir. Şifre sıfırlama bağlantısının kullanım süresi gibi iş gereksinimleri ayrıca tasarlanır; SMTP kuyruğu ile uygulamadaki token süresini aynı şey saymayın.
- Alıcı bazında mevcut sonucu ve kuyruk sahibini doğrulayın.
- Kanıtlanan nedeni düzeltin; değişikliği, uygulandığı sistemi ve zamanı kaydedin.
- İleti kuyruktaysa mevcut MTA denemesini izleyin; geniş çaplı kuyruk zorlamasıyla alıcıyı tekrar yüklemeyin.
- Denemeler sonlanmışsa içeriğin hâlâ gerekli ve geçerli olduğunu kontrol edin; başarılı alıcıları yeni gönderime eklemeyin.
- Veri sonunda yanıt kaybında kabul belirsizliğini kayda alın. Sağlayıcı/uygulama düzeyinde desteklenen tekrar önleme mekanizmalarını kullanın; yalnız aynı Message-ID’nin kopyaları engelleyeceğini varsaymayın.
Bir politika veya oran reddinden kaçmak için trafiği başka IP’lere dağıtmayın. Meşru yeni gönderim kaynağında hacim artışı, izinli alıcı talebi ve ölçülen yanıtlarla planlanır. Dedicated IP ısıtma ve itibar yönetimi ancak böyle doğrulanmış bir mimari ihtiyacın parçasıdır; sabit takvimle kabul garantisi değildir.
Kritik Bildirim İçin Doğrulanmış Bir Alternatif Seçin
Fatura veya parola sıfırlama gibi bir bildirim yararlı süresi içinde ulaşmayacaksa, olay sahibi önceden yetkilendirilmiş ve doğrulanmış bir alternatif kanalı ya da kullanıcının erişebildiği kimlik doğrulamalı müşteri portalını değerlendirsin. SMS gibi genel durum bildirimi, faturanın içeriğini veya sıfırlama anahtarını taşımak zorunda değildir; hassas içerik yetkili erişim yolunda kalsın. Hesap kurtarmada ilgili kimlik doğrulama sürecini izleyin; rastgele yeni bir e-posta adresine hassas içerik yönlendirmeyin.
Alternatif bildirim kararını aynı uygulama olayıyla ilişkilendirin. Asıl iletinin kuyruğunu, sonraki teslimini ve bağlantı ya da token’ın geçerlilik durumunu izleyin; yeniden gönderim veya iptal kararını mevcut kuyruk sorumlusuyla koordine edin. Geç ulaşan eski ileti, çift sipariş işlemi, tekrarlanan bildirim veya çelişen hesap kurtarma adımı üretmemelidir.
6. Düzeltmeyi kontrollü bir gönderimle doğrulayın
Yetkili test alıcısı ve hassas olmayan içerikle aynı gönderim yolunu kullanın. Kaynak IP, relay, From/MAIL FROM ve DKIM seçicisi değişirse eski hatayla karşılaştırma kapsamı da değişir. Uygulamadan submission’a, MTA kuyruğundan uzak yanıta kadar ilgili kimlikleri birleştirin; yalnız panelde yeşil durum görmeyi yeterli saymayın.
- Önceki hata hangi aşamada ve kodla oluşmuştu; aynı aşama şimdi hangi sonucu verdi?
- Kabul edilen ve ertelenen alıcılar ayrı kaydedildi mi?
- İleti alıcı tarafında beklenen yere ulaştı mı; sonradan DSN veya karantina oluştu mu?
- Kuyruk yaşı ve büyüklüğü normale döndü mü, yoksa başarılı küçük test devam eden hacim sorununu gizliyor mu?
- İlgili uygulama olayı için istenmeyen kopya bildirim oluştu mu?
Kapanış ölçütünü iş etkisine göre belirleyin: örneğin etkilenen uygulama yolundaki kontrollü teslimin doğrulanması ve sonraki normal trafik boyunca aynı hatanın yeniden oluşmaması. Kullanılan zaman aralığını ve alıcı kapsamını yazın. Bir testin başarısı tüm sağlayıcılarda veya gelecekte teslim garantisi değildir.
Varsayımsal olay: WooCommerce bildirimlerinde iki ayrı hata
Bir mağazada sipariş e-postaları için hem 550 5.1.1 hem de belirli bir domainde 421 4.7.0 Temporary rate limit exceeded görüldüğünü düşünün. Bunlar aynı arızanın kanıtı değildir. Önce sipariş/uygulama kaydı ile alıcı ve kuyruk kimliklerini eşleştirip etkiyi ayırın.
İlk grupta alıcı adresi yetkili kaynaktan yanlış olarak doğrulanırsa otomatik gönderim durdurulur ve düzeltme istenir. İkinci grupta iletiler hâlâ sağlayıcının kuyruğundaysa yeniden sipariş bildirimi üretmek yerine mevcut kuyruğun denemeleri ve hedefe toplam hacim izlenir. Bu varsayımları kayıt doğrulamazsa ilgili dal değiştirilir; sonucu önceden başarılı ilan etmeyin.
Düzeltme sonrasında yalnız gerekli alıcılara yetkili test yapılır, kabul ve alıcı sonucu ayrı doğrulanır. Eğer gerçek tanı kimlik doğrulama veya TLS hatası çıkarsa oran ayarıyla yetinilmez. Olay kaydı, yapılan değişiklik ve ölçülen sonuçla kapanır; “temiz IP’ye taşındı ve bütün hatalar bitti” gibi kanıtsız açıklamalarla değil.
7. Aynı sorunun tekrarını ölçerek azaltın
Adres doğrulama ve çift onay süreci kullanın; doğrulanmış geçersiz adresleri sonraki gönderimlerden çıkarın. Teslim engeli nedeniyle gönderimi durdurmak ile kullanıcının abonelikten çıkma isteğini ayrı kaydedin. Açılma kaydı yokluğu adresin geçersiz veya gönderimin izinsiz olduğuna tek başına kanıt değildir; izin ve abonelik tercihlerini kendi kayıtlarından yönetin.
Kimlik bilgileri ve uygulamaları koruyun; ele geçirilmiş site, form veya hesap kaynaklı çıkışları izleyin. Hesap başına uygun limitler beklenmedik artışı sınırlayabilir, ancak tek başına uyarı veya zararlı yazılım teşhisi değildir. Parola ve uygulama sırlarını güvenli saklayın; DNS ve imza değişikliklerini kontrollü kaydedin.
İşlemsel ve pazarlama trafiğinin kuyruğunu, önceliğini ve gönderim kaynaklarını ihtiyaç varsa ayırın. Alt domain veya IP ayrımı diğer trafiğin itibardan hiç etkilenmeyeceğini garanti etmez. Şifre sıfırlama gibi kritik olaylarda tekrar önleme, geçerlilik süresi ve kullanıcıya gösterilecek durum uygulama tasarımının parçasıdır.
İzlemede toplam hata sayısıyla yetinmeyin: belirli zaman aralığındaki alıcı denemelerini payda alarak hata türü, hedef domain ve gönderim kaynağı bazında oran tutun; tekrarların sayımı şişirebileceğini belirtin. Kuyruk yaşı, nihai başarısızlık, kabul ve şikâyetler farklı ölçümlerdir. Ortalama yanında en eski bekleyen iletiler ve ani artışlar da görünür olsun.
Paylaşımlı hosting, VPS ve fiziksel sunucu seçeneklerini kanıtlanan kapasite ve yönetim ihtiyacına göre değerlendirin. MTA işletimi, port/PTR yetkisi, güvenlik, yedek ve destek sorumluluğunu teyit edin. Daha büyük sunucu yanlış adresi, uygunsuz gönderimi veya uzak alıcının politikasını kendi başına düzeltmez.
Destek kaydını olay zamanı, etki kapsamı, ilgili sunucu/komut, tam diagnostic yanıtı, kuyruk durumu ve yapılan kontrollü değişikliklerle tamamlayın. Böylece sonraki kişi aynı olayı baştan tahmin etmek yerine eldeki kanıttan ilerleyebilir.
Resmî Kaynaklar
Standart anlamlar 4 Kasım 2026’da incelenen aşağıdaki belgeler ve kayıtlarla karşılaştırılmıştır. Ürüne veya alıcı sağlayıcıya özgü davranış için ilgili sürüm ve tam diagnostic yanıtı ayrıca doğrulayın.
