Ana içeriğe geç

Sorun Giderme · Kurumsal E-posta ve İş Birliği

Yönlendirilen E-postada DMARC Hatası: SPF, DKIM ve ARC

Mail yönlendirildiğinde alıcı yeni gönderici IP’sini görür; SPF bu nedenle başarısız olabilir. DKIM imzası kapsadığı içerik değişmediyse geçerliliğini koruyabilir. DMARC görünür From…

Teknik gözden geçirme:

Mimari ve çalışma modeli

Mail yönlendirildiğinde alıcı yeni gönderici IP’sini görür; SPF bu nedenle başarısız olabilir. DKIM imzası kapsadığı içerik değişmediyse geçerliliğini koruyabilir. DMARC görünür From alanıyla SPF veya DKIM kimliğinin hizalanmasını ister; iki testin sırf pass olması yeterli değildir.

Footer ekleyen gateway veya mailing list DKIM imzasını bozabilir. ARC ara sistemin kimlik doğrulama sonucunu zincirleyebilir, fakat her ARC kaydı güvenilir sayılmaz. Google Workspace ve Microsoft 365’in gateway/forwarding davranışını gerçek header üzerinden değerlendirin; p=none’a kalıcı dönüş teşhis değildir.

  1. 1İlk gönderen
  2. 2Forwarder/gateway
  3. 3SPF/DKIM/ARC sonuçları
  4. 4DMARC hizalama
Ham header’ı saklayın.

Tasarım parametreleri

Header zinciri
Received, Authentication-Results, DKIM d= ve görünür From alanlarını ham mesajda okuyun.
Dönüş adresi
SRS forwarding’de SPF yolunu değiştirebilir; DMARC hizalamasını otomatik çözmüş saymayın.
ARC güveni
Zincir doğrulama ve güvenilen sealer kapsamını hizmet belgesinde kontrol edin.

Hesap ve uygulama örneği

From alice@example.test, DKIM d=example.test olsun. Yönlendiren IP SPF’de yoksa SPF fail olabilir; değişmeyen ve hizalı DKIM pass ise DMARC geçebilir. Gateway imzalı gövdeyi değiştirirse DKIM fail olur; iki teslim kopyasının header ve gövdesini karşılaştırın.

Hata teşhisi

BelirtiOlası neden / ayrımDoğrulama
SPF fail, DMARC passHizalı DKIM başarılı.header.d ve header.from eşleşmesini doğrulayın.
Yalnız forward edilmiş mesaj bozukİmza değişimi veya envelope farkı.Forward öncesi/sonrası ham mesajı karşılaştırın.

Kabul ve doğrulama kontrolleri

  1. Ham header’ı saklayın.
  2. SPF kimliğini From’dan ayırın.
  3. DKIM hizalamasını doğrulayın.
  4. Gövde değişimini kontrol edin.
  5. ARC güven zincirini inceleyin.
  6. Kontrol politikasını zayıflatmadan retesti yapı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.

TLS ve sertifika doğrulaması

TLS iletişimin gizliliğini ve bütünlüğünü sağlar; sertifika doğrulaması karşı taraf kimliğinin kontrolüne yardımcı olur. Sertifika adı, zincir, geçerlilik süresi ve güvenilen kökler birlikte değerlendirilmelidir. Bir bağlantının şifreli olması uygulamanın yetkilendirmesinin doğru olduğu anlamına gelmez. Reverse proxy veya inspection kullanılıyorsa TLS oturumunun hangi noktada sonlandırıldığını çizimde açıkça gösterin. Hata teşhisinde sertifika kontrolünü kapatmak kalıcı çözüm değildir; yanlış hostname, eksik ara sertifika ve cihaz saatini ayrı inceleyin.

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; log yokluğu, olay yokluğu şeklinde yorumlanmamalıdır.

Bağımlılık ve geri açılış sırası

Bir hizmet çoğu zaman kimlik, DNS, zaman, ağ, veritabanı ve lisans servislerine bağlıdır. Bağımlılıkları yalnız cihaz listesi olarak değil, hangi hizmetin hangi koşulla çalışabildiğini gösteren bir grafik olarak kaydedin. Geri açılış sırası buna göre belirlenir; bazı döngüsel bağımlılıklar özel acil erişim gerektirir. Çalışan altyapı bileşenleri ile işin yeniden başlayabildiği anı ayırın. Her bağımlılığa sorumlu, doğrulama yöntemi ve alternatif erişim yolu atayın. Uçtan uca testte bir bileşeni bilerek erişilemez hale getirerek varsayımları sınayı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.

Birincil teknik dokümantasyon

Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.

Bilgi Merkezi

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ı!