Kurumsal e-postanızı Microsoft 365 veya Google Workspace üzerinde tutuyorsanız, "zaten profesyonel bir servis kullanıyorum, smarthost'a ne gerek var" diye düşünebilirsiniz. Bu doğru bir soru ve cevabı senaryoya bağlı: bu platformlar kullanıcı yazışmaları için mükemmeldir ama uygulama kaynaklı gönderimler için tasarlanmamışlardır.
Bu rehber, hangi durumda ek bir gönderim altyapısına ihtiyaç duyacağınızı ve entegrasyonun nasıl kurulacağını anlatıyor.
Ne Zaman Ek Bir Gönderim Yolu Gerekir?
Kurumsal e-posta platformları, insan kullanıcıların yazışması için optimize edilmiştir. Şu durumlarda sınırlarına çarparsınız:
- Gönderim limitleri: Bu platformlar günlük ve saatlik gönderim limitleri uygular. Bülten, toplu bildirim veya yüksek hacimli işlemsel e-posta gönderiyorsanız bu limitlere çarparsınız — ve limit aşımı hesabınızın geçici olarak askıya alınmasına yol açabilir.
- Uygulama gönderimleri: Web sitenizin sipariş onayı, şifre sıfırlama ve form bildirimlerini kurumsal e-posta hesabınız üzerinden göndermek, o hesabın kimlik bilgilerini uygulamanıza gömmek anlamına gelir. Bu bir güvenlik riskidir.
- Cihaz ve otomasyon gönderimleri: Yazıcılar, izleme sistemleri ve yedekleme raporları modern kimlik doğrulama yöntemlerini desteklemeyebilir. Bu platformlar temel kimlik doğrulamayı giderek kısıtlıyor.
- İtibar ayrıştırma: Pazarlama gönderiminiz itibar sorunu yaşarsa, aynı altyapıdan giden kritik yazışmalarınız da etkilenir. Ayrı bir gönderim yolu bu riski bölümlere ayırır.
Doğru Mimari: Trafiği Ayırmak
Çözüm, kurumsal e-posta platformunu bırakmak değil, gönderim trafiğini türüne göre ayırmaktır:
| Trafik türü | Uygun yol | Neden |
|---|---|---|
| Kullanıcı yazışmaları | Kurumsal e-posta platformu | Tam da bunun için tasarlanmış |
| İşlemsel e-postalar | Smarthost / gönderim altyapısı | Yüksek hacim, kimlik bilgisi izolasyonu |
| Pazarlama / bülten | Ayrı alt alan adı + gönderim altyapısı | İtibar riskini ayırma |
| Cihaz / otomasyon | Smarthost | Basit kimlik doğrulama desteği |
Bu ayrım, tek bir altyapıya yığılmanın yarattığı riskleri dağıtır. Kritik nokta şudur: bir kampanya itibarınızı zedelese bile, çalışanlarınızın günlük yazışmaları ve müşterilerinizin şifre sıfırlama e-postaları etkilenmez.
Gelen ve Giden Ayrımı
Entegrasyonun en çok karıştırılan noktası budur ve netleştirmek gerekir:
- Gelen e-posta: MX kayıtları tarafından yönetilir. Kurumsal e-posta platformunuzu kullanıyorsanız MX kayıtları ona işaret eder ve bu değişmez.
- Giden e-posta: Gönderen sistemin yapılandırmasıyla belirlenir. Bir uygulamayı smarthost üzerinden göndermeye ayarlamak, gelen e-posta akışınızı hiçbir şekilde etkilemez.
Bu ayrımı bilmemek, geçiş sırasında MX kayıtlarına dokunup gelen e-postaları kesme hatasına yol açar. Kural nettir: giden gönderim yapılandırması için MX kaydına asla dokunulmaz.
Kurulum Adımları
- Hangi sistemin nereden göndereceğine karar verin. Yukarıdaki tabloyu kendi sistemlerinizle doldurun.
- SPF kaydını genişletin. Hem kurumsal e-posta platformunuz hem smarthost sağlayıcınız tek bir SPF kaydında listelenmeli. İki ayrı SPF kaydı oluşturmak doğrulamayı tamamen bozar.
- Her gönderen için DKIM tanımlayın. DKIM birden fazla anahtarı destekler; her gönderim yolu kendi anahtarıyla imzalar. Kurumsal platformun DKIM'i zaten kuruluysa ona dokunmayın, smarthost için ikinci bir anahtar ekleyin.
- Alt alan adı ayrımı yapın. Pazarlama gönderimleri için ayrı bir alt alan adı tanımlayın ve o alt alan adı için ayrı SPF/DKIM kurun.
- Uygulamaları yapılandırın. Her uygulamanın SMTP ayarlarını smarthost bilgileriyle güncelleyin. Gönderen adresinin kendi alan adınızda olduğundan emin olun.
- DMARC ile doğrulayın. Politikayı "none" ile başlatıp raporları okuyun. Raporlar, tüm gönderim yollarının doğru yapılandırıldığını kanıtlar — ve atladığınız bir sistemi ortaya çıkarır.
Entegrasyonda Sık Yapılan Üç Hata
- İkinci bir SPF kaydı oluşturmak: Yeni gönderen eklerken ayrı kayıt açmak, doğrulamayı tamamen geçersiz kılar. Mevcut kaydı genişletin.
- MX kayıtlarına dokunmak: Giden gönderim yapılandırması gelen akışı ilgilendirmez. MX'e dokunmak e-posta almanızı keser.
- Kurumsal hesap kimlik bilgilerini uygulamaya gömmek: Bir çalışanın e-posta hesabının parolasını web uygulamanızın yapılandırma dosyasına yazmak, o hesabın tamamını riske atar. Uygulama gönderimleri için ayrı kimlik bilgileri kullanın.
Sonuç
Microsoft 365 veya Google Workspace kullanmak ile ek bir gönderim altyapısı kullanmak birbirinin alternatifi değildir — farklı işler için farklı araçlardır. Kullanıcı yazışmaları kurumsal platformda, uygulama ve toplu gönderimler smarthost üzerinden gitmelidir. Bu ayrım hem gönderim limitleri sorununu çözer hem itibar riskini bölümlere ayırır hem de kurumsal hesap kimlik bilgilerinizi uygulamalardan uzak tutar. Entegrasyonda tek kritik kural: SPF tek kayıt, MX'e dokunma.
Sıkça Sorulan Sorular (SSS)
Microsoft 365 kullanıyorum, gerçekten smarthost'a ihtiyacım var mı?
Yalnızca kullanıcı yazışması yapıyorsanız hayır. Web uygulamanız e-posta gönderiyorsa, bülten yolluyorsanız veya cihazlarınız rapor gönderiyorsa evet — bu trafiği kurumsal hesap üzerinden yürütmek hem limit hem güvenlik sorunu üretir.
Smarthost kurunca MX kaydımı değiştirmeli miyim?
Hayır. MX gelen e-postayı, smarthost gideni yönetir. MX kayıtlarınız kurumsal e-posta platformunuza işaret etmeye devam etmelidir. Bu ayrım karıştırıldığında gelen e-posta akışı kesilir.
İki gönderim yolum var, SPF nasıl olmalı?
Tek bir SPF kaydı içinde her ikisi de listelenmelidir. Aynı alan adı için ikinci bir SPF kaydı eklemek geçersiz bir yapılandırmadır ve doğrulamanın tamamen başarısız olmasına yol açar.
Pazarlama için ayrı alt alan adı şart mı?
Şart değil ama güçlü biçimde önerilir. Pazarlama gönderimleri şikayet üretmeye en yatkın trafiktir; ayrı bir alt alan adı, olası bir itibar sorununun kritik işlemsel e-postalarınızı etkilemesini önler.
