Kurumsal E-posta Teslimat ve Spam Sorunları

E-posta gitmiyor mu, reddediliyor mu, spama mı düşüyor?

Kurumsal e-postanın “Gönderilenler” klasöründe görünmesi, alıcının gelen kutusuna ulaştığını göstermez. İstemcinin SMTP sunucusuna bağlanması, sunucunun iletinin sorumluluğunu alması ve alıcı sistemin teslim kararı farklı aşamalardır. Önce sorunun hangi aşamada olduğunu belirleyin.

Bu rehber, kendi alan adıyla e-posta gönderen işletmeler ve müşteri sitelerinin form/sipariş iletilerini yöneten ajanslar içindir. Hesap telefonda veya bilgisayarda hiç açılmıyorsa önce IMAP ve SMTP kurulum rehberini kullanın.

Tek bir alıcıdaki sorunu bütün sisteme genellemeyin. Etkilenen alıcı alan adlarını, aynı anda başarılı olan gönderimi ve son DNS/uygulama değişikliğini not alın.

Alan adınız adına kimlerin e-posta gönderdiğini çıkarın

Çalışanların posta kutuları, web sitesi formu, mağaza, CRM ve bülten aracı farklı sunuculardan gönderim yapabilir. Bir posta kutusunun doğru ayarlanması diğer bütün kaynakların doğrulandığı anlamına gelmez. Her kaynağın sağlayıcısını, görünen gönderen adresini ve kendi SPF/DKIM yönergesini kaydedin.

Gönderim kaynağı: posta kutusu / web formu / mağaza / CRM
Kullanılan sağlayıcı veya SMTP hizmeti:
Görünen From alan adı:
Sağlayıcının verdiği SPF yönergesi:
DKIM seçicisi ve doğrulama durumu:
Son başarılı / başarısız gönderim zamanı:
Bu sistemin teknik sorumlusu:

Şifre veya API anahtarı bu envantere eklenmemelidir. DNS başka bir sağlayıcıda yönetiliyorsa kayıt değişikliklerini o yetkili bölgede yapmanız gerekir; yalnız hosting panelinde kayıt eklemek etkisiz kalabilir. Yetkili DNS’i bulmak için DNS kayıtları rehberini kullanın.

SPF, DKIM ve DMARC sonuçlarını birbirinden ayırın

• SPF: İletinin zarf gönderen alan adı için gönderim yapan sistemin yetkili olup olmadığını değerlendirir. Aynı DNS adı üzerinde birden fazla bağımsız SPF kaydı yayımlamayın; kullandığınız hizmetleri sağlayıcı yönergelerine göre tek politikada düzenleyin.
• DKIM: İletinin imzasını, seçiciye ait DNS anahtarıyla doğrular. Anahtar ve seçici değerini kullandığınız gönderim servisinden alın; başka bir hizmetin örneğini kopyalamayın.
• DMARC: Görünen From alanıyla SPF veya DKIM üzerinden doğrulanan alanın hizalanmasını değerlendirir. SPF ya da DKIM’nin başarılı ve DMARC politikasına uygun hizalı olması gerekir; yalnızca herhangi bir alanda “pass” görmek yeterli değildir.

Gmail’in gönderen yönergeleri kimlik doğrulama yanında DNS/PTR, TLS, spam oranı ve gönderim davranışını da ele alır. Toplu göndericiler için ek koşullar vardır. Bu yüzden doğru SPF ve DKIM, her iletinin gelen kutusuna düşeceği garantisini vermez.

PTR ters DNS kaydını genellikle gönderim IP’sini yöneten sağlayıcı düzenler; alan adınızın normal DNS bölgesine rastgele TXT veya A kaydı eklemek bunun yerini tutmaz. Paylaşımlı bir gönderim altyapısında IP ve itibar incelemesini sağlayıcınızla yürütün.

Alınan iletinin başlıklarını okuyarak doğrulayın

1. Kendi kontrolünüzdeki bir dış posta kutusuna, ilgili gönderim kaynağından kişisel veri içermeyen tek bir test iletisi gönderin. Posta kutusundan gönderilen test ile web formundan gönderilen testin aynı yolu kullandığını varsaymayın.
2. Alınan iletide ham başlıkları veya özgün ileti görünümünü açın. Gmail’de iletinin yanındaki Diğer → Orijinali göster seçeneği kullanılır; Google’ın başlık görüntüleme belgesi adımları açıklar.
3. Alıcı sistemin eklediği Authentication-Results kaydında spf, dkim ve dmarc sonuçlarını bulun. Birden fazla geçit varsa hangi sunucunun değerlendirdiğini de kontrol edin.
4. From alanını, SPF için kullanılan zarf gönderen alanıyla ve DKIM imzasındaki d= alanıyla karşılaştırın. Tam başlıkta DKIM seçicisi s= alanında bulunabilir.
5. Sonucu, kullanılan kaynak ve test zamanı ile kaydedin. DNS değiştiyse önbellek süresini dikkate alarak yeni bir iletiyle yeniden sınayın; eski iletinin başlıkları sonradan değişmez.

Örnek başlık özeti; gerçek müşteri verisi değildir:

Görünen From: [email protected]
SPF: pass, smtp.mailfrom=sender.example.net
DKIM: pass, header.d=sender.example.net
DMARC: fail, header.from=example.com

Bu örnekte gönderim sistemi kendi alanı için doğrulanıyor, ancak görünen example.com alanıyla hizalanmıyor. Çözüm, kullanılan servisin size ait alan adı için desteklediği DKIM veya uygun zarf gönderen yapılandırmasını tamamlamaktır. Bütün kayıtlara gelişigüzel “izin ver” eklemek sorunu doğru biçimde çözmez.

DMARC politikasını gerçek gönderim kaynaklarıyla devreye alın

Google’ın DMARC kurulum belgesi önce SPF/DKIM hazırlığını ve kontrollü bir devreye alma sürecini önerir. Gönderim kaynaklarınızı doğrulamadan doğrudan p=reject uygulamak, işletmenizin meşru iletilerinin de reddedilmesine neden olabilir.

1. Posta kutusu, form, CRM ve diğer meşru kaynakları envanterinizle karşılaştırın; her kaynağın doğrulama ve hizalamasını test edin.
2. Alanınız için mevcut DMARC kaydı olup olmadığını kontrol edin. Var olan politikayı etkisini anlamadan değiştirmeyin.
3. Yeni bir dağıtımda izleme politikası ve raporlamayı sorumlu ekiple planlayın. p=none, DMARC nedeniyle ret/karantina istememektir; spam filtrelerini kapatmaz ve teslim garantisi vermez.
4. Raporların kim tarafından izleneceğini belirleyin. Rapor adresini gelişigüzel kişisel bir posta kutusu yapmayın; hacim, erişim ve saklama düzenini düşünün.
5. Meşru kaynakların sonuçlarını inceledikten sonra daha sıkı politikaya geçişi planlayın; form ve sipariş e-postalarını tekrar sınayın.

Bu rehber bütün alan adları için kopyalanacak bir SPF veya DMARC değeri üretmez. Kayıt içeriği kullandığınız gerçek hizmetler ve mevcut politikayla belirlenmelidir.

SMTP hata kodunu açıklamasıyla birlikte yorumlayın

SMTP standardında 4xx yanıtları geçici, 5xx yanıtları kalıcı başarısızlık sınıfını gösterir. Ancak yalnız ilk rakam çözümü söylemez; tam kodu, açıklamayı ve hangi sunucunun yanıt verdiğini birlikte inceleyin. “550” gibi bir kod farklı açıklamalarla farklı sorunları belirtebilir.

Kimlik doğrulama başarılıysa izinli gönderim, adres kalitesi, içerik ve alıcı davranışı gibi etkenleri inceleyin. Pazarlama gönderisini çalışan posta kutularından yürütmek yerine bu iş için uygun hizmet ve gönderim izinlerini değerlendirin.

Web sitesi formu ve sipariş e-postasını ayrı sınayın

Formun başarı mesajı, iletinin alıcıya ulaştığını kanıtlamaz. Form uygulamasının hangi SMTP hizmetini kullandığını, uygulama günlüğündeki sonucu ve alınan iletinin başlıklarını kontrol edin. SMTP hesabı değiştiyse eski bir eklenti ayarının veya ortam değişkeninin kullanılmadığını doğrulayın.

Görünen gönderen için yetkili olduğunuz alan adını kullanın. Ziyaretçinin yazdığı adresi doğrudan From yapmak yerine, uygun uygulamada yanıtların ona gitmesi için Reply-To kullanılabilir. Böylece ziyaretçinin alan adı adına yetkisiz gönderim yapmaya çalışmazsınız. Alanlara gelen verinin uygulama tarafından doğrulanması da gerekir.

Mağazada test siparişi yapacaksanız ödeme sağlayıcısının test ortamını ve size ait test adreslerini kullanın. Sipariş onayı, yönetici bildirimi ve parola sıfırlama farklı şablonlar veya yollar kullanabilir; iş açısından önemli olan akışları ayrı kontrol edin.

Destek ekibine teşhis edilebilir bir özet gönderin

Etkilenen hizmet / alan adı:
Gönderim kaynağı: posta kutusu / web formu / mağaza / CRM
Gönderim zamanı ve saat dilimi:
Etkilenen alıcı sağlayıcısı:
Tam SMTP hata kodu ve açıklaması:
SPF / DKIM / DMARC sonucu ve ilgili alan adları:
Varsa Message-ID (yetkili destek kanalında):
Son DNS veya uygulama değişikliği:
Başarılı karşılaştırma testi ve sonucu:

Ham ileti başlıkları e-posta adresi ve IP bilgileri içerebilir. Herkese açık paylaşımda kişisel bilgileri gizleyin; yetkili destek kanalına yalnız inceleme için gerekli veriyi iletin. Parola, oturum anahtarı veya tam müşteri iletisini bu özete eklemeyin.

Mevcut hesabınız için müşteri portalından destek talebi açın. Yeni bir altyapı veya taşıma planlıyorsanız kurumsal hosting kapsamını inceleyebilir ve e-posta ihtiyacınız için görüşme isteyebilirsiniz. Posta kutusu kapasitesi, gönderim sınırları, arşiv, taşıma ve ek e-posta hizmetleri teklif kapsamında değerlendirilir.