Bir E-Posta Geçiş Projesinin Anatomisi

Aşağıdaki senaryo, orta ölçekli şirketlerdeki e-posta geçiş projelerinin birleştirilmiş bir anlatımıdır. Belirli bir firmayı temsil etmez.

Durum

Bir mühendislik firması. Otuz civarında çalışan.

Mevcut durum:

• E-posta, web sitesinin bulunduğu hosting paketinde
• Kutu başına alan sınırlı, çoğu dolu
• Bazı çalışanlar POP kullanıyor, postalar bilgisayarlarında
• Kimlik doğrulama kayıtları yapılandırılmamış
• Takvim paylaşımı yok
• Arşivleme yok

Tetikleyici: Müşterilerden "teklifiniz gelmedi" geri bildirimi ve dolan kutular.

Karar aşaması

Üç seçenek değerlendirildi:

Karar: ayrı kurumsal e-posta hizmeti.

Hazırlık — Hafta 1

Envanter

• Hesaplar ve boyutları çıkarıldı
• Takma adlar listelendi
• Yönlendirmeler kaydedildi
• Grup adresleri ve üyeleri belgelendi

Bulgu 1: Kimsenin hatırlamadığı sekiz takma ad bulundu. Bunlardan biri, hâlâ kullanılan bir müşteri portalının bildirim adresiydi.

Bulgu 2: Üç çalışan POP kullanıyordu; yıllarca birikmiş postaları yalnız kendi bilgisayarlarındaydı.

Bulgu 3: Web sitesi form bildirimleri, muhasebe programı ve bir proje takip sistemi de şirket adına e-posta gönderiyordu. Hiçbiri SPF'te listeli değildi.

DNS yedeği

Tüm kayıtların ekran görüntüsü alındı.

Hafta 2 — Kurulum

• Hesap şirket adına açıldı
• Yönetici bildirim adresi bt@ olarak ayarlandı
• Yedek bildirim adresi farklı bir alan adında tanımlandı
• Erişim iki kişiye verildi
• İki adımlı doğrulama zorunlu hâle getirildi
• Hesaplar, takma adlar ve gruplar oluşturuldu
• Kotalar profil bazlı ayarlandı

Hafta 3-4 — Arşiv aktarımı

• Sağlayıcının taşıma aracıyla toplu aktarım başlatıldı
• POP kullanan üç çalışanın yerel postaları önce sunucuya yüklendi
• Aktarım gece saatlerinde çalıştırıldı
• İki hesapta hata alındı, elle aktarıldı

Kritik karar: Aktarım, DNS değişikliğinden önce başlatıldı. Geçiş anında arşivin çoğu yeni taraftaydı.

Hafta 5 — Geçiş

Öncesinde

• TTL düşürüldü
• Kullanıcılar bilgilendirildi
• Cihaz kurulum kılavuzu hazırlandı
• Geçiş cuma akşamına planlandı

Geçiş

• MX kaydı değiştirildi
• Eski MX kayıtları silindi
• SPF yeniden yazıldı: yeni sağlayıcı + form sistemi + muhasebe + proje takip
• DKIM etkinleştirildi ve kaydı eklendi
• DMARC izleme politikasıyla eklendi

Hemen sonrasında

• Beş farklı sağlayıcıya test gönderildi
• Hepsinde gelen kutusuna düştüğü doğrulandı
• Eski sistem açık bırakıldı

Yaşanan sorunlar

İkinci satır, en öğretici sorun oldu: sistemin hangi adresten gönderdiğini varsaymak yerine test etmek gerekiyordu.

İlk ay bulguları

• DMARC raporları incelendi; iki bilinmeyen kaynak tespit edildi
• Biri eski bir pazarlama aracıydı, kaldırıldı
• Diğeri bir muhasebe entegrasyonuydu, SPF'e eklendi
• Raporlar temizlendikten sonra DMARC politikası kademeli sıkılaştırıldı

Kapanış — Hafta 9

• Eski sisteme posta düşmediği doğrulandı
• Son aktarım tamamlandı
• Bağımsız bir arşiv kopyası alındı ve şirket depolamasında saklandı
• Hosting paketindeki e-posta hizmeti kapatıldı
• Hosting paketi küçültüldü (disk ihtiyacı azaldı)

Sonuç

• Teslim sorunları ortadan kalktı
• Kutu alanı sorunu bitti
• Takvim ve kişi paylaşımı devreye girdi
• POP kullanımı sona erdi, tüm postalar sunucuda
• İki adımlı doğrulama tüm hesaplarda aktif
• Site kesintisi artık e-postayı etkilemiyor
• Arşivleme politikası tanımlandı
• Toplam proje süresi: yaklaşık iki ay

Çıkarılan dersler

1. Envanter, unutulmuş adresleri ortaya çıkarır. Sekiz takma addan biri aktif kullanımdaydı.
2. Posta gönderen tüm sistemler listelenmelidir. Üç ayrı sistem şirket adına gönderim yapıyordu.
3. Sistemin hangi adresten gönderdiği test edilmelidir, varsayılmamalıdır.
4. Arşiv aktarımı DNS değişikliğinden önce başlamalıdır.
5. POP kullanıcılarının yerel postaları önce sunucuya alınmalıdır.
6. Geçiş sonrası eski sistem kontrol edilmelidir; oraya düşen postalar vardır.
7. DMARC izleme politikası, bilinmeyen gönderim kaynaklarını ortaya çıkarır.
8. Yeni spam filtresi, tanıdık göndericileri engelleyebilir; ilk günler izlenmelidir.
9. Bağımsız arşiv kopyası alınmadan eski hizmet kapatılmamalıdır.