SMTP Kodları ve Bounce Mesajları: Yanıt Referansı

SMTP yanıtını doğru okumak için üç bilgiyi birlikte değerlendirin: üç haneli kod, yanıtın geldiği komut ve varsa genişletilmiş durum kodu. Bounce içindeki DSN alanları bunlara alıcıya özgü teslim sonucunu ekler. Bu referans kodların anlamını ve sınırlarını açıklar; tek başına bir koddan kesin kök neden çıkarmaz.

Bu sayfadaki SMTP yanıtları açıklayıcı örneklerdir; belirli sağlayıcıdan yakalanmış çıktı veya çalıştırılmış test sonucu değildir.

SMTP Yanıtının Anlamı ve Sınırı

SMTP hata kodları, e-posta teslim zincirindeki problemin türü ve geçici mi kalıcı mı olduğu hakkında ipuçları veren işaretlerdir. Sunucular arası iletişim sırasında her kritik adım bir kod ile cevaplanır ve bu kodu doğru okursanız:

• Adres hatası mı, içerik filtresi mi, kota veya boyut sorunu mu olduğunu hata açıklamasıyla birlikte değerlendirebilirsiniz.
• Geçici erteleme ile kalıcı reddi ayırıp kuyruk, bildirim ve düzeltme kararını komut bağlamında değerlendirebilirsiniz.
• Sorunun sizde mi, alıcı tarafta mı, yoksa aradaki ağ ve DNS katmanlarında mı olduğunu loglarla birlikte araştırabilirsiniz.
• Yanıt açıklaması, IP itibarınız, SPF/DKIM/DMARC konfigürasyonunuz veya kara liste sorunlarınız hakkında sinyal verebilir.

Bu yazı komut, yanıt ve DSN başvurusunu kısa senaryolar, teşhis kontrol listesi ve işletim notlarıyla tamamlar. Ayrıntılı olay kaydı, kontrollü düzeltme ve yeniden deneme doğrulaması için e-posta teslim sorunu çözüm rehberini izleyin.

SMTP ve bounce mesajı temelleri

Önce kavramları netleştirelim. SMTP, e-postanın gönderici MTA (Mail Transfer Agent) ile alıcı MTA arasında nasıl taşınacağını tanımlayan protokoldür. Gönderim sırasında şu adımlar kabaca gerçekleşir:

• Gönderici, hedef domainin MX kayıtlarını çözer ve uygun SMTP sunucusunu seçer. MX yoksa RFC 5321’in A/AAAA üzerinden örtük MX kuralı uygulanabilir; null MX ise domainin posta kabul etmediğini bildirir.
• Bağlantı ve sunucu karşılama yanıtından sonra EHLO/HELO, MAIL FROM, RCPT TO ve DATA akışı yürür; desteklenen uzantılar ve güvenlik politikası akışı etkiler.
• Her alıcı için RCPT sonucu ayrı olabilir. Mesaj verisi sonundaki başarılı yanıt kabulü bildirir; her 250 yanıtı mesajın teslim edildiği anlamına gelmez.
• 2xx komut başarısını, 3xx ek girdi beklendiğini, 4xx geçici ve 5xx kalıcı başarısızlığı bildirir. Kabul, gelen kutusunda görünme veya okunma garantisi değildir.

Hata iki şekilde karşınıza çıkar:

Anlık SMTP hatası (synchronous)

Gönderici MTA, bağlantı sırasında karşı sunucudan doğrudan bir 4xx veya 5xx kodu alır. Bu yanıt SMTP oturumu sırasında alınır; kullanıcının hatayı ne zaman göreceği ise ayrı bir konudur. Mesajı önceden kabul etmiş olan gönderici MTA, 4xx yanıtında genellikle yeniden denemek üzere kuyruğa alır; teslimi engelleyen 5xx yanıtında ise göndericiye sonradan bir başarısızlık bildirimi oluşturabilir. Loglarda doğrudan SMTP oturumu içinde bu kodu görürsünüz.

Sonradan gelen bounce (asynchronous)

Bazen alıcı sunucu mesajı ilk etapta kabul eder, ancak daha sonra içerik filtresi, virüs taraması veya alıcı posta kutusu kotası gibi nedenlerle teslim edemez. Bu durumda teslim edilemedi bildirimi (Delivery Status Notification), SMTP zarfındaki geri dönüş adresine gönderilebilir; bu adres görünen From adresinden farklı olabilir. Bounce, yalnızca alıcı sunucuda sonradan oluşan hatalardan kaynaklanmaz: Gönderici MTA da uzak sunucunun kalıcı reddi veya yeniden deneme süresinin dolması üzerine bildirim oluşturabilir. Kullanıcı genellikle posta kutusunda postmaster veya mailer-daemon benzeri bir göndericiden gelen geri dönüş mesajı görür.

Kodun tamamını, açıklamayı, yanıtın hangi komuta geldiğini ve olay zamanını saklayın. DSN’nin Action alanı “delayed” ise deneme sürüyor, “failed” ise bu alıcı için denemeler bırakılmıştır; Status 4.x.x olsa bile nihai başarısızlık bildirimi oluşabilir. Paylaşılacak kayıtlardan kimlik bilgilerini ve gereksiz kişisel verileri çıkarın.

4xx: Geçici SMTP Yanıtları

4 ile başlayan SMTP hata yanıtları, geçici başarısızlık bildirir. E-posta gönderim platformları bu tür teslim sorunlarını sıklıkla soft bounce olarak sınıflandırır; ancak her 4xx yanıtı kullanıcıya hemen bir bounce e-postası gönderildiği anlamına gelmez. Gönderici MTA genellikle belirli bir süre boyunca mesajı kuyrukta tutar ve tekrar göndermeyi dener. Bu hataları görürseniz, mesajın mutlaka kaybolduğu anlamına gelmez; ama sebebi doğru anladığınızdan emin olmanız gerekir.

421 Service not available

Örnek mesaj satırı:

421 4.3.2 Service not available, closing transmission channel

Anlamı:

• Yanıtı veren SMTP sunucusu hizmeti geçici olarak sağlayamıyor ve bağlantıyı kapatıyor.
• Aşırı yük, bakım veya bağlantı limitinin dolması olası nedenlerdir; kod tek başına hangisinin geçerli olduğunu göstermez.

Yorumlama sınırı:

• 421 bağlantıyı kapatma anlamını taşır; yalnız ilk bağlantıda verilmesi gerekmez.
• Bakım, kapasite veya oran politikası olası nedenlerdir; hangisinin geçerli olduğunu tam açıklama ve yanıtı veren sunucu belirler.
• Örnekteki 4.3.2, sistemin ağ iletilerini kabul etmediği geçici durumu daraltır; bütün 421 yanıtlarına bu ayrıntıyı atamayın.

450 Requested mail action not taken: mailbox unavailable

Örnek:

450 4.2.0 Mailbox temporarily unavailable

Sunucunun hata açıklamasına bağlı olarak bu kod:

• Alıcı posta kutusunun geçici olarak kilitli olduğu,
• Posta kutusu kotasının dolduğu ve sunucunun bunu geçici hata olarak bildirdiği,
• Virüs taraması sırasında geçici blokaj uygulandığı

gibi durumlarda görülür.

İlgili kontrol:

• Aynı alıcıya farklı zamanlarda gönderilen e-postalarda da 450 görüyorsanız, alıcı taraf posta kutusu veya depolama sorunu ihtimalini iletin.
• Kendi sunucunuzda ise, disk ve quota değerlerini, özellikle paylaşımlı hosting ortamında cPanel veya Plesk üzerinden kontrol edin.

451 Requested action aborted: local error in processing

Örnek:

451 4.3.0 Temporary server error. Please try again later

451 yanıtı, yanıtı veren sunucuda işleme hatası bildirir. Aşağıdakiler olası örneklerdir; kod tek başına bunlardan birini seçmez:

• Virüs tarayıcı, spam filtresi veya harici bir API modülünün çökmesi,
• Veritabanı bağlantı hataları,
• DNS sorgularında geçici sorunlar.

451 yanıtını veren sunucu sizin yönetiminizdeyse:

• Sunucu yükünü ve sistem loglarını inceleyin.
• DNS tarafında genel bir sorun olup olmadığını kontrol edin; DNS tarafında sorun yaşandığında sitelerinizin de etkilenebileceğini unutmayın. Bu konuyu derinlemesine ele aldığımız DNS hata teşhis rehberine de göz atabilirsiniz.

452 Insufficient system storage

Örnek:

452 4.3.1 Insufficient system storage

Bu örnekte yanıtı veren SMTP sunucusu yetersiz depolama bildiriyor. Hatanın hangi sunucudan geldiğini loglardan belirleyin; disk ve depolama incelemesini o sunucuda yapın. Sunucu sizin yönetiminizdeyse:

• VPS, dedicated veya colocation sunucunuzda df ve izleme araçlarıyla disk kullanımını kontrol edin.
• Log dosyalarının şişmesi, yedeklerin yanlış dizinde tutulması gibi klasik sorunlara bakın.
• Disk alanı sorunu sık tekrar ediyorsa, kaynak planlama tarafında adım atmanız gerektiğini gösteren sinyallerden biridir; bu konuda doğru VPS boyutlandırma ve depolama planlaması rehberimiz işinize yarayacaktır.

454 ve 455: Komuta Göre Farklı Geçici Hatalar

Aşağıdaki yanıtlar ayrı bağlamlara aittir; tek SMTP oturumu değildir:

454 4.7.0 Temporary authentication failure
454 TLS not available due to temporary reason
455 Server unable to accommodate parameters

AUTH sonrasında 454, geçici sunucu kimlik doğrulama arızasıdır; otomatik parola değiştirme önerisi değildir. STARTTLS sonrasında 454, TLS’nin geçici kullanılamadığını bildirir. 455 ise MAIL FROM/RCPT TO parametrelerinin o anda karşılanamadığını gösterir; genel SPF/DKIM/DMARC reddi değildir. Tanınmayan veya uygulanmayan MAIL FROM/RCPT TO parametresi için 555 kullanılır. Komutu, EHLO’da duyurulan uzantıları ve sunucu logunu inceleyin. Zorunlu TLS politikasını hatayı aşmak için düşürmeyin.

5xx: Kalıcı SMTP Yanıtları

Alıcı sayısı için bir uyumluluk istisnası vardır: RFC 5321, eski 552 “too many recipients” yanıtının istemci tarafından geçici ele alınmasını tarif eder. Bu durum 552 5.3.4 ileti boyutu reddinden ayrıdır.

5 ile başlayan SMTP hata yanıtları, ilgili komut veya teslim denemesi için kalıcı başarısızlık bildirir. Teslimi engelleyen bu yanıtlar genellikle hard bounce olarak sınıflandırılır; bu, alıcı adresinin mutlaka geçersiz olduğu anlamına gelmez. Bu tür bir hata aldığınızda, aynı içeriği, aynı alıcıya tekrar tekrar göndermek genellikle hiçbir şeyi değiştirmez; önce sorunu düzeltmeniz gerekir.

500, 501, 503: Sözdizimi ve protokol hataları

500 tanınmayan komutu, 501 parametre veya argüman sözdizimini, 503 yanlış komut sırasını bildirir. Bunlar farklı protokol durumlarıdır; ilgili örneğe göre aşağıdaki alanlar incelenir:

• SMTP komutlarının yanlış kullanılması veya yanlış sırayla gönderilmesi,
• Hatalı HELO/EHLO formatı,
• Eksik veya yanlış MAIL FROM ve RCPT TO sözdizimi

Uygulama veya MTA kaydında gerçekten gönderilen komutu ve yanıtı eşleştirin; bu kodlardan doğrudan DNS ya da parola arızası sonucu çıkarmayın.

Örneğin:

501 5.5.4 Invalid domain name in HELO

Bu durumda:

• Giden HELO/EHLO adını kontrol edin; RFC 5321, uygun ad yoksa adres literalini de tanımlar. Operasyonel bir posta sunucusunda geçerli FQDN kullanmak ve alıcı politikasını karşılamak tercih edilir; yalnız sistem hostname değerine bakmak yeterli değildir. Postfix’te giden ad smtp_helo_name ile belirlenir ve varsayılanı myhostname değeridir.
• Reverse DNS (PTR) kaydınızı bu FQDN ile uyumlu olacak şekilde ayarlayın; bu adın A/AAAA kaydı da gönderen IP’ye dönmelidir. Bu DNS tutarlılığı kontrolü, hatalı HELO sözdizimini düzeltmenin yerine geçmez.
• PTR değişikliğinin hangi IP sağlayıcısı veya yönetim arayüzü üzerinden yapılabildiğini doğrulayın; DCHost planınızın destek ve yetki kapsamını ayrıca teyit edin.

530: Kimlik Doğrulama mı, Önce STARTTLS mi?

530 5.7.0 Authentication required, RFC 4954’e göre istenen işlem için kimlik doğrulama gerekirken bunun henüz geçerli olmadığını bildirir. RFC 3207 ise önce TLS isteyen, genel MX hizmeti olmayan bir sunucunun 530 Must issue a STARTTLS command first yanıtını kullanabileceğini belirtir; genişletilmiş kod burada da 5.7.0 olabilir.

Bu nedenle yalnız 530 veya 5.7.0 sayısından dal seçmeyin: önceki komutu ve yanıtın tamamını okuyun. Uygulama gönderiminde sağlayıcının yapılandırılmış, güvenilen submission uç noktasını ve TLS modunu doğrulayın. Gereken TLS bağlantısı kurulup doğrulanmadan kimlik bilgisi göndermeyin; ardından hizmetin gerektirdiği AUTH işlemini değerlendirin. Uzak alıcı MX’ine kendi posta hesabınızın parolasını vermek bu yanıtın genel çözümü değildir.

550 Requested action not taken: mailbox unavailable

Geçersiz alıcı adresi için örnek yanıtlar:

550 5.1.1 User unknown
550 5.1.1 Recipient address rejected: User does not exist

Bu 550 5.1.1 örneklerinde sunucu, alıcı e-posta adresinin bulunamadığını bildiriyor; adres yanlış yazılmış veya silinmiş olabilir. Tek başına 550 kodu ise başka ret nedenleri için de kullanılabilir. Özellikle toplu gönderim yapanlarda eski, bozuk, yazım hatalı listeler yüzünden bu hata oranı çok yükselir.

İlgili kontrol:

• Doğrulanmış 5.1.1, bu alıcı posta kutusunun bulunmadığını bildirir. 550 tek başına aynı kesinliği sağlamaz.
• Açılma kaydı bulunmaması SMTP adres geçerliliği testi değildir; liste doğrulaması ve izin ayrıca değerlendirilir.
• Gönderimi durdurma ve düzeltme süreci için itibar kurtarma rehberindeki ilgili kontroller kullanılabilir.

550 5.7.1: Permission denied veya spam şüphesi

Bu hata genelde şöyle görünür:

550 5.7.1 Message rejected due to spam or policy reasons
550 5.7.1 Relaying denied

SMTP yanıtını veren sunucu, mesajı veya relay isteğini politikaları gereği reddediyor. Muhtemel sebepler:

• Gönderici IP kara listede (RBL listeleri).
• SPF, DKIM veya DMARC kayıtlarınız hatalı veya hiç yok.
• Gönderdiğiniz içerik, spam filtrelerinin hassas olduğu kalıplarla dolu.
• Kullandığınız SMTP sunucusu, hedef domaine relay yapmanıza izin vermiyor; kimlik doğrulama ve relay yetkilerini kontrol edin. Bu yanıt tek başına sunucunuzun open relay olduğunu göstermez.

Bu durumda:

Koddan hangi kontrolün başarısız olduğunu seçmeyin. Kimlik doğrulama açıklaması varsa gerçek iletinin doğrulama ve hizalama sonucunu, blokliste belirtilmişse ilgili IP ve listeyi, relay reddiyse kullanılan submission hizmeti ve yetkiyi inceleyin. Kimlik doğrulama rehberi bu ayrı kontrolleri açıklar; kök neden düzeltilmeden delist veya genel DNS değişikliği önerilmez.

552 5.3.4: Message size exceeds fixed maximum message size

Örnek:

552 5.3.4 Message size exceeds fixed maximum message size

Bu örnekte sunucu, toplam mesajın kendi boyut sınırını aştığını bildirir. MIME kodlaması ve başlıklar da boyuta dahildir; ek dosyanın diskteki boyutu tek başına yeterli ölçü değildir. Özellikle büyük ek dosyalar, HTML içinde gömülü görseller veya inline resimlerle şişen bildirim e-postaları bu hataya yol açar.

Boyut sınırıyla ilişkisi:

• Uygulamanızda maksimum ek boyutunu mantıklı bir seviyede sınırlayın.
• Gereksiz görselleri ve ağır imzaları sadeleştirin.
• Büyük dosya için uygun paylaşım alanı kullanabilirsiniz. Hassas belgelerde alıcı yetkisini, bağlantı süresini ve erişim kaydını koruyun; yalnızca boyut sınırını aşmak için dosyayı herkese açık yayımlamayın.

554: Transaction failed

554, işlem başarısızlığını bildirir; bağlantı açılışında “No SMTP service here” anlamında da kullanılabilir. Aşağıdaki yanıtlar açıklayıcı örneklerdir, gerçek bir sağlayıcının hata çıktısı değildir:

554 5.7.1 Service unavailable; Client host blocked
554 5.7.1 Message rejected by content policy

Bu politika retlerinin olası nedenleri:

• İçerik filtresi (spam, virüs, zararlı link) tarafından reddedilme,
• IP itibarına bağlı tam blok,
• Belirli bir ülke, ASN veya IP aralık politikasına takılma

Bu örnekler politika reddini gösterir. 5.2.0 ise “diğer veya tanımlanmamış posta kutusu durumu”dur; genel içerik filtresi anlamına gelmez. Gerçek yanıtta kod ve metin çelişiyorsa ham kaydı koruyup yanıtı veren sağlayıcının belgesiyle doğrulayın; hata içindeki bağlantıyı da güvenilir kanaldan kontrol edin.

Genişletilmiş SMTP durum kodları (x.y.z) nasıl okunur?

Üç haneli SMTP yanıtına ek olarak RFC 3463 ve sonraki kayıtlarda tanımlanan class.subject.detail biçimindeki genişletilmiş kod görülebilir. Güncel anlamlar IANA kaydında tutulur. Örnekler:

550 5.1.1 User unknown
451 4.4.1 No answer from host

İkinci kısım olan x.y.z, SMTP yanıtına daha ayrıntılı bir sınıflandırma ekler.

• İlk bileşen: 4 geçici, 5 kalıcı hatayı gösterir; 2 ise başarı durumları içindir.
• İkinci bileşen: Hatanın ana kategorisini belirtir.
• İkinci ve üçüncü bileşenler bir ile üç rakam içerir. Örneğin 5.7.26 geçerli biçimdedir; ayrıntı bilinmiyorsa sınıf ve kategori korunarak raporlanır.

Sık görülen kategorilerden bazıları:

• 5.1.x: Adresleme hataları (var olmayan kullanıcı, hatalı domain vb.).
• 5.2.x: Kalıcı posta kutusu sorunları (örneğin devre dışı posta kutusu). Kota doluluğu sıklıkla geçici 4.2.2 ile bildirilir.
• 5.3.x: Kalıcı sistem sorunları (örneğin yapılandırma hataları). Posta sistemi depolamasının doluluğu ise geçici 4.3.1 ile bildirilir.
• 5.4.x: Ağ ve yönlendirme sorunları (DNS veya routing hataları).
• 5.7.x: Güvenlik, politika ve yetkilendirme hataları (spam, relay denied, kimlik doğrulama sorunları).

5.7.1 yetkilendirme/politika reddini bildirir; hangi kontrolün başarısız olduğunu tek başına söylemez. 4.4.1 bağlantı girişimine karşı taraftan yanıt alınmadığını, 4.4.2 ise kurulmuş bağlantının işlemi tamamlayamadığını belirtir. Bunlardan doğrudan DNS veya içerik arızası sonucu çıkarmayın.

Bir bounce mesajını satır satır okumak

Elinize gelen klasik bir bounce mesajı genelde şu bileşenlerden oluşur:

• Konu satırı (Delivery Status Notification, Undelivered Mail Returned to Sender vb.).
• Özet açıklama (kısa insan okunabilir metin).
• Diagnostik kod ve uzak sunucu cevabı.
• Orijinal iletinin başlıkları ve bazen tamamı.

Aşağıdaki metin, aynı varsayımsal olayın insan tarafından okunan açıklamasını ve delivery-status alanlarını bir arada gösterir; tam MIME ileti değildir. Gerçek DSN’de Reporting-MTA gibi ileti alanları ile alıcıya ait alanlar boş satırla ayrılır:

Mail delivery failed: returning message to sender

This illustrative message could not be delivered.
<alici@example.net>: host mx.example.net[203.0.113.10] said:
    550 5.1.1 <alici@example.net>: User unknown
    (in reply to RCPT TO command)

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

Burada dikkat etmeniz gereken kritik satırlar:

• Reporting-MTA, bildirilen teslim/iletme denemesini yapan MTA’dır. Örnekte uzak RCPT reddini raporlayan gönderen sunucudur.
• Final-Recipient, bu alan grubunun alıcısıdır; birden fazla alıcı varsa her alıcının sonucu ayrı değerlendirilir.
• Action: failed denemelerin bu alıcı için bırakıldığını; Status: 5.1.1 bulunamayan posta kutusunu bildirir.
• Remote-MTA, uzak sunucunun diagnostic yanıtı verdiğini belirtir. Uzak sunucu devreye girmediyse bu alan bulunmamalıdır.
• Diagnostic-Code taşımanın gerçek hata açıklamasını saklar. DSN de sahte olabilir; otomatik liste değişikliğinden önce kaydı kendi gönderim, zarf alıcısı ve kuyruk kimliğiyle ilişkilendirin.

Örnekte uzak sunucu RCPT TO aşamasında alıcıyı bulamadığını bildirir. Bu sonuç yalnız belirtilen alıcı ve işlem içindir. Raporu kendi gönderiminizle ilişkilendirin; bir doğrulanmamış bounce üzerinden tüm domaini veya bütün 5xx alıcılarını geçersiz saymayın.

551 ve 553: Yerel Olmayan Alıcı ve Posta Kutusu Adı

Aşağıdaki yanıtlar ayrı açıklayıcı örneklerdir:

551 User not local; please try <forward-path>
553 5.1.3 Invalid destination mailbox address syntax
553 5.1.2 Bad destination system address

551 yerel olmayan alıcı için bir yönlendirme adresi önerir; tek başına farklı submission hizmetine giriş yapmanız gerektiği anlamına gelmez. 553 kabul edilmeyen posta kutusu adıyla ilgilidir. 5.1.3 sözdizimini, 5.1.2 posta için geçersiz hedef sistemi/domaini daraltır. Hangi komuttaki hangi adresin reddedildiğini belirleyin; MAIL FROM, RCPT TO ve görünen From farklı alanlardır.

Yönlendirme adresini güvenilir kanaldan doğrulamadan otomatik değiştirmeyin. Tam adresi uygulamanın desteklediği ayrıştırıcıyla doğrulayın; tırnaklı yerel kısımlar veya uluslararası adres desteği nedeniyle basit bir “boşluk olamaz” kuralı yeterli değildir.

Komuta Göre Başarı ve Hata Yanıtları

Aynı yanıt, önceki komut bilinmeden eksik yorumlanır. Aşağıdaki tablo temel akışın seçilmiş yanıtlarını gösterir; bütün uzantıları veya sağlayıcı politikalarını kapsayan eksiksiz bir liste değildir.

Veri sonundaki başarı yanıtı kaybolursa istemci kabul gerçekleşip gerçekleşmediğini bilemeyebilir. Aynı mesajı yeniden üretmek kopya teslim riski yaratır. RFC 5321 §4.5.3.2.6 bu son yanıt aşamasındaki zaman aşımını özellikle ayırır; aşağıdaki kuyruk kontrolünü kullanın ve ayrıntılı olay kaydı için çözüm rehberine başvurun.

Çok Satırlı Yanıt ve Kod–Metin Uyumsuzluğu

Çok satırlı SMTP yanıtında devam satırlarında kodun ardından kısa çizgi, son satırda boşluk bulunur. Her satır aynı üç haneli kodu kullanır. Aşağıdaki bağımsız biçim örneği gerçek bir sunucunun yetenek listesi değildir:

250-First line
250-Second line
250 Last line

Yanıtı ilk satırda kesmeyin; son satıra kadar açıklama ve bağlamı koruyun. 250- bir başarısızlık veya farklı bir kod değildir. Üç haneli SMTP yanıtı ile 5.1.1 gibi genişletilmiş kod farklı biçimlerdir. Gerçek sunucu standart anlamla uyuşmayan metin verirse kaydı değiştirmeyin; ham yanıtı ve sağlayıcı açıklamasını yan yana değerlendirin.

Genişletilmiş Kodlar İçin Ayrım Tablosu

SPF, MAIL FROM veya uygun durumda HELO kimliği için çıkış IP’sini değerlendirir. DKIM seçilmiş kanonik başlık/gövde üzerinden imzayı doğrular. DMARC için görünen From domainiyle hizalı başarılı SPF veya DKIM kimliklerinden en az biri gerekir. Bunlar SMTP AUTH oturum girişinden farklıdır. PTR ve ileri DNS tutarlılığı da ayrı bir kontroldür; hiçbirinin varlığı tek başına gelen kutusu garantisi değildir.

Taşıma güvenliğinde de yönü koruyun: STARTTLS oturumun TLS’ye yükseltilmesi, MTA-STS/DANE hedefin politika doğrulaması, REQUIRETLS ise iletinin aktarım gereksinimiyle ilgilidir. Zorunlu politika başarısızlığını açık metne sessiz geçişle aşmayın. Kendi gelen posta politikanız, uzaktaki alıcı sunucunun TLS arızasını düzeltmez.

DSN Alanının Bildirdiği Sonuç ve Bildirmediği Şey

Bir DSN’nin asgari alanları Reporting-MTA ile her alıcı için Final-Recipient, Action ve Status’tur. İsteğe bağlı alanın yokluğu tek başına bozuk DSN kanıtı değildir. Her alıcı grubunu ayrı işleyin; geçersiz adres için gönderimi durdurmayı kullanıcının abonelikten çıkma isteğiyle aynı kayıt olarak değerlendirmeyin.

Yaygın Teslim Sorunlarında İlk Karar

Aşağıdaki senaryolar varsayımsaldır. Kararı yalnız koddan değil, kendi gönderiminizle eşleştirilmiş tam yanıttan verin; aynı anda birden fazla neden bulunabilir.

Bağımsız açıklayıcı yanıt örnekleri; bunlar tek SMTP oturumunun çok satırlı cevabı değildir:

550 5.7.1 Message rejected as spam
554 5.7.1 Service unavailable; Client host blocked
451 4.7.0 Try again later (greylisting)
421 4.7.0 Temporary rate limit exceeded

Teşhis İçin Kısa Kontrol Listesi

1. Olayı ve sorumlu katmanı belirleyin. Saat ve saat dilimini, SMTP komutunu, tam yanıtı, kuyruk/sağlayıcı kimliğini, zarf alıcısını ve yanıtı veren sunucuyu kaydedin. Adres/posta kutusu, politika/kimlik veya sistem/ağ ayrımını ayrıntılı kodla daraltın. Reporting-MTA ile Remote-MTA’yı aynı sunucu varsaymayın.
2. Alıcıyı ve yönlendirmeyi doğrulayın. Adresi güvenilir kanaldan kontrol edin; alıcı domainin MX’ini ve seçilen MX hedefinin A/AAAA çözümlemesini inceleyin. MX yoksa SMTP’nin örtük MX kuralı devreye girebilir; kullanılmaz MX veya posta kabul etmediğini bildiren null MX bununla aynı değildir. Domain taşımasında yetkili DNS bölgesini ve panelde yerel/uzak posta yönlendirmesini kontrol edin.
3. Gerçek gönderen kimliğini inceleyin. SPF’nin gerçek, meşru çıkış IP’sini MAIL FROM/HELO kimliği için yetkilendirdiğini kontrol edin. DKIM seçicisini, gerçek doğrulama sonucunu ve DMARC raporlarındaki görünen From hizalamasını karşılaştırın. SPF’de DNS sorgusu doğuran terimlerin iç içe değerlendirme dahil 10 sınırını gözetin; meşru kaynakları koruyarak gereksiz bağımlılıkları kaldırın, otomatik flattening önerisini varsayılan çözüm saymayın. PTR değişikliği IP sağlayıcısının yetkisinde olabilir. DKIM pass tek başına hizalama veya gelen kutusu garantisi değildir.
4. Bağlantı ve TLS yönünü ayırın. Uygulama–submission bağlantısı ile MTA–alıcı MX aktarımında host, port, erişim, sertifika ve zorunlu TLS politikasını ayrı kontrol edin. Uzak MX arızası için uygulamanın SMTP AUTH parolasını değiştirmek veya zorunlu şifrelemeyi kapatmak çözüm değildir.
5. Kuyruğun sahibini bulun. Uygulama isteği, yerel MTA ve dış sağlayıcı aynı yeniden denemeyi birlikte üretmemelidir. 452 alıcı sınırında başarılı veri sonu kabulünden sonra yalnız o aktarımda kabul edilmeyen alıcılar yeniden denenir; kabul edilmiş alıcıları yeni bir tam listeyle tekrar göndermeyin. Son yanıt kaybolduysa uygulama ve MTA/sağlayıcı kayıtlarını karşılaştırın; Message-ID tek başına tekrar teslimi engellemez. MTA’nın yeniden deneme aralığı ve toplam kuyruk ömrü ayrı ayarlardır; tek kullanımlık kodun işlevsel ömrü SMTP kuyruk süresiyle aynı değildir.
6. Log ve ölçümleri birlikte okuyun. Postfix/Exim’in etkin log hedefini, örneğin yapılandırmaya göre /var/log/mail.log, /var/log/maillog veya journal kayıtlarını ve alıcı bazındaki kuyruk durumunu inceleyin; her kurulum tam SMTP konuşmasını kaydetmez. Kuyruk derinliği, en eski iletinin yaşı, 4xx/5xx oranı ve hedef domain dağılımını aynı zaman aralığında karşılaştırın. Oranın paydasının ileti, alıcı veya deneme olduğunu belirtin; yeniden denemeler sayacı büyütebilir. Paylaşımlı hostingde yalnız erişebildiğiniz panel kayıtlarını alın, MTA kanıtını sağlayıcıdan isteyin.

Altyapı Seçimi ve İşletim Sorumluluğu

Postfix’te default_destination_rate_delay, default_destination_concurrency_limit ve default_destination_recipient_limit farklı kontrollerdir. Transport’a özel ayarlar bunları geçersiz kılabilir; recipient limit 1 olduğunda hedefe göre gecikme/eşzamanlılık kapsamı domainden alıcıya değişir. Exim’de kullanılan sürümün router, transport ve retry yapılandırmasını inceleyin; Postfix parametrelerini Exim’e kopyalamayın. Evrensel bir güvenli hız değeri yoktur: belgelenmiş alıcı sınırları ve kuyruk ölçümleriyle küçük değişiklikleri değerlendirin.

Güncellemeler, erişimi sınırlı merkezi loglar, kuyruk büyümesi/yaşı alarmları ve geri yüklemesi denenmiş posta/yapılandırma yedekleri işletim planına dahildir. Birden fazla MX, alıcı listeleri, filtre ve yönlendirme tutarlı kurulursa gelen posta için dayanıklılık sağlayabilir; tek başına giden posta sorunlarını çözmez. Teknik kararları ilgili kurulum ve yedekli MX rehberleriyle ayrıntılandırın.

Aynı Hataların Tekrarlanmasını Azaltmak

• Liste hijyeni: İzinli kayıt ve uygun olduğunda double opt-in kullanın; doğrulanmış geçersiz adresleri gönderimden çıkarın. Geçersiz adres baskılaması ile kullanıcının abonelikten çıkması ayrı kayıtlardır; açılma oranını adres doğrulaması veya teslim kanıtı saymayın.
• Kötüye kullanım kontrolü: SMTP/API kimlik bilgilerini koruyun, desteklenen yönetim girişlerinde MFA kullanın. Ele geçirilmiş WordPress, eklenti veya formların gönderimini durdurup kaynağı temizleyin; hesap başına limit ve anormal gönderim/kuyruk alarmı kurun.
• Ölçülü başlangıç: Yeni IP veya domain üzerinde meşru, izinli trafiği kademeli artırın; ret/erteleme ve şikâyetleri izleyerek hızı ayarlayın. Sabit bir ısıtma takvimi kabul garantisi vermez; engellenen akışı başka IP’ye taşımak kök neden düzeltmesi değildir.
• Akış ayrımı: Şifre sıfırlama ve sipariş gibi işlemsel iletiler için pazarlamadan ayrı kuyruk, öncelik ve gönderim kaynağı planlayın. Böylece toplu gönderim kritik bildirimleri daha az bekletir; ortak domain/IP itibarının tamamen yalıtılacağını varsaymayın.

Bu Referanstan Sonraki Adım

Kod, komut ve alıcı sonucu birlikte okunduğunda hangi kanıtın eksik olduğu belirlenebilir. Müdahale ve yeniden deneme sırası için e-posta teslim sorunu çözüm rehberini izleyin. Aşağıdaki yazılar ayrı altyapı ve işletim konularını tamamlar:

• VPS
• dedicated sunucu
• IPv6 ile e-posta teslimi
• e-posta altyapısında yedeklilik rehberi
• Postfix, Dovecot ve rspamd kurulumu
• SMTP taşıma güvenliği

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.

• RFC 5321: SMTP
• RFC 3463: Enhanced Status Codes
• RFC 3464: Delivery Status Notifications
• IANA: SMTP Enhanced Status Codes
• RFC 4954: SMTP AUTH
• RFC 3207: STARTTLS
• RFC 8689: REQUIRETLS
• RFC 9989: DMARC
• Postfix: Configuration Parameters