SPF, DKIM ve DMARC başlangıç rehberi

SPF, DKIM ve DMARC aynı problemi çözmez

SPF: gönderim kaynağı yetkisi

SPF kaydı, RFC 5321 MAIL FROM veya HELO kimliği için hangi sistemlerin yetkili olduğunu DNS üzerinden belirtir. Kullanıcının ekranda gördüğü From alanını doğrudan doğrulamaz ve yönlendirme gibi akışlarda tek başına kırılabilir.

DKIM: domain imzası ve içerik bütünlüğü

DKIM gönderen sistemin belirli başlıkları ve gövdeyi özel anahtarla imzalamasını sağlar. Alıcı, DNS'teki açık anahtarla imzayı doğrular. Geçerli DKIM imzası mesajın güvenli veya zararsız olduğunu değil, imzalanan içeriğin ilgili domain adına doğrulandığını gösterir.

DMARC: hizalama, politika ve geri bildirim

DMARC, kullanıcının gördüğü RFC 5322 From domaini ile SPF veya DKIM tarafından doğrulanan domainlerden en az birinin hizalanmasını arar. Domain sahibi ayrıca başarısız mesajlar için izleme, karantina veya reddetme politikasını ve aggregate rapor hedefini yayınlayabilir.

DNS değişikliğinden önce gönderici envanteri çıkarın

En sık kesinti nedeni, gerçek gönderim kaynaklarının bilinmeden sıkı politika uygulanmasıdır. Kurumsal posta, CRM, destek sistemi, fatura uygulaması, bülten servisi, güvenlik ürünü ve yetkili simülasyon altyapısı ayrı ayrı kayda alınmalıdır.

• Her servisin envelope-from, görünen From ve DKIM imza domainini belirleyin.
• Hangi ekip veya tedarikçinin DNS kaydından ve anahtar dönüşümünden sorumlu olduğunu yazın.
• Üçüncü taraf gönderimler için mümkünse ayrı alt domain kullanın.
• Kullanılmayan eski servisleri SPF ve DKIM yetkisinden çıkarın.
• Test, pazarlama ve işlem e-postalarının itibarını birbirinden ayırın.

Güvenli kurulum sırası

1. SPF'i sadeleştirin: Domain başına tek SPF kaydı tutun, yetkili kaynakları envanterle eşleştirin ve RFC'deki DNS sorgu sınırını gözetin.
2. DKIM'i etkinleştirin: Her gönderen için ayrı selector ve güncel anahtar politikası kullanın; özel anahtarı DNS'e koymayın.
3. Hizalamayı test edin: SPF veya DKIM sonucunun yalnız geçerli değil, görünen From domainiyle DMARC açısından hizalı olduğunu doğrulayın.
4. Raporları toplayın: DMARC aggregate raporlarını güvenli bir posta kutusu veya rapor servisine yönlendirin.
5. Politikayı kademeli sıkılaştırın: Meşru akışlar düzeltildikten sonra karantina ve reddetme kararına kontrollü geçin.

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Bu kayıt yalnız biçim örneğidir. Domain adı, rapor adresi, alt domain politikası, hizalama modu ve yüzdelik uygulama değeri kurumun gerçek posta mimarisine göre tasarlanmalıdır.

DMARC politikasını neden bir anda reject yapmamalısınız?

p=none aşaması görünürlük sağlar; başarısız mesajların otomatik olarak reddedilmesini istemez. Raporlar düzenli analiz edilmeden doğrudan p=reject uygulanması, unutulmuş meşru göndericilerin teslimatını bozabilir.

Geçiş planında en azından kaynak sahipliği, SPF kapsamı, DKIM imzası, hizalama, yönlendirme ve mailing-list etkisi, alt domainler ve başarısızlık oranı izlenmelidir. Politika değişikliği öncesinde geri dönüş kaydı ve sorumlu ekip hazır olmalıdır.

Yaygın beş hata

• Aynı domain için birden fazla SPF TXT kaydı yayınlamak.
• SPF sonucunun görünen From adresini doğruladığını varsaymak.
• DKIM anahtarını döndürmeden yıllarca aynı selector'ı kullanmak.
• DMARC raporlarını toplamak ancak sahip ve aksiyon süreci tanımlamamak.
• Simülasyon veya üçüncü taraf gönderimini ana kurumsal domain itibarıyla karıştırmak.