SPF, DKIM ve DMARC, bir e-postanın gerçekten sizin alan adınızdan gönderilip gönderilmediğini alıcı sunucunun kontrol etmesini sağlayan üç kayıttır. E-posta protokolü onlarca yıl önce tasarlandığında gönderen adresini doğrulayan bir mekanizma içermiyordu; tıpkı zarfın üzerine istediğiniz gönderen adresini yazabilmeniz gibi. Dolandırıcılar da bundan yararlanır: müşterinize ya da muhasebenize sizin alan adınızla "banka hesabımız değişti" maili atar. Bu yazıda üç kaydın ne işe yaradığını, hangi sırayla kurulacağını ve yaygın hataları anlatıyoruz.
Üç kayıt, üç ayrı soru
| Kayıt | Cevapladığı soru | Sade anlatım |
|---|---|---|
| SPF | Bu sunucu, bu alan adı adına mail göndermeye yetkili mi? | Alan adınız adına mail gönderebilecek sunucuların listesi |
| DKIM | Bu mail yolda değiştirildi mi, gerçekten o alan adından mı çıktı? | Giden her maile eklenen dijital imza; alıcı, DNS'teki açık anahtarla doğrular |
| DMARC | SPF ve DKIM başarısız olursa ne yapılsın, bana rapor gönderilsin mi? | Alan adı sahibinin alıcılara verdiği talimat ve geri bildirim kanalı |
SPF ve DKIM tek başına yeterli değildir; çünkü ikisi de alıcının gördüğü "Kimden" adresini doğrudan korumaz. DMARC, bu iki kontrolün sonucunu görünen gönderen adresiyle eşleştirir (buna hizalama denir) ve başarısız maillerin ne olacağını belirler.
Neden artık bir tercih değil?
Büyük e-posta sağlayıcıları bu kayıtları giderek zorunlu hâle getiriyor. Google ve Yahoo, Şubat 2024'ten itibaren gönderen kurallarını sıkılaştırdı: Google'ın gönderen yönergelerine göre tüm göndericilerden en az SPF veya DKIM, Gmail adreslerine günde yüksek hacimde mail gönderenlerden ise SPF, DKIM ve DMARC'ın birlikte kurulu olması bekleniyor. Bu kayıtları eksik olan firmaların teklif ve fatura mailleri giderek daha sık spam klasörüne düşüyor.
Güvenlik tarafı ise daha da önemli. Sahte fatura ve IBAN değişikliği dolandırıcılığı, doğrudan maddi kayba yol açar. Firmanızın adıyla gönderilen bir oltalama maili müşterinizin kişisel verilerinin ele geçirilmesine neden olabilir; bu da hem itibar hem KVKK açısından sorumluluk tartışması doğurur.
Adım adım kurulum
- Tüm gönderim kaynaklarını listeleyin. Kurumsal e-posta sunucusu, web sitesinin form bildirimleri, e-fatura sistemi, bülten aracı, CRM, destek yazılımı. Unutulan her kaynak, DMARC sıkılaştığında maillerinin reddedilmesi demektir.
- SPF kaydını tek ve düzgün yazın. Bir alan adında yalnız bir SPF kaydı olmalı. Tüm yetkili kaynaklar bu tek kayda eklenir. SPF'in DNS sorgu sınırı olduğunu unutmayın; çok fazla hizmet eklendiğinde kayıt geçersizleşebilir.
- Her gönderim kaynağında DKIM'i açın. Her hizmet kendi DKIM anahtarını verir; DNS'e eklenir. Anahtarlar yeterli uzunlukta (güncel öneri en az 2048 bit) olmalı.
- DMARC'ı izleme modunda başlatın. İlk aşamada politika "none" olur; hiçbir mail engellenmez, yalnız rapor toplanır. Raporlar, alan adınız adına kimlerin mail gönderdiğini gösterir.
- Raporları okuyup eksik kaynakları düzeltin. Unutulmuş bir bülten aracı ya da yazıcı genellikle bu aşamada ortaya çıkar.
- Kademeli sıkılaştırın. Önce "quarantine" (spam klasörüne gönder), sorunsuz birkaç haftadan sonra "reject" (reddet). Amaç, sahte maillerin alıcıya hiç ulaşmamasıdır.
Sık yapılan hatalar
- İki ayrı SPF kaydı. İkisi birden geçersiz sayılır.
- SPF'in sonunu çok gevşek bırakmak. Her sunucuya izin veren bir ifade, kaydı anlamsız kılar.
- DMARC'ı "none"da unutmak. İzleme modu koruma sağlamaz; yalnız rapor verir. Birçok alan adı yıllarca bu aşamada kalır.
- Kullanılmayan alan adlarını unutmak. Mail göndermeyen yan alan adlarınız da taklit edilebilir. Onlar için "hiçbir sunucu yetkili değil" diyen SPF ve "reject" politikalı DMARC yazılmalıdır.
- Web sitesi formlarını atlamak. Site sunucusundan doğrudan gönderilen form bildirimleri DKIM imzasız kalır ve spam'e düşer.
Kontrol listesi
- Tüm gönderim kaynakları listelendi
- Tek bir SPF kaydı var ve tüm kaynakları kapsıyor
- Her kaynakta DKIM imzası etkin
- DMARC kaydı var ve raporlar düzenli okunuyor
- Politika izleme modundan karantina veya ret aşamasına geçti
- Mail göndermeyen yan alan adları da korunuyor
- Muhasebe ve satış ekibi, IBAN değişikliği maillerini telefonla teyit etmeyi biliyor
Son madde teknik değil ama en az diğerleri kadar önemli: hiçbir kayıt, ele geçirilmiş gerçek bir hesaptan gönderilen maili durduramaz. Hesap güvenliği için parola politikası ve 2FA yazısına bakabilirsiniz.
Globya'da nasıl yapıyoruz
Kurumsal e-posta ve web sitesi kurulumlarında SPF, DKIM ve DMARC kayıtlarını baştan yapılandırıyor; sitenin form bildirimlerini de imzalı gönderiyoruz. Mevcut bir alan adında önce gönderim kaynaklarının envanterini çıkarıp DMARC'ı izleme modunda açıyor, raporları birlikte okuyup kademeli olarak ret aşamasına taşıyoruz. Bu gereklilikler KVKK uyumu yaklaşımımız gereği ek ücrete tabi değildir.
Sık sorulan sorular
Bu kayıtları eklersek maillerimiz hiç spam'e düşmez mi?
Garanti etmez ama teslim edilebilirliği belirgin biçimde iyileştirir. İçerik, gönderim hacmi ve alıcıların tepkisi de spam kararını etkiler.
DMARC'ı doğrudan "reject" ile başlatabilir miyiz?
Önermiyoruz. Unutulmuş bir gönderim kaynağı varsa (ör. e-fatura bildirimleri) o mailler de reddedilir. Önce izleme modunda raporları görmek güvenli yoldur.
DMARC raporları nasıl okunur?
Raporlar makine için yazılmış XML dosyalarıdır. Bir raporlama aracı ya da bu işi yapan bir ekip, raporları okunur özetlere çevirir; asıl bakılacak şey tanımadığınız gönderim kaynaklarıdır.
Alan adımızın durumunu kontrol edebilir misiniz?
Evet. 0850 432 55 13 ya da iletişim sayfası üzerinden ulaşın; alan adınızın SPF, DKIM ve DMARC durumunu inceleyip önerilerimizi yazılı iletelim.
Globya asistanı 7/24 çevrimiçi; sorunuzu hemen yanıtlar, gerekirse ekibe iletir.