X

Lütfen Ülke (Bölge) Seçiniz

Türkiye (Türkçe)Türkiye (Türkçe) Worldwide (English)Worldwide (English)
X

Lütfen Para Birimi Seçiniz

₺ Türk Lirası $ US Dollar
X

Lütfen Ülke (Bölge) Seçiniz

Türkiye (Türkçe)Türkiye (Türkçe) Worldwide (English)Worldwide (English)
X

Lütfen Para Birimi Seçiniz

₺ Türk Lirası $ US Dollar

Kurumsal E-posta İçin SPF, DKIM ve DMARC Ayarları

AnasayfaYazılarTeknik RehberlerKurumsal E-posta İçin SPF, DKIM ve ...

Kurumsal e-posta iletilerinin alıcının spam klasörüne düşmesini azaltmak ve alan adının başkaları tarafından taklit edilmesini zorlaştırmak için önce SPF, DKIM ve DMARC yapılandırılmalıdır. Bunun için alan adı DNS yönetimine ve kullandığınız e-posta servisinin yönetim ekranına erişmeniz gerekir. Kayıtları eklemeden önce mevcut DNS değerlerini not edin; çünkü aynı hizmette yapılan küçük bir değişiklik, gönderim ve alım akışını etkileyebilir.

Kurumsal e-posta doğrulaması neyi çözer?

SPF, alan adınız adına e-posta göndermesine izin verilen sunucuları DNS üzerinde tanımlar. DKIM, gönderilen iletiye alan adınızla ilişkili bir dijital imza ekler; alıcı sunucu bu imzanın değiştirilmediğini doğrular. DMARC ise SPF ve DKIM sonuçlarının, ileti başlığındaki gönderen alan adıyla nasıl eşleşeceğini belirler ve başarısız iletiler için uygulanacak politikayı bildirir.

Bu kayıtlar tek başına teslimatı garanti etmez. Gönderen itibarınız, alıcının filtreleri, ileti içeriği, gönderim hacmi ve servis sağlayıcının kendi kuralları da sonucu etkiler. Yine de belirli bir gönderim hizmeti kullanıyorsanız, SPF kaydında o hizmetin yetkili sunucusu bulunmalı; DKIM anahtarı sağlayıcı ekranında etkinleştirilmeli ve DMARC politikası mevcut akış doğrulanmadan sertleştirilmemelidir.

Başlamadan önce mevcut gönderim akışını çıkarın

Önce hangi sistemlerin alan adınız adına ileti gönderdiğini listeleyin: ana e-posta sağlayıcısı, web sitesi iletişim formu, müşteri ilişkileri yazılımı ve pazarlama platformu gibi. Bir sistemin gönderdiği iletiler SPF içinde yetkilendirilmezse SPF başarısız olabilir. DKIM desteği olmayan bir sistem için de sağlayıcının alternatif doğrulama yöntemini veya ayrı bir gönderim alt alan adını incelemek daha güvenlidir.

Diyelim ki çalışanlar bir e-posta hizmetinden, web siteniz ise ayrı bir uygulama sunucusundan ileti gönderiyor. Sadece e-posta hizmetinin SPF değerini eklemek, web sitesi formlarını doğrulama dışında bırakabilir. Gönderimler yalnızca çalışan hesaplarından yapılıyorsa daha dar SPF kaydı tercih edilir; iki ayrı kaynak varsa ikisini de sağlayıcıların önerdiği tek SPF kaydında birleştirmek gerekir. Aynı alan adı için birden fazla SPF kaydı oluşturmak yerine mevcut kaydı düzenleyin.

SPF, DKIM ve DMARC kayıtlarını adım adım yapılandırma

Aşağıdaki işlem, alan adının DNS paneline ve e-posta servisinin yönetici ekranına erişimi olan kişiler içindir. Menü adları sağlayıcıya göre değişebilir; servis sağlayıcının verdiği ana bilgisayar adı, kayıt türü ve değeri esas alınmalıdır.

  1. Mevcut DNS kayıtlarını yedekleyin. DNS panelinde alan adınıza ait TXT kayıtlarını dışa aktarın veya değerlerini güvenli bir yere kopyalayın. Özellikle mevcut SPF kaydını ve varsa _dmarc kaydını saklayın. Aynı ad için bir SPF kaydı zaten varsa yeni kayıt açmayın; hangi gönderim kaynaklarının eksik olduğunu belirleyip mevcut değeri buna göre düzenleyin.
  2. SPF kaydını servis listesine göre güncelleyin. E-posta sağlayıcınızın önerdiği TXT değerini, varsa web sitesi veya üçüncü taraf gönderim hizmetinin yetkilendirmesiyle birlikte kullanın. DNS paneli kaydı kabul ediyor ancak alıcı raporlarında SPF başarısız görünüyorsa, gönderim sunucusunun gerçekten SPF içinde tanımlı olup olmadığını kontrol edin. Sorun yalnızca uygulama iletilerindeyse tüm politikayı gevşetmek yerine o uygulamanın doğru gönderim kaydını ekleyin.
  3. DKIM anahtarını oluşturup etkinleştirin. E-posta servisinin yönetim ekranında DKIM kurulumu bölümünü açın ve servis tarafından verilen seçici adını ve TXT veya CNAME hedefini DNS paneline ekleyin. Doğrulama başarılı olduğunda sağlayıcı ekranındaki durum etkin veya doğrulanmış görünür. Kayıt bulunamıyorsa seçici adındaki alt çizgi, nokta ve alan adı sonunun panel tarafından otomatik eklenip eklenmediğini inceleyin; aynı kaydı ikinci kez oluşturmadan önce DNS görünürlüğünün yayılmasını bekleyin.
  4. DMARC politikasını önce izleme modunda başlatın. _dmarc ana bilgisayar adına, sağlayıcınızın desteklediği bir rapor adresiyle izleme politikası ekleyin. Bu aşamada amaç başarısız iletileri gözlemlemektir; SPF veya DKIM sonucu başarısız olan meşru sistemleri tanımlamadan iletileri reddeden katı bir politika kullanmayın. Raporlarda yalnızca beklemediğiniz bir gönderim kaynağı görürseniz bunun gerçek bir uygulama mı yoksa yetkisiz kullanım mı olduğunu ayırın.
  5. Aynı gönderimi tekrarlayıp yeni kanıtı kontrol edin. Değişikliklerden sonra aynı kurumsal hesaptan, kendi kontrol edebildiğiniz bir alıcı adrese kısa bir test iletisi gönderin. İletinin özgün başlıklarında SPF, DKIM ve DMARC sonuçlarını inceleyin; ayrıca değişiklikten sonraki zamana ait yeni DMARC raporlarını kontrol edin. SPF ve DKIM başarılı, fakat DMARC başarısızsa sonuçların alan adı hizalamasını inceleyin; gönderen görünen alan adı ile imza veya dönüş yolu alan adı uyumlu olmayabilir.

Sonuçlara göre güvenli düzeltme seçimi

SPF başarısız, DKIM başarılıysa önce SPF kaydında gönderim yapan hizmetin eksik olup olmadığını araştırın; DKIM doğrulamasını bozacak şekilde rastgele DNS değişikliği yapmayın. DKIM başarısız, SPF başarılıysa servis ekranındaki seçici ve anahtarın DNS kaydıyla birebir eşleştiğini kontrol edin. Her iki yöntem de başarılı fakat DMARC başarısızsa sorun çoğunlukla alan adı hizalamasıdır; görünen gönderen alan adı, dönüş yolu veya DKIM imzalayan alan adının sağlayıcı tarafından nasıl ayarlandığını inceleyin.

Test iletisi doğru sonuç veriyor ancak gerçek uygulama iletileri başarısız oluyorsa uygulama ile e-posta hizmetinin farklı gönderim yolları kullandığını varsayın ve yeni iletinin başlıklarını ayrı inceleyin. Bir kaynağı düzeltirken diğerini etkilememek için aynı anda yalnızca tek DNS değerini değiştirin. Değişiklikten önceki değeri saklayın; yeni değer beklenmeyen alım veya gönderim sorununa yol açarsa yalnızca son değişikliği geri alıp yeniden test edin.

DMARC politikasını ne zaman sıkılaştırmalı?

İzleme raporlarında bilinen tüm gönderim kaynakları SPF veya DKIM ile doğrulanıyor ve meşru iletilerde DMARC hizalaması sağlanıyorsa politikayı kademeli olarak sıkılaştırmayı değerlendirebilirsiniz. Önce başarısız iletileri spam olarak işaretleme yaklaşımı, ardından reddetme yaklaşımı düşünülebilir; kesin değerler ve rapor biçimi sağlayıcıya göre değişir. Bilinmeyen bir kaynak düzenli olarak görünüyorsa reddetmeden önce bunun unutulmuş bir uygulama, yönlendirme sistemi veya gerçekten yetkisiz gönderim olup olmadığını doğrulayın.

Alan adı kayıtlarınızın ve kullandığınız gönderim servislerinin durumunu birlikte gözden geçirmek için İyibirNet sitesindeki ilgili kaynaklardan yararlanabilirsiniz. Bir sonraki güvenli adım, yeni yapılandırmayla aynı test iletisini tekrar göndermek ve bu gönderime ait başlık sonuçlarını önceki kayıtlarla karşılaştırmaktır.


Top