Kısa yanıt
Kurumsal e-posta spam’e gidiyorsa önce mesajı hangi sistemin gönderdiğini ve alıcıda ne olduğunu belirleyin. SPF yetkisini, DKIM imzasını ve DMARC alan adı uyumunu gerçek test mesajında inceleyin. Ardından gönderim kayıtları, geçersiz adresler ve içerik davranışına bakın. Kimlik doğrulamanın başarılı olması gelen kutusuna teslim garantisi değildir.
Dört adımda uygulama rotası
BAŞLANGIÇ → SONUÇ- 01Kaynağı bul
Webmail, form ve otomasyonu ayır.
- 02Sonucu sınıflandır
Ret ile spam klasörünü farklı incele.
- 03Doğrulamayı oku
Gerçek mesajın teknik sonucuna bak.
- 04Kontrollü değiştir
Tek düzeltmeden sonra ayrı testler yap.
Önce sorunun hangi gönderimde olduğunu bulun
Şirketinizin e-postaları spam klasörüne gidiyorsa hemen metni değiştirerek başlamayın. Webmail’den yazılan mesaj, web sitesinin iletişim formu ve fatura bildirimi farklı sistemlerden gönderiliyor olabilir. Aynı görünen şirket adresinin kullanılması, hepsinin aynı teknik yapılandırmayı kullandığını göstermez.
Önce hangi gönderenin, hangi alıcıda ve hangi tarihte sorun yaşadığını kaydedin. Mesaj reddedilip geri mi döndü, yoksa teslim edilip spam klasöründe mi göründü? İki durum farklı inceleme gerektirir. “Mail gitmiyor” yerine bir test mesajının kaynağını ve sonucunu belirtmek, destek ekibinin doğru kayda ulaşmasını kolaylaştırır.
SPF ve DKIM farklı kontroller yapar
SPF, gönderici sunucunun belirli bir alan adı adına gönderim yapmaya yetkili olup olmadığını kontrol etmeye yardımcı olur. Bu kontrol doğrudan ekranda görülen From adresinin bütün anlamını doğrulamaz; SMTP zarfındaki gönderici gibi teknik kimliklerle ilgilidir. DKIM ise mesajı bir imzalayan alan adıyla ilişkilendiren kriptografik imza kullanır.
Bu iki mekanizmayı tek bir “DNS yeşil” sonucuna indirgemeyin. DNS kaydı bulunmasıyla gerçek test mesajının o kaydı kullanarak doğrulanması farklıdır. Alıcının eklediği doğrulama sonuçlarını inceleyin; teknik ayrıntıya aşina değilseniz mesaj başlıklarını kişisel içerikten arındırarak hizmet sağlayıcısına iletin. Her gönderen sistem için kendi testini yapın.
Örnek: webmail başarılı, fatura bildirimi sorunlu
Çalışanın webmail üzerinden yazdığı mesaj karşıya ulaşıyor ama iş yazılımının aynı görünen adresten gönderdiği bildirim spam’e düşüyor olsun. İki mesajın aynı sunucudan çıktığını varsaymayın. Uygulama başka bir gönderim hizmetini kullanıyor olabilir. Gerçek test mesajlarının teknik başlıkları ve gönderim kayıtları karşılaştırılmalıdır.
SPF veya DKIM sonucunda görülen alan adı ile görünür gönderen arasındaki ilişki önem taşır. Bir hizmet kendi alan adıyla başarılı imza atmış olabilir; bu, şirketinizin From alan adı için gereken uyumun da sağlandığını kendiliğinden göstermez. Destek ekibine hangi gönderim sisteminin hangi adresi kullandığını açıkça iletin.
Değişikliği yalnızca DNS panelindeki yeşil onaya bakarak tamamlamayın. Yeni test mesajının alıcı tarafında hangi sonucu verdiğini inceleyin. Eski bir mesajın başlığı, sonradan düzeltilen kaydın etkisini göstermez. Her testin gönderim zamanı ve kullanılan sistem kayıtta bulunsun.
Bu senaryo açıklama amacıyla hazırlanmıştır; gerçek müşteri sonucu veya ürün testi değildir.
DMARC için alan adı uyumuna da bakın
DMARC değerlendirmesinde görünen From alan adı ile başarılı SPF veya DKIM kimliği arasındaki uyum önem taşır. Dolayısıyla bir mesajda başka bir hizmetin alan adıyla DKIM başarılı görünmesi, şirketinizin From adresi için DMARC’ın da başarılı olacağını tek başına göstermez. Alan adı uyumu ve alıcının doğrulama sonucu birlikte ele alınmalıdır.
Aynı ad altında birbiriyle çelişen birden fazla SPF kaydı yayımlamak yerine yetkili göndericileri tek bir geçerli politika içinde planlayın. Değerleri başka bir şirketten kopyalamayın. Mevcut göndericileri incelemeden sıkı bir DMARC politikası uygulamak, kendi meşru iletilerinizi de etkileyebilir. Değişikliği kontrollü test ve izlemeyle yönetin.
Doğrulama başarılıysa içerik ve gönderim davranışını inceleyin
SPF veya DKIM’in başarılı olması gelen kutusu garantisi değildir. Alıcı sistemin değerlendirmesinde gönderim itibarı, şikâyetler, adres kalitesi ve mesajın özellikleri gibi başka unsurlar bulunabilir. Geçersiz adrese aynı mesajı sürekli göndermek veya beklenmedik hacim artışıyla devam etmek yerine geri dönüşleri ve gönderim kayıtlarını inceleyin.
Bize ait TekPosta’nın SPF, DKIM ve DMARC yapılandırma rehberini kendi alan adınızdaki kurulumla karşılaştırmak için kullanabilirsiniz. Tek bir örnek mesajdan bütün alıcılara teslim sonucu çıkarmayın. DNS ayarlarını, istemci bağlantısını ve mesajın hangi hizmetten çıktığını aynı kayıt üzerinde kontrol edin.
Teslim sorununun türünü sınıflandırın
| Gözlem | Gerekli kanıt | İlk inceleme |
|---|---|---|
| Mesaj geri döndü | Geri dönüş kodu ve ilgili gönderim | Adres, ret nedeni ve hizmet kaydı |
| Spam klasörüne geldi | Gerçek ileti başlığı ve doğrulama sonucu | Gönderen sistem, uyum ve itibar |
| Sadece bir uygulamada sorun var | Uygulamanın SMTP veya API ayarı | Farklı gönderim yolu |
| Geçişten sonra başladı | Eski ve yeni kayıt/istemci envanteri | Güncellenmemiş bağımlılık |
Bu sınıflandırma alıcının kararını kontrol etmez; destek incelemesini doğru yöne taşır. Kesin sonuç alınmadan bütün DNS kayıtlarını değiştirmek veya sürekli yeni test göndererek hacmi artırmak teşhisi karmaşıklaştırabilir.
Destek kaydına işe yarayan kanıtları ekleyin
Gönderim zamanı, gönderen sistem, hedef hizmet, varsa geri dönüş kodu ve teknik mesaj kimliği inceleme için yararlı olabilir. Parola ve uygulama şifrelerini göndermeyin; müşteri yazışmasının tamamını herkese açık bir alana yapıştırmayın. Gereken teknik başlıkları sağlayıcının güvenli destek kanalında paylaşın.
Düzeltme sonrasında webmail, web formu ve otomatik bildirimden ayrı testler yapın. Sadece kendi alan adınızdaki bir kutuya göndererek dış teslimatı doğrulamış sayılmayın. Sorun yeni sağlayıcıya geçiş sırasında başladıysa e-posta geçiş planındaki eski gönderim ayarlarını da kontrol edin; bütün sistemlerin aynı gün güncellendiği varsayımı sıkça yanıltır.
Düzeltmeyi güvenli ve izlenebilir yapmak
DNS politikasını değiştirmeden önce alan adınız adına mesaj gönderen bütün meşru sistemleri listeleyin. Eski uygulama veya pazarlama aracı unutulursa sıkı politika bu mesajları da etkileyebilir. Her kaydın sorumlusu, değişiklik nedeni ve kontrol saati belli olsun. İnternetteki örnek değeri alan adınıza uygunluğunu doğrulamadan kullanmayın.
Bir düzeltme başarılıysa hangi problemi çözdüğünü yazın. Böylece sonraki olayda aynı çözümü körlemesine uygulamak yerine kaynak ve belirtiyi karşılaştırabilirsiniz. Uygulama şifresi veya özel anahtar teknik destek kaydına açık olarak eklenmemelidir.
0 / 4 adım kontrol edildi · Bu seçimler yalnızca açık sayfada tutulur.
Sık sorulan sorular
SPF başarılıysa DMARC da başarılı olur mu?
Başarılı doğrulama yanında görünür gönderen alan adıyla gereken uyumun da sağlanması gerekir. Gerçek mesajın sonuçlarını birlikte inceleyin; DNS kaydının bulunması tek başına yeterli değildir.
DKIM imzası spam sorununu kesin çözer mi?
Hayır. İmza kimlik doğrulama mekanizmasıdır. Alıcının değerlendirmesinde başka unsurlar da bulunabilir; bir test mesajının gelen kutusuna gitmesi bütün gelecek teslimler için garanti vermez.
Destek ekibine hangi bilgileri göndermeliyim?
Gönderim zamanı, kaynak sistem, hedef hizmet ve varsa geri dönüş kodunu iletin. Gerekli teknik başlıkları güvenli kanalda paylaşın; parola, özel anahtar veya gereksiz müşteri içeriğini eklemeyin.
Yöntem ve kaynak notu
Örnek senaryolar ve karar tabloları, konuyu açıklamak için hazırlanmış çalışma önerileridir. Ölçülmüş müşteri sonucu veya bağımsız ürün testi olarak sunulmaz. Platform ve ürün koşulları değişebileceğinden uygulama öncesinde ilgili resmi belgeyi ve kendi hizmet kapsamınızı kontrol edin.
Resmi belgeler ve ek okuma
- IETF: SPF yetkilendirme mekanizması (RFC 7208)
- IETF: DKIM imzaları (RFC 6376)
- IETF: DMARC değerlendirmesi (RFC 9989)