Ana içeriğe geç

SecuraWall.com

E-posta güvenliği ve sürekliliği

Keşfedin
Teknik Rehber · Microsoft 365 & Cloud

Exchange Online için SPF, DKIM ve DMARC Rehberi

SPF, DKIM ve DMARC; alan adınız adına gönderilen e-postaların doğrulanmasına ve sahte gönderimlerin politika ile yönetilmesine yardımcı olan tamamlayıcı mekanizmalardır.

SON TEKNİK GÖZDEN GEÇİRME:
Microsoft 365 & Cloud

Bu Konu Neden Önemli?

SPF, DKIM ve DMARC; alan adınız adına gönderilen e-postaların doğrulanmasına ve sahte gönderimlerin politika ile yönetilmesine yardımcı olan tamamlayıcı mekanizmalardır.

Karar Verirken Kontrol Edilecek Noktalar

SPF kaydında gereksiz include ve kaynakları azaltın.

DKIM anahtarlarını etkinleştirip düzenli doğrulayın.

DMARC'ı raporlama ile başlayıp kademeli sıkılaştırın.

Üçüncü taraf gönderim servislerini envanterleyin.

Mimari ve çalışma modeli

SPF mesajın zarf gönderen alanı için hangi sunucuların gönderim yapabileceğini bildirir. DKIM belirli başlıkları ve gövdeyi alan adı anahtarıyla imzalar. DMARC ise görünen From alanı ile SPF veya DKIM kimliğinin hizalanmasını değerlendirir. SPF pass olması tek başına DMARC pass anlamına gelmez. DNS kaydının bulunması da gerçek mesajın doğru yoldan çıkacağını kanıtlamaz.

İletme işlemi SPF kontrolünü bozabilir; korunmuş ve hizalı DKIM imzası bazı akışlarda DMARC sonucunu sağlayabilir. Mesajı değiştiren ara sistemler DKIM imzasını da bozabilir. Harici CRM, bülten, tarayıcı ve faturalama servisleri gönderici envanterine dahil edilir. DMARC izleme raporları incelenmeden reject politikasına geçmek meşru postayı engelleyebilir. TXT kayıtları, anahtar rotasyonu ve DNS yayılımı kontrollü değişikliktir.

  1. 1Gönderici envanteri
  2. 2SPF ve DKIM kimliği
  3. 3From alanıyla hizalama
  4. 4DMARC sonucu ve rapor
Her gönderim kaynağı için gerçek mesaj başlıklarında SPF, DKIM ve DMARC sonucunu ayrı doğrulayın.

Tasarım parametreleri

Hizalama
Görünen From domainini SPF zarf kimliği ve DKIM d= alanıyla karşılaştırın; yalnız SPF pass yeterli değildir.
DNS ve gönderici envanteri
Tek doğru SPF kaydı, lookup sınırı, DKIM selectorı ve harici servisleri birlikte kontrol edin.
Kimlik ve tenant sınırı
Kullanıcı, misafir, yönetici ve uygulama kimliklerini ayırın. Tenant politikaları ile tek kaynağın izinleri aynı kapsam değildir.
Veri sahipliği ve yaşam döngüsü
Verinin sahibi, saklama süresi, silinme yolu ve geri kazanım yöntemi belirlenmelidir. Senkronizasyon ile yedeklemeyi ayırın.
Lisans ve özellik kapsamı
Kullanıcı rolü, cihaz, tenant ve gerekli özellik üzerinden lisans doğrulayın. Güncel paket adını geçmiş bilgiyle varsaymayın.
Bağlantı ve maliyet
İnternet, kimlik servisi, veri çıkışı, depolama ve işletim giderini birlikte değerlendirin. Bütçe alarmının harcamayı otomatik durdurduğunu varsaymayın.

Hesap ve uygulama örneği

Görünen gönderen firma.example, zarf gönderen ise hizmet.example olsun. SPF hizmet.example için geçse bile firma.example ile hizalanmadığı için bu sonuç DMARC şartını tek başına karşılamaz. Firma alanıyla hizalı DKIM imzasını gerçek mesajın Authentication-Results başlığında doğrulayın. Önce raporları toplayın, tüm meşru kaynakları düzeltin ve politikayı aşamalı sıkılaştırın.

Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.

nslookup -type=TXT example.com
nslookup -type=TXT _dmarc.example.com

Hata teşhisi

BelirtiOlası neden / ayrımDoğrulama
SPF geçiyor, DMARC başarısızSPF domaini hizalı değil ve DKIM sonucu uygun olmayabilir.Gerçek Authentication-Results başlığında kimlik, hizalama ve DKIM’i ayrı inceleyin.
Bazı kullanıcılar erişemiyorLisans, grup, cihaz durumu veya erişim politikası farklı olabilir.Etkilenen ve çalışan kullanıcıların karar kayıtlarını karşılaştırın.
Silinen veri geri getirilemiyorSaklama ve kurtarma kapsamı beklenenden farklı olabilir.Nesne türü, silinme zamanı ve resmî kurtarma koşullarını doğrulayın.
Maliyet beklenenden yüksekKaynak boyutu, veri çıkışı, saklama veya taahhüt kullanımı farklı olabilir.Kaynak ve hizmet bazında gerçekleşeni tahminle eşleştirin.

Kabul ve doğrulama kontrolleri

  1. Her gönderim kaynağı için gerçek mesaj başlıklarında SPF, DKIM ve DMARC sonucunu ayrı doğrulayın.
  2. Her meşru gönderim servisini envantere ve DNS tasarımına dahil edin.
  3. Gerçek mesajda görünen From ile SPF/DKIM kimlik hizalamasını doğrulayın.
  4. İletilmiş mesajın Authentication-Results sonucunu ayrıca kontrol edin.
  5. DMARC raporlarını inceleyip politikayı aşamalı sıkılaştırın.
  6. DKIM rotasyonunda eski/yeni selector ve DNS yayılımını doğrulayın.

İlgili kavramlar

DNS önbelleği ve bağımlılık

DNS cevabı yalnız kaydın authoritative sunucudaki değerine bağlı değildir; istemci ve recursive resolver önbellekleri de sonucu etkiler. TTL değişikliği daha önce önbelleğe alınmış yanıtların ömrünü geriye dönük kısaltmaz. A/AAAA, CNAME, MX ve TXT kayıtları farklı işlevlere sahiptir. İç ve dış görünümü ayrı test edin; split DNS nedeniyle cevapların farklı olması tasarlanmış olabilir. Arıza araştırmasında kullanılan resolver, yanıt türü, TTL ve sorgu zamanını kaydedin. IP ile erişimin çalışması tek başına DNS yapılandırmasının doğru olduğunu göstermez.

Kimlik doğrulama ve oturum

Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.

Güven sınırı ve hata alanı

Güven sınırı, aynı erişim kararlarını paylaşan bileşenleri ayırır; hata alanı ise tek bir olayın birlikte etkileyebileceği kaynakları tanımlar. İki VLAN kullanmak, aralarında serbest yönlendirme varsa güçlü bir güven sınırı kurmaz. İki yedek aynı yönetici hesabıyla silinebiliyorsa da farklı klasörlerde bulunmaları ayrı hata alanı sağlamaz. Tasarımda fiziksel yer, kimlik sağlayıcı, yönetim hesabı, ağ yolu ve enerji kaynağını ayrı ayrı değerlendirin. Bir bileşen kaybedildiğinde hangi erişimlerin ve kurtarma seçeneklerinin ayakta kalacağını sınayın.

Politikanın yaşam döngüsü

Bir politika yalnız etkinleştirildiği anda değil, kapsamı değiştikçe de yönetilmelidir. Taslak, gözlem, pilot, uygulama ve periyodik inceleme aşamalarını ayırın. Her istisnanın sahibi, gerekçesi, kapsamı ve sona erme tarihi olmalıdır. Test verileri gerçek kullanıcı davranışını temsil etmezse başarılı pilot üretimde yanlış engellemelere dönüşebilir. Önce kimin ve hangi uygulamanın etkilenebileceğini belirleyin; sonra ölçülebilir kabul koşullarıyla devreye alın. Geri alma yolu yalnız düğme konumunu değil, değişikliğin kim tarafından ve hangi koşulda geri alınacağını da tanımlamalıdır.

Telemetri ve zaman eşleştirmesi

Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.

Yüksek erişilebilirlik ile kurtarma ayrımı

Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve yedekleme birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.

Birincil teknik dokümantasyon

SecuraWall MailFlow

E-posta Güvenliği ve Sürekliliği

Backup MX, SMTP Gateway, AntiSpam ve Antivirus hizmetleri.

SecuraWall MailFlow’u keşfedin
Who · How · Why

Bu İçerik Nasıl Hazırlandı?

Kim?

Doz Teknoloji Teknik Ekibi

İçerik, Doz Teknoloji’nin kurumsal BT hizmet alanlarında kullandığı teknik değerlendirme yaklaşımı temel alınarak hazırlanmıştır.

Nasıl?

Teknik kriterler + birincil kaynaklar

Konu; üretici dokümantasyonu, standart kuruluşları ve ilgili resmî teknik kaynaklarla çapraz kontrol edilmiştir.

Neden?

Karar kalitesini artırmak

Amaç, teknik bir terimi yalnız tanımlamak değil; satın alma, tasarım veya işletim kararı verirken hangi kriterlerin birlikte değerlendirilmesi gerektiğini görünür hale getirmektir.

SON TEKNİK GÖZDEN GEÇİRME

Bu Rehberle İlgili Kurumsal Çözümler

Teknik konuyu uygulamaya dönüştürmek için ilgili hizmet ve çözüm sayfalarına geçebilirsiniz.

Teknik İhtiyacınızı Birlikte Değerlendirelim

Mevcut altyapınızı, kullanıcı sayınızı veya teknik hedefinizi paylaşın; ürün, lisans veya proje kapsamını ihtiyaca göre netleştirelim.

Teknik Talep Oluşturun
Kurumsal IT Ürün Satışı, Lisanslama ve Kurulum
Kurumsal IT Proje & Çözüm Senaryoları
Tüm ilgili içerikleri görüntüleyin
WhatsApp'tan Yazın
Kopyalandı!