E-Posta Güvenliği

DMARC Fail (Başarısız) Olduğunda Sorun Giderme: SPF/DKIM, Alignment ve DNS Kaynaklı Hataları Hızlı Teşhis Etme

13.10.2026 · 6 dk okuma

DMARC fail ne demektir ve neden tek başına “SPF/DKIM bozuk” anlamına gelmez?

DMARC, alıcı tarafın bir e-postayı değerlendirirken “Kimlik doğrulama (authentication) geçti mi?” sorusunu daha net yanıtlamasını sağlar. Ancak DMARC sonucunun fail olması, mutlaka SPF ve DKIM’in ikisinin de teknik olarak çalışmadığı anlamına gelmez. DMARC; SPF ve DKIM sonuçlarını, ayrıca bu sonuçların gönderen alan adıyla uyumunu (alignment) birlikte değerlendirir. Bu yüzden “SPF=pass ama DMARC=fail” gibi görünen durumlar pratikte sık yaşanır.

Bu makalede bir DMARC fail vakasını hızlı teşhis etmek için pratik bir triage (önceliklendirilmiş inceleme) yaklaşımı bulacaksınız. Amaç; bir e-postanın neden DMARC’tan kaldığını, sorunun SPF tarafında mı DKIM tarafında mı alignment tarafında mı yoksa DNS ve yönlendirme gibi çevresel faktörlerde mi olduğunu sistematik biçimde anlamaktır.

Hızlı teşhis için önce doğru veriyi toplayın

Sorun giderme, doğru örnekle başlar. Mümkünse aşağıdaki verileri aynı olay için tek bir yerde toplayın:

  • Alıcının verdiği hata/uyarı: “550 DMARC fail” gibi bir SMTP yanıtı veya spam klasörüne düşme bilgisi.
  • Mesajın tam header’ı: Authentication-Results, Received, Return-Path, From gibi alanlar kritik.
  • Gönderim kaynağı: Kullanıcı mı gönderdi, bir uygulama mı (web sitesi, CRM, muhasebe yazılımı), bir cihaz mı (yazıcı, kamera), yoksa üçüncü taraf bir servis mi?
  • DNS kayıtları: Alan adının SPF, DKIM selector kayıtları ve DMARC kaydı.

Bu veriler olmadan yapılan yorumlar çoğu zaman yanlış yönlendirir; çünkü DMARC değerlendirmesi “hangi alan adı, hangi IP, hangi imza, hangi envelope-from” sorularının birleşimidir.

Adım 1: Header’dan “From”, “Return-Path” ve DKIM d= alanını ayırın

DMARC’ı anlamanın en önemli adımı, üç alan adını birbirinden ayırmaktır:

  • Header From: Kullanıcının gördüğü gönderen alan adı (ör. user@firma.com). DMARC politikası bu alan adına göre uygulanır.
  • Envelope From / Return-Path: SPF’in kontrol ettiği alan adı (ör. bounce@mailer.firma.com veya bounces@thirdparty.example).
  • DKIM d=: DKIM imzasının ait olduğu alan adı (ör. d=firma.com veya d=mail.firma.com).

DMARC pass olması için, SPF veya DKIM’den en az biri pass olmalı ve ayrıca pass olan mekanizmanın alan adı Header From ile alignment sağlamalıdır. Alignment relaxed veya strict olabilir; organizasyonun DMARC kaydında hangi modların kullanıldığına bağlı olarak değerlendirme değişebilir.

Adım 2: “SPF pass ama DMARC fail” senaryosunu doğru okuyun

Bu senaryo genelde alignment problemidir. Yani SPF gerçekten geçmiştir, ama SPF’in kontrol ettiği alan adı (Return-Path/envelope-from) Header From ile uyumlu değildir. Örnek tipik durumlar:

  • Bir üçüncü taraf servis, kendi bounce domainini kullanıyordur: Return-Path thirdparty.example, From firma.com. SPF pass olur, DMARC fail olabilir.
  • Kurumsal alan adında From kullanılırken, uygulama başka bir domain üzerinden zarf göndereni atıyordur.
  • Yönlendirme/forwarding veya gateway senaryolarında SPF’in değerlendirdiği yol değişmiştir.

Bu durumda çözüm çoğu zaman DKIM’i doğru kurup From ile align ettirmektir; çünkü SPF alignment’ı üçüncü tarafların kontrolündeki bounce domain nedeniyle sağlamak her zaman mümkün değildir.

Adım 3: “DKIM pass ama DMARC fail” neden olur?

İlk bakışta çelişkili görünür, ama burada da alignment devreye girer. DKIM=pass demek, imza kriptografik olarak doğrulandı demektir. DMARC için ise bu imzanın d= alanı Header From ile uyumlu olmalıdır. Sık nedenler:

  • d= farklı bir domain: Örneğin d=thirdparty.example, From=firma.com.
  • Yanlış selector/DNS yayılımı: Bazı alıcılar eski DNS’i görüyor ve imza doğrulanıyor gibi görünse de farklı yollarda doğrulama tutarsızlaşıyor.
  • Mesajın gövdede değişmesi: Bazı geçitler (disclaimer ekleme, konu satırı değişimi, içerik filtreleri) DKIM imzasını bozabilir. Burada bazen “pass” görülen örnek ile “fail” olan örnek farklı akıştan geçiyor olabilir.

Bu adımda kritik kontrol, DKIM d= değerinin kurumun From alan adıyla aynı mı (veya relaxed alignment kapsamında alt alan adı mı) olduğudur.

Adım 4: DMARC fail’in DNS kaynaklı yaygın nedenleri

SPF kaydı yok, yanlış yerde veya sözdizimi hatalı

SPF kaydı, domainin TXT kaydıdır ve tek bir doğru SPF kaydı olması beklenir. Birden fazla SPF TXT kaydı, yanlış “include” kullanımı veya sözdizimi hataları SPF’in “permerror/temperror” üretmesine neden olabilir. SPF bozulursa DMARC’ın SPF tarafındaki şansı da düşer.

DKIM public key kaydı yanlış selector’da veya yanlış domain altında

DKIM’de selector._domainkey.domain.tld formatı kullanılır. Selector adı yanlış seçilirse, DNS kaydı yanlış yere yazılırsa veya kopyalama sırasında anahtar kırılırsa DKIM fail olur. Ayrıca bazı kurumlar yanlışlıkla DKIM’i subdomain’e yazıp From alan adını root domain’de tutarak alignment sorunları yaşayabilir.

DMARC kaydı hatalı veya yanlış subdomain’de

DMARC kaydı _dmarc.domain.tld altında bulunur. Yanlış konuma yazılırsa alıcı DMARC politikasını bulamaz veya beklenmedik değerlendirme yapabilir. Ayrıca p=reject gibi katı bir politika, küçük bir yapılandırma hatasında bile teslimatı doğrudan etkileyebilir.

Adım 5: Yetkisiz gönderim mi, yoksa yanlış yapılandırma mı?

DMARC fail her zaman “saldırı var” anlamına gelmez. Çok sık, meşru bir sistem yanlış yapılandırılmıştır. Ayırt etmek için şu sorular işe yarar:

  • Gönderim hacmi: Aniden artan hacim ve farklı ülkeler/IP’ler yetkisiz kullanımı işaret edebilir.
  • Gönderim kaynağı biliniyor mu?: Kullanıcı “ben gönderdim” diyorsa kimlik doğrulama sonuçlarına bakarak hangi sistem üzerinden gittiği bulunabilir.
  • Header tutarlılığı: From alan adı sizin, ama Return-Path ve DKIM d= tamamen yabancıysa spoofing olasılığı artar.

Yetkisiz gönderim şüphesi varsa, parolalar ve hesap güvenliği adımları ayrı bir olay yönetimi sürecini gerektirir. Yine de çoğu teslimat probleminde kök neden; SPF/DKIM alignment eksikliği ve üçüncü taraf göndericilerin doğru yetkilendirilmemesidir.

Adım 6: Pratik bir aksiyon planı (kısa kontrol listesi)

  1. Bir örnek mesaj seçin ve tam header’ı alın.
  2. Header From, Return-Path ve DKIM d= domainlerini yazın.
  3. Authentication-Results satırında SPF, DKIM ve DMARC sonuçlarını not edin.
  4. DMARC fail ise hangi tarafın (SPF mi DKIM mi) “pass+aligned” olamadığını belirleyin.
  5. Üçüncü taraf gönderim varsa, tercihen DKIM ile From domainine align
  6. DNS’te SPF/DKIM/DMARC kayıtlarını kontrol edin: tek SPF kaydı, doğru selector, doğru _dmarc konumu, yazım hataları.
  7. Değişiklik yaptıysanız, TTL ve yayılım süresini hesaba katın ve farklı alıcılara test gönderimi yapın.

DMARC fail sorunlarını kalıcı olarak azaltmanın yolu

Kalıcı çözüm, “tek bir gönderici yokmuş gibi” tasarlamaktır. Modern şirketlerde e-posta yalnızca kullanıcılardan çıkmaz; uygulamalar, cihazlar ve servisler de gönderir. Bu yüzden alan adınız adına gönderim yapacak her kaynağın en baştan envanterini çıkarın ve her biri için net bir authentication stratejisi belirleyin.

MX1Mail gibi kurumsal e-posta hizmetlerinde domaininizin DNS ve kimlik doğrulama kayıtlarını düzenli ve dokümante biçimde yönetmek, hem teslim edilebilirliği hem de operasyonel görünürlüğü artırır. DMARC fail olaylarında da aynı disiplin, sorunu saatler içinde değil dakikalar içinde sınıflandırmanıza yardımcı olur.

Kurumsal e-postanızı MX1Mail ile yönetin.

Güvenli e-posta, ekip iletişimi ve iş yönetimi tek platformda.

MX1Mail’i İncele