E-postanız alıcıya ulaşmadan "550 5.7.26 This message does not pass authentication checks" veya benzeri bir hatayla reddedildiyse büyük olasılıkla DMARC politikasıyla karşılaştınız. Bu rehber, hatanın kökünü tespit etmeyi ve kalıcı olarak çözmeyi adım adım açıklıyor.
p=none ile izlemeye alın; raporlar temizlendikten sonra p=quarantine ardından p=reject'e geçin.DMARC (Domain-based Message Authentication, Reporting, and Conformance), RFC 7489'da tanımlanan bir e-posta kimlik doğrulama protokolüdür. SPF (RFC 7208) ve DKIM (RFC 6376) üzerine inşa edilen DMARC, alan adı sahiplerine "benim adımdan gönderilen ancak doğrulamayı geçemeyen e-postalara ne yapılsın?" sorusunun yanıtını DNS üzerinden bildirme imkânı tanır.
Bir e-posta sunucusu mesajı aldığında şu kontrol zincirini işletir:
From: başlığındaki alan adının SPF kaydında yetkili mi?From: alanıyla hizalı mı?Üçü de başarısız olursa, alıcı sunucu alan adının _dmarc TXT kaydındaki politikaya (p=none, p=quarantine veya p=reject) göre mesajı işler. p=reject politikasında sunucu mesajı 5xx kalıcı hatasıyla geri döndürür; gönderen tarafta bu durum "bounce" olarak kaydedilir.
Farklı e-posta sağlayıcıları DMARC reddini farklı kodlarla bildirir. Aşağıdaki tablo en yaygın hata mesajlarını ve kaynaklarını özetlemektedir:
| Hata Kodu / Mesajı | Sağlayıcı | Olası Neden |
|---|---|---|
550 5.7.26 — This message does not pass authentication checks |
Google Workspace / Gmail | SPF veya DKIM hizalaması başarısız; p=reject politikası aktif |
550 5.7.1 — Message rejected due to DMARC policy |
Microsoft 365 / Outlook.com | DMARC politikası p=reject; SPF/DKIM her ikisi de başarısız |
550 5.7.509 — Access denied, sending domain does not pass DMARC verification |
Microsoft Exchange Online | Gönderen alan adının DMARC kaydı p=reject veya SPF yok |
554 5.7.5 — DMARC unauthenticated mail is prohibited |
Yahoo / AOL | Yahoo'nun zorunlu p=reject politikası; @yahoo.com adresiyle gönderim denemesi |
421 4.7.26 — This message does not pass authentication checks (geçici) |
Geçici oran sınırı; DMARC uyum sorunu birleşimi |
Terminal veya bir DNS sorgulama aracıyla alan adınızın DMARC kaydını çekin:
dig TXT _dmarc.sirketiniz.com +short
# veya
nslookup -type=TXT _dmarc.sirketiniz.com
Tipik bir DMARC kaydı şöyle görünür:
v=DMARC1; p=reject; rua=mailto:dmarc-raporlar@sirketiniz.com; ruf=mailto:dmarc-adli@sirketiniz.com; pct=100; adkim=s; aspf=s
Önemli etiketler:
none (sadece izle), quarantine (spam klasörüne gönder), reject (reddet).r (relaxed, varsayılan), s (strict). Strict modda imzalayan alan adı From: alanıyla birebir eşleşmelidir.r veya s.RFC 7208'e göre bir alan adının en fazla bir SPF kaydı olabilir ve DNS sorgusu sayısı 10'u geçemez. Kaydınızı kontrol edin:
dig TXT sirketiniz.com +short | grep spf
Connect365 üzerinden gönderim yapıyorsanız Connect365'in gönderim IP aralığını veya include: mekanizmasını SPF kaydınıza eklemeniz gerekir. Örnek:
v=spf1 include:spf.connect365.com.tr ip4:203.0.113.10 ~all
SPF doğrulaması için Google'ın Toolbox aracını (toolbox.googleapps.com) veya açık kaynaklı pyspf kütüphanesini kullanabilirsiniz. Microsoft'un Remote Connectivity Analyzer aracı (testconnectivity.microsoft.com) da SPF ve DMARC uyumunu analiz eder.
Dikkat: DMARC SPF hizalamasında kontrol edilen alan adı, MAIL FROM (zarf göndereni, RFC 5321) değil, From: başlığıdır. Birçok toplu gönderim platformu kendi alan adını MAIL FROM olarak kullandığından, aspf=s (strict) moduyla hizalama başarısız olabilir. Bu durumda aspf=r (relaxed) tercih edilebilir veya özel gönderim alan adı (bounce.sirketiniz.com) tanımlanabilir.
RFC 6376 kapsamında tanımlanan DKIM, mesajın başlık ve gövdesinin gönderim sunucusu tarafından özel anahtarla imzalandığını ve alıcının DNS'teki ortak anahtarla bu imzayı doğrulayabildiğini garanti eder.
DKIM kaydınızı sorgulayın (seçici adını e-posta başlığındaki DKIM-Signature: s= alanından öğrenebilirsiniz):
dig TXT secici._domainkey.sirketiniz.com +short
Yaygın DKIM sorunları:
DMARC'ın en değerli özelliği raporlamadır. rua= etiketiyle belirttiğiniz adrese günlük XML formatında toplam raporlar gönderilir. Bu raporları elle okumak zahmetlidir; aşağıdaki araçlar süreci kolaylaştırır:
postmaster.google.com): Alan adınızın Gmail'deki itibarını, SPF/DKIM/DMARC uyumunu görsel olarak sunar.Raporlarda dkim=fail veya spf=fail gördüğünüzde, reddedilen mesajların kaynak IP adresleri ve gönderen alan adları da listelenir. Bu sayede yetkisiz gönderim kaynakları (üçüncü taraf hizmetler, eski sunucular) tespit edilebilir.
Mevcut politikanız p=reject ise ve meşru e-postalar reddediliyorsa, politikayı geçici olarak p=none'a çekip sorunu çözdükten sonra yeniden sıkılaştırabilirsiniz. Önerilen geçiş takvimi:
p=none; pct=100; rua=mailto:... — Tüm e-postalar geçer, sadece raporlama aktif.p=quarantine; pct=10 — Mesajların %10'u spam klasörüne düşer; geri kalan normale devam eder.p=quarantine; pct=100 — Uyumsuz tüm mesajlar karantinaya alınır.p=reject; pct=100 — Tam uygulama.E-posta yönlendirmesi (forwarding) DKIM imzasını bozmaz, ancak SPF'i bozabilir. RFC 5321 kapsamında her yönlendirme adımında orijinal gönderici IP'si değişir. ARC (RFC 8617) bu zinciri korumak için tasarlanmıştır; Google ve Microsoft ARC'ı destekler.
Mailchimp, SendGrid, Amazon SES gibi üçüncü taraf gönderim hizmetleri kullanıyorsanız:
include: mekanizmasını veya yetkili IP'lerini kayıtlarınıza ekleyin.mail.sirketiniz.com) kullanın.DMARC kaydı olmayan alan adları, alıcı sunucunun kendi politikasına göre değerlendirilir. Gmail ve Microsoft 365 gibi büyük sağlayıcılar DMARC kaydı bulunmayan alan adlarından gelen e-postaları spam klasörüne düşürebilir; ancak doğrudan reddetmez. Bununla birlikte, büyük hacimli gönderim yapıyorsanız Google ve Yahoo'nun 2024'ten itibaren uyguladığı toplu gönderici gereksinimlerine göre DMARC kaydı zorunludur.
DMARC hizalaması SPF kaydının varlığından fazlasını gerektirir: SPF'in doğruladığı alan adının From: başlığıyla hizalı olması şarttır. Birçok toplu gönderim platformu kendi alan adını MAIL FROM olarak kullandığından, SPF başarılı olsa bile DMARC hizalaması başarısız olabilir. Çözüm için özel gönderim alan adı tanımlamayı veya aspf=r (relaxed) moduna geçmeyi deneyin.
En yaygın neden e-posta yönlendirmesidir: aradaki sunucu mesaj gövdesine başlık eklediğinde veya içeriği değiştirdiğinde DKIM imzası bozulur. Ayrıca bazı güvenlik ağ geçitleri ve spam filtreleri mesajı yeniden biçimlendirerek imzayı geçersiz kılabilir. ARC (RFC 8617) zinciri bu sorunu kısmen çözer.
Yahoo ve AOL, kendi alan adlarını (@yahoo.com, @aol.com) From: olarak kullanan mesajlara yıllardır p=reject uyguluyor. Bu alan adlarından gönderim yapıyorsanız From: adresini kendi kurumsal alan adınıza (@sirketiniz.com) çevirmeniz gerekir; yanıt adresi olarak Yahoo/AOL adresini Reply-To: başlığıyla ekleyebilirsiniz.
Hızlı geçiş yasak değil ama risklidir. DMARC raporlarında en az iki tam hafta boyunca tüm meşru gönderim kaynaklarınızın %100 uyum sağladığını gördükten sonra p=quarantine'e, ardından daha iki haftalık temiz rapor sonrası p=reject'e geçmeniz önerilir.
Evet. RFC 7208 açıkça belirtir: bir alan adı için yalnızca bir SPF TXT kaydı olabilir. Birden fazla kayıt varsa alıcı sunucular hangisini kullanacağını bilemez ve PermError döner; bu da SPF'in başarısız sayılmasına yol açar. Tüm yetkili kaynakları tek bir kayıtta birleştirin.
Raporlar, _dmarc kaydınızdaki rua=mailto: adresine günlük gzip'li XML dosyaları olarak gelir. Alıcı adres farklı bir alan adındaysa (örn. üçüncü taraf analiz servisi), o alan adı sirketiniz.com._report._dmarc.analizservisi.com TXT kaydıyla kabul ettiğini bildirmelidir. Dmarcian, Valimail veya parsedmarc gibi araçlar bu XML'leri okunabilir tablolara dönüştürür.
DMARC RFC 7489'a göre ana alan adının politikası alt alan adlarına da uygulanır; ancak bunu sp= etiketiyle ayrıca belirleyebilirsiniz. Örneğin sp=none ekleyerek alt alan adları için politikayı gevşetebilirsiniz. Alt alan adı için ayrı bir _dmarc TXT kaydı tanımlarsanız bu, üst alan adı politikasını geçersiz kılar.
Büyük ESP'lerin (Email Service Provider) çoğu DKIM imzalamayı destekler; ancak bazıları varsayılan olarak kendi alan adlarını imzalar. Connect365 dahil kurumsal platformlar, müşteriye özel DKIM seçicileri sağlar. Platforma giriş yaptıktan sonra "Alan Adı Doğrulama" veya "Gönderim Ayarları" bölümünden size verilen seçici ve ortak anahtarı DNS'e eklemeniz gerekir.
Teşhis için önerilen araçlar şunlardır: MXToolbox (DNS ve header analizi), Mail Tester (test gönderimiyle SPF/DKIM/DMARC puanı), Google Admin Toolbox — Check MX, Microsoft Remote Connectivity Analyzer ve DMARC Analyzer by dmarcian. Gelişmiş analiz için açık kaynak araçlardan parsedmarc (Python) ve dkimpy kullanılabilir.
Reklamsız, KVKK uyumlu; kurulum ve geçiş ücretsiz, mailleri biz taşırız.
Kurulum + migrasyon ücretsiz. KVKK uyumlu, Türkiye'de barındırma. 7/24 Türkçe destek.
Kampanya 30 Haziran'a kadar geçerlidir.