SPF, DKIM ve DMARC, alan adınızla gönderilen sahte e-postaların ayırt edilmesine yardım eder. Her birinin ne yaptığını ve DMARC'ta p=none'dan reject'e kademeli geçişi öğrenin.
Müşterinize sizin alan adınızla, "banka hesabımız değişti" diyen bir e-posta gitse, bunun sizden gelmediğini anlayabilir mi? E-postanın temel yapısı, gönderen adresinin doğruluğunu kendiliğinden denetlemez; kötü niyetli biri sizin adresinizi "Kimden" alanına yazarak mesaj gönderebilir. SPF, DKIM ve DMARC, alıcı tarafın bu tür sahte mesajları ayırt etmesine yardım eden ve alan adınızın DNS kayıtlarında tanımlanan üç tamamlayıcı mekanizmadır.
Neden gerekli?
Bu kayıtlar iki ayrı sorunu ele alır. Birincisi sahtecilik: dolandırıcıların sizin alan adınızı kullanarak müşterilerinize, tedarikçilerinize ya da çalışanlarınıza ödeme talebi veya parola sayfası bağlantısı göndermesi. İkincisi teslim edilebilirlik: kendi gönderdiğiniz faturaların, tekliflerin ve bildirimlerin alıcının gereksiz klasörüne düşmesi. Büyük e-posta sağlayıcıları, gönderen alan adlarının kimliğini doğrulamasını giderek daha fazla bekliyor; özellikle yüksek hacimde gönderim yapanlar için bu kayıtlar artık temel bir gereklilik hâline geldi.
SPF: Kim adınıza gönderebilir?
SPF (Sender Policy Framework), alan adınız adına e-posta göndermeye yetkili sunucuların ve hizmetlerin listesidir. Alan adınızın DNS'ine "v=spf1" ile başlayan bir metin (TXT) kaydı olarak eklenir. Alıcı sunucu, gelen mesajı gönderen sunucunun bu listede olup olmadığına bakar.
SPF'te sık yapılan hatalar şunlardır:
- Unutulan gönderim kaynakları: Yalnızca ana e-posta hizmetinizi eklemek yetmez. Fatura programı, toplu e-posta aracı, müşteri yönetim uygulaması, web sitesindeki iletişim formu ve tarama yapıp e-posta gönderen yazıcılar da sizin adınıza gönderim yapıyor olabilir.
- Birden fazla SPF kaydı: Bir alan adında yalnızca bir SPF kaydı olmalıdır. Yeni bir hizmet eklenirken ikinci bir kayıt açmak, SPF denetiminin hata vermesine yol açar; yeni kaynak mevcut kayda eklenmelidir.
- DNS sorgu sınırı: SPF denetimi sırasında en fazla 10 DNS sorgusu yapılabilir. Çok sayıda hizmet "include" ile eklendiğinde bu sınır aşılabilir ve kayıt geçersiz sayılabilir.
Kaydın sonundaki ifade, listede olmayan kaynaklara ne yapılacağını söyler: "~all" şüpheli olarak işaretlenmesini, "-all" reddedilmesini önerir. SPF'in bir sınırı da vardır: alıcının ekranda gördüğü "Kimden" adresini değil, mesajın arka plandaki dönüş adresini denetler. Ayrıca bir mesaj başka bir adrese otomatik olarak yönlendirildiğinde SPF denetimi çoğu zaman başarısız olur. Bu boşlukları DKIM ve DMARC kapatır.
DKIM: Mesaj gerçekten sizden mi ve değişmeden mi geldi?
DKIM (DomainKeys Identified Mail), gönderen sunucunun her mesaja dijital bir imza eklemesidir. İmza gizli bir anahtarla oluşturulur; bu anahtarın eşi olan ortak anahtar ise alan adınızın DNS'inde yayımlanır. Alıcı sunucu bu ortak anahtarla imzayı doğrular ve mesajın gerçekten alan adınız adına gönderildiğini, yolda değiştirilmediğini anlar.
DKIM'in avantajı, imzanın mesajla birlikte taşınmasıdır; bu yüzden yönlendirilen mesajlarda da çoğu zaman geçerliliğini korur. Her gönderim hizmeti için DKIM ayrı ayrı açılmalıdır: ana e-posta hizmetinizde DKIM'in açık olması, fatura programınızın gönderdiği mesajları imzalamaz. Anahtar uzunluğu için yaygın öneri 2048 bittir; anahtarları belirli aralıklarla yenilemek de iyi bir uygulamadır.
DMARC: Doğrulama başarısız olursa ne olacak?
DMARC (Domain-based Message Authentication, Reporting and Conformance), SPF ve DKIM'i bir araya getirip alıcıya bir politika bildirir. DNS'te "_dmarc" alt adına eklenen bir TXT kaydıdır. DMARC'ın kritik kavramı "hizalama"dır: mesajın geçmesi için SPF veya DKIM'den en az birinin başarılı olması ve doğrulanan alan adının, alıcının gördüğü "Kimden" adresindeki alan adıyla uyuşması gerekir. Böylece SPF'in görünen adresi denetlememe sorunu giderilir.
DMARC'ın ikinci önemli katkısı raporlardır. Kayıtta belirttiğiniz adrese, alıcı sistemler sizin alan adınızla gönderilen mesajlara ilişkin toplu raporlar gönderir. Bu raporlar teknik biçimdedir ve genellikle bir rapor okuma aracıyla incelenir; ancak hangi kaynakların sizin adınıza gönderim yaptığını ve hangilerinin doğrulamadan geçemediğini görmenin en pratik yoludur.
| Ne yapar? | Sık görülen hata | |
|---|---|---|
| SPF | Adınıza gönderim yapabilecek sunucuları listeler | Gönderim yapan bir hizmetin unutulması, birden fazla kayıt |
| DKIM | Mesajı imzalar, kaynağını ve bütünlüğünü doğrular | Yalnızca ana e-posta hizmetinde açılması |
| DMARC | Başarısız mesajlara ne yapılacağını söyler, rapor toplar | Yıllarca izleme modunda bırakılması |
Mevcut durumunuzu nasıl görürsünüz?
Başlamak için teknik bir proje gerekmez. Kendi adresinizden dışarıdaki bir e-posta hesabına mesaj gönderin ve alıcı tarafta mesajın "orijinali" ya da "başlık bilgileri" görünümünü açın. "Authentication-Results" satırında spf, dkim ve dmarc için "pass" ya da "fail" sonuçlarını görürsünüz. Bu denemeyi fatura programı ve iletişim formu gibi diğer gönderim kaynaklarınız için de tekrarlayın. Alan adınızın DNS kayıtlarını, ücretsiz çevrim içi DNS sorgulama araçlarıyla da görüntüleyebilirsiniz.
DMARC'a kademeli geçiş
DMARC politikasını ilk günden en sıkı düzeye çekmek, unutulmuş bir gönderim kaynağının mesajlarının reddedilmesine yol açabilir. Güvenli yol aşamalı ilerlemektir:
- Envanter: Alan adınızla e-posta gönderen bütün hizmetleri listeleyin; muhasebe, satış ve pazarlama ekiplerine de sorun.
- SPF ve DKIM: Her kaynağı SPF kaydına ekleyin ve her hizmette DKIM'i açın.
- p=none: DMARC kaydını yalnızca izleme moduyla yayımlayın. Bu aşamada mesajların teslimi etkilenmez, yalnızca rapor toplanır. Raporları birkaç hafta izleyin ve doğrulamadan geçemeyen meşru kaynakları düzeltin.
- p=quarantine: Doğrulamadan geçemeyen mesajların gereksiz klasörüne alınmasını isteyin. İsterseniz "pct" ayarıyla bu politikayı önce mesajların bir bölümüne uygulayabilirsiniz.
- p=reject: Raporlar temiz göründüğünde, doğrulamadan geçemeyen mesajların reddedilmesini isteyin. Sahteciliğe karşı en güçlü koruma bu aşamada sağlanır.
En sık görülen sorun, DMARC'ın p=none aşamasında bırakılıp unutulmasıdır. İzleme modu bilgi toplar ama sahte mesajları durdurmaz; bu yüzden geçiş için baştan bir takvim belirleyin.
E-posta göndermediğiniz alan adları da korunmalıdır. Kullanılmayan ya da yalnızca web sitesi için alınmış alan adlarında "v=spf1 -all" içeren bir SPF kaydı ve p=reject politikalı bir DMARC kaydı yayımlamak, bu adların sahte e-postalarda kullanılmasını zorlaştırır.
Bu kayıtların yapamadıkları
SPF, DKIM ve DMARC, alan adınızın birebir taklit edilmesini zorlaştırır; ancak her şeyi çözmez. Dolandırıcılar sizin adınıza çok benzeyen başka bir alan adı alıp, örneğin bir harfi değiştirerek, o alan adı için kendi kayıtlarını eksiksiz yapabilir. Ele geçirilmiş gerçek bir çalışan hesabından gönderilen mesaj da bütün doğrulamalardan geçer. Bu nedenle hesaplarda çok faktörlü doğrulama, çalışan farkındalığı ve özellikle banka hesabı değişikliği gibi taleplerin önceden bilinen başka bir kanaldan teyit edilmesi bu kayıtların tamamlayıcısıdır.
Kontrol listesi
- Alan adınızla e-posta gönderen bütün hizmetler listelendi mi?
- Alan adınızda tek ve güncel bir SPF kaydı var mı, DNS sorgu sınırı aşılmıyor mu?
- Her gönderim hizmeti için DKIM imzalaması açık mı?
- DMARC kaydı yayımlandı ve raporlar düzenli olarak inceleniyor mu?
- p=none'dan quarantine ve reject aşamalarına geçiş için bir takvim var mı?
- E-posta göndermeyen alan adlarınız için SPF ve DMARC kayıtları yapıldı mı?
- Ödeme ve hesap bilgisi değişikliği talepleri ikinci bir kanaldan teyit ediliyor mu?