RehberlerKimlik doğrulama

SPF ve DKIM geçtiği halde DMARC başarısız

İki kontrol de pass diyor, DMARC yine de fail diyor. Neden, From (Kimden) adresinizle eşleşmeyen bir alan adıdır. Tek bir test e-postası hangisi olduğunu gösterir; çözüm de e-postayı gönderen tarafta yapılacak bir ayardır.

Güncelleme: 5 Ekim 2026Okuma süresi: 9 dk

Kısaca

DMARC yalnızca SPF veya DKIM, From adresinizdeki alan adı için geçerse geçer. Sağlayıcınızın alan adı için alınmış bir pass sayılmaz.
Gönderilmiş bir mesajı Gmail’de Show original (Orijinali göster) ile açın ve Authentication-Results üstbilgisindeki smtp.mailfrom, header.i ve header.from değerlerini karşılaştırın.
Önce DKIM’i düzeltin: Sizin adınıza gönderim yapan her hizmette kendi alan adınızla imzalamayı açın. DKIM imzası yönlendirmeden sağ çıkar, SPF çıkmaz.
Varsayılan ayarda bir alt alan adı yeterince yakındır. DMARC kaydınız adkim=s veya aspf=s içeriyorsa değildir.
Isıtma hizalamayı onarmaz. Isıtma e-postaları posta kutunuz üzerinden gönderilir ve onunla birlikte başarısız olur.

DMARC, SPF ve DKIM’in geçip geçmediğini sormaz. Bunlardan birinin From (Kimden) adresinizdeki alan adı için geçip geçmediğini sorar. SPF sağlayıcınızın geri dönüş (bounce) alan adı için, DKIM de sağlayıcınızın imzalama alan adı için geçtiyse iki satır da “pass” der, DMARC ise yine “fail” der. Çözüm gönderen taraftadır: Ona sizin alan adınızla imzalatın veya sizin alan adınızda bir geri dönüş adresi kullanın. İkisinden biri yeterlidir.

Bu eşleşmenin adı hizalamadır (alignment). DMARC’ın, bir DNS kontrol aracının göremediği kısmıdır. E-postalarınızın hizalı olup olmadığı ancak gerçekten gönderilmiş bir mesajda görünür. Bu sayfa böyle bir mesajın nasıl okunacağını gösterir.

Her e-postayla birlikte üç alan adı yolculuk eder

Bir e-posta, alan adınızı en fazla üç yerde taşır. Her kontrol farklı birine bakar.

Bir rıhtımda yan yana: zarf amblemli lacivert bir flama, pirinç etiketli bir posta çuvalı ve mum mühürlü bir mektup; mühür flamadaki amblemi tekrarlıyor, etiket tekrarlamıyor — Flama From satırıdır, posta çuvalındaki etiket Return-Path’tir, mum mühür DKIM imzasıdır. DMARC, etiketin veya mührün flamayla eşleşmesini ister.

Nerede	Diğer adları	Kim bakar
Okurunuzun gördüğü From satırı	Header From, `header.from`	DMARC. Diğer ikisinin ölçütüdür.
Return-Path	Zarf göndereni (envelope sender), MAIL FROM, geri dönüş adresi (bounce address), `smtp.mailfrom`	SPF. Gönderen sunucunun bu alan adını kullanmasına izin verilip verilmediğini kontrol eder.
DKIM-Signature üstbilgisindeki `d=` değeri	İmzalama alan adı, `header.d` veya `header.i`	DKIM. Bu alan adının imzasının geçerli olup olmadığını kontrol eder.

SPF (RFC 7208) ve DKIM (RFC 6376) birer dar soruya yanıt verir ve iki soru da From satırınızdan söz etmez. Bir bülten hizmeti kendi geri dönüş alan adı için SPF’den geçebilir ve kendi anahtarıyla imzalayabilir; mesaj yine de sizden geldiğini iddia edebilir. DMARC bu boşluğu kapatır. Mayıs 2026’dan beri DMARC standardı olan RFC 9989, bir sonucu yalnızca arkasındaki alan adı From alan adıyla eşleşiyorsa kabul eder ve DKIM için gerekçeyi tek cümleyle verir:

DMARC, Tanımlayıcı Hizalamasının DKIM ile Doğrulanmış Tanımlayıcıya uygulanmasını gerektirir; çünkü bir mesaj herhangi bir alan adının, hatta kötü niyetli birinin kullandığı bir alan adının bile geçerli imzasını taşıyabilir.

Aynısı SPF için de geçerlidir, çünkü herkes sahibi olduğu bir alan adı için SPF kaydı yayımlayabilir. Dolayısıyla kural şudur: SPF geçerse ve alan adı hizalıysa ya da DKIM geçerse ve alan adı hizalıysa DMARC geçer.

Uyuşmazlığı gerçek bir mesajda bulun

Gerçek e-postalarınızın gönderildiği biçimde gönderilmiş tek bir e-postaya ve onu alacak bir Gmail adresine ihtiyacınız var.

Söz konusu posta kutusundan veya araçtan, açabildiğiniz bir Gmail adresine bir mesaj gönderin.
Mesajı bilgisayarda Gmail’de açın. Reply (Yanıtla) düğmesinin yanındaki More (Diğer) seçeneğini, ardından Show original (Orijinali göster) seçeneğini tıklayın. Google aynı adımları Trace an email with its full header (bir e-postayı tam üstbilgisiyle izleme) sayfasında anlatır.
Alıcı sunucunun kontrollerinin sonucunu not ettiği Authentication-Results üstbilgisini bulun (RFC 8601). Üç değeri karşılaştırın: smtp.mailfrom= ifadesinden sonraki alan adı, header.i=@ ifadesinden sonraki alan adı (bazı alıcılar header.d= yazar) ve header.from= ifadesinden sonraki alan adı. E-posta üstbilgileri nasıl okunur rehberi o satırı adım adım ele alır.

SPF ve DKIM’den geçen ama DMARC’ta başarısız olan bir mesajın kalıbı budur. Üstbilgi kısaltılmıştır ve örnek alan adları kullanır:

From: anna@example.com
Return-Path: <bounces@send.vendor-mail.example>

Authentication-Results: mx.google.com;
       dkim=pass header.i=@vendor-mail.example header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=fail header.from=example.com

Aşağıdan yukarı okuyun. From alan adı example.com olarak görünüyor. SPF geçti, ama send.vendor-mail.example için. DKIM geçti, ama imza vendor-mail.example alan adına ait. Hiçbiri example.com değil; dolayısıyla From satırındaki ada kefil olan hiçbir şey yok.

Hizmet sizin alan adınızla imzalayacak biçimde kurulduktan sonra aynı mesaj şöyle görünür:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=pass header.from=example.com

SPF hâlâ hizmet sağlayıcıyı gösteriyor. Sorun değil. DKIM artık eşleşiyor ve DMARC’ın ihtiyacı olan tek şey hizalı bir pass sonucudur.

Ne kadar yakın yeterince yakındır: gevşek ve katı

İki alan adının aynı olması gerekmez. Varsayılan olarak hizalama gevşektir (relaxed): İkisinin de, standardın kuruluş alan adı dediği aynı tescilli alan adına ait olması yeterlidir. Katı (strict) hizalama tam eşleşme ister. Seçimi DMARC kaydınızdaki, DKIM için adkim ve SPF için aspf etiketleriyle yaparsınız.

SPF veya DKIM’in geçtiği alan adı	From alan adı	Gevşek (varsayılan)	Katı
`example.com`	`example.com`	Hizalı	Hizalı
`mail.example.com`	`example.com`	Hizalı	Hizalı değil
`example.com`	`news.example.com`	Hizalı	Hizalı değil
`vendor-mail.example`	`example.com`	Hizalı değil	Hizalı değil

Standart, “neredeyse tüm Alan Adı Sahiplerinin gevşek hizalamayı ihtiyaçlarını karşılamaya yeterli bulduğunu” belirtir. Yine de kendi kaydınızı kontrol edin. Google’ın Set up DMARC sayfasının başındaki örnek kayıt adkim=s; aspf=s ile biter; yani oradan kopyalanan bir kayıt katıdır. Sizinkinde bu iki etiket varsa ve bir araç bir alt alan adından gönderiyorsa bunları kaldırın. Google’ın kendisi o sayfada katı hizalamanın “ilişkili alt alan adlarından gelen mesajların reddedilmesine veya spama gönderilmesine yol açabileceği” konusunda uyarır.

Uyuşmazlık çoğunlukla nereden gelir

Kendi sunucularından gönderim yapan bir hizmet

Bülten platformları, CRM’ler, faturalama araçları ve destek masası yazılımları e-postalarınızı kendi altyapılarından gönderir. Siz alan adınızı bağlayana kadar genellikle kendi alan adlarında bir geri dönüş adresi kullanır ve kendi anahtarlarıyla imzalarlar. Amazon’un belgeleri SPF hizalamasının burada neden nadir olduğunu açıkça söyler: Return-Path “sağlayıcının (SES) kendisine ait bir adres kullanarak izlediği geri dönüşler ve şikâyetler için kullanılır” (Amazon SES). Bunu düzelten ayarın her hizmette farklı bir adı vardır ve iş sizin tarafınızdaki birkaç DNS kaydıyla biter.

Hizmet	Alan adınızı bağlamadan önce	Aranacak ayar
Twilio SendGrid	E-posta “via sendgrid.net” (sendgrid.net aracılığıyla) gönderilmiş olarak gösterilir.	Domain authentication: bir geri dönüş alt alan adı ve iki DKIM anahtarı için CNAME kayıtları.
Amazon SES	Return-Path, `amazonses.com` alan adının bir alt alan adıdır.	İmza için Easy DKIM, SPF için custom MAIL FROM domain (özel MAIL FROM alan adı).
Mailchimp	Alan adı doğrulanmıştır (verified) ama kimlik doğrulaması yapılmamıştır (authenticated).	Email domain authentication: DKIM için iki CNAME kaydı.

Bunlar, Ekim 2026 itibarıyla firmaların kendi anlatımlarıdır. Diğer hizmetler de benzer biçimde çalışır. Yardım sayfalarında “authenticate domain”, “custom DKIM” veya “branded sending domain” ifadelerini arayın.

E-posta sağlayıcınız kendi alan adıyla imzalıyor veya hiç imzalamıyor

Kendi alan adınızdaki bir posta kutusunda Return-Path normalde kendi adresinizdir; dolayısıyla SPF kaydınız sağlayıcıyı listeler listelemez SPF hizalanır. Bunu smtp.mailfrom= ifadesinden sonraki değer gösterir. Açılması gereken bir ayarı olan kısım DKIM’dir.

Google Workspace. Siz alan adınız için DKIM’i açana kadar Google kendi alan adlarından biriyle imzalamıştır. Google’ın yardım sayfasının önceki bir sürümü, Gmail’in o durumda “şu varsayılan DKIM alan adı anahtarıyla: d=*.gappssmtp.com” imzaladığını söylüyordu. Güncel sayfa artık alan adını vermiyor; bu yüzden kendi üstbilginize bakın: gappssmtp.com ile biten bir header.i, anahtarınızın etkin olmadığı anlamına gelir. Anahtarı Admin console’da Apps, Google Workspace, Gmail, Authenticate email (e-postanın kimliğini doğrula) altında oluşturun, gösterdiği TXT kaydını ekleyin, ardından Start authentication (kimlik doğrulamayı başlat) düğmesini tıklayın (Set up DKIM).
Microsoft 365. Microsoft’un Ağustos 2026’da güncellenen belgeleri şunu belirtir: “Şu anda özel alan adlarından giden e-postalar için DKIM imzalaması yapılmamaktadır”. İki CNAME kaydı yayımlar ve imzalamayı Defender portalında etkinleştirirsiniz (How to use DKIM for email in your custom domain).

Bir DKIM anahtarı için eklediğiniz kayıt her zaman _domainkey altında, sağlayıcının seçtiği bir adla durur. Google Workspace için, anahtar kısaltılmış halde şöyle görünür:

google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Posta kutunuza bağlanan ve onun üzerinden gönderen bir araç kendi imzasını eklemez. Böyle bir araçtan gelen e-posta, elle yazdığınız e-postayla tıpatıp aynı görünür; dolayısıyla çözüm araçta değil, e-posta sağlayıcısındadır.

Mesaj yönlendirildi

Bir alıcı e-postanızı otomatik olarak yönlendirdiğinde e-posta, SPF kaydınızın listelemediği bir sunucudan ulaşır. SPF başarısız olur ya da yönlendirenin alan adı için geçer. DKIM imzası, kimse mesajı değiştirmediği sürece yolculuktan sağ çıkar. Altbilgi veya konu etiketi ekleyen e-posta listeleri imzayı da bozar. Bunu kendi tarafınızdan onaramazsınız. Google’ın gönderen SSS’si Gmail için “yönlendirilen veya e-posta listesinden gelen mesajlarda DMARC hizalamasının gerekmediğini” söyler. DKIM’i hizalı tutmanın ve yalnızca SPF’ye güvenmemenin nedeni budur.

Mühürlü bir mektup bir posta teknesinden diğerine geçiyor; her teknenin kendi posta çuvalı ve etiketi var, mektubun üzerindeki mum mühür bozulmamış — Yönlendirme posta çuvalını ve etiketini değiştirir. Mektubun üzerindeki mühür sağlam kalır.

Bu sizin e-postanız değil

DMARC raporlarınız hiç kullanmadığınız sunuculardan gelen başarısızlıklar gösteriyorsa biri sizin adresinizle gönderim yapıyor olabilir. Bu mesajların başarısız olması gerekir. Düzeltilecek bir şey yoktur; bunlar ileride daha katı bir politikanın gerekçesidir.

Önce DKIM’i, sonra SPF’yi düzeltin

İkisinden biri size pass kazandırır. Sahip olunması daha iyi olan DKIM’dir, çünkü mesajla birlikte yolculuk eder. M3AAWG en iyi uygulamaları bunu kural olarak koyar: “Giden tüm e-postaları, RFC5322.From üstbilgisinin alan adıyla hizalanan bir DKIM anahtarıyla imzalayın.” RFC 9989 ikisinin birlikte kullanılmasını önerir.

Alan adınız adına gönderim yapan her şeyi listeleyin. Posta kutuları, bülten aracı, CRM, faturalar, web sitenizdeki iletişim formu. Unuttuklarınızın adını DMARC raporlarınız verir.
Her birini test edin: Yukarıdaki üstbilgi kontrolünü yapın ve iki alan adından hangisinin sizin olmadığını not edin.
Sizin alan adınızla imzalamayı açın: header.i başka bir ad gösterdiği her yerde bunu yapın ve hizmetin verdiği kayıtları yayımlayın. DNS sağlayıcınız kabul ediyorsa 2048 bitlik bir anahtar seçin. Gmail en az 1024 bit şart koşar ve 2048 bit önerir.
Özel bir geri dönüş alan adı ayarlayın: Hizmet sunuyorsa bounce.example.com gibi bir alt alan adında. Bu, SPF’yi de hizalar.
Testi yeniden gönderin ve dmarc=pass arayın. DNS değişiklikleri biraz zaman alabilir. Google, yeni bir DKIM anahtarının çalışmaya başlaması için 48 saate kadar süre tanır.

İşe yaramayan şey, hizmet sağlayıcıyı kendi kayıtlarınıza eklemektir. Return-Path hizmet sağlayıcının alan adındaysa SPF kaydınıza onun için eklenen bir include: hiçbir şeyi değiştirmez; çünkü SPF sizin değil, o alan adının kaydına bakar. Bir DMARC kaydı güvenilen üçüncü tarafları da listeleyemez. Standart bunun için “genel kabul görmüş bir mekanizma olmadığını” söyler.

Üstbilgi dmarc=pass gösteriyor ve mesaj yine de spama düşüyorsa neden artık kimlik doğrulama değildir. SPF, DKIM ve DMARC başarılı, ama e-posta yine de spama düşüyor rehberi oradan devam eder.

Politikanız p=none iken başarısız bir DMARC’ın bedeli

p=none ile alıcılardan bir başarısızlıkta işlem yapmamalarını istersiniz; dolayısıyla politikanız yüzünden hiçbir şey reddedilmez. Yine de iki biçimde aleyhinize işler.

Toplu gönderen kuralları. Gmail, Yahoo ve Outlook.com toplu gönderenlerden hizalı e-posta ister; Gmail ve Outlook.com için bu, günde 5.000 mesajdan itibaren demektir. Google’ın gönderen SSS’si, From üstbilgisi “kimliği doğrulanmış SPF veya DKIM kuruluş alan adlarından hiçbiriyle hizalı olmayan” e-postalar için 4.7.32 geçici hatasını listeler ve sonuç olarak “geçici veya kalıcı hata kodlarını ya da spam klasörüne gönderilmeyi” sayar.
Bir sonraki adımı engeller. p=quarantine veya p=reject politikasına geçtiğiniz anda kendi hizalanmamış her mesajınız spam sayılacak veya reddedilecektir. Gmail’de geri dönen ileti şöyle der: “Unauthenticated email from domain-name is not accepted due to domain's DMARC policy”, hata 5.7.26 (Troubleshoot DMARC issues).

Hiç DMARC kaydınız yoksa eklenecek kayıtla başlayın. Bu kayıt, tüm gönderenleriniz için hizalamayı tek seferde gösteren raporları da açar.

Isıtma burada ne yapabilir, ne yapamaz

Isıtma hizalamayı onarmaz. WarmupBay posta kutunuza bağlanır ve ondan gönderir; dolayısıyla ısıtma e-postaları, sağlayıcınız tarafından tam olarak kendi yazdığınız e-postalar gibi gönderilir ve imzalanır. Posta kutunuz DMARC’ta başarısızsa onlar da onunla birlikte başarısız olur. Önce kayıtları düzeltin.

WarmupBay öncesindeki ve sonrasındaki kısımda yardımcı olur. Bir posta kutusu bağladığınızda alan adı için SPF, DKIM ve DMARC’ı kontrol eder ve 72 saat sonra hâlâ eksiklerse ısıtmayı durdurur. Kayıtlar yerine oturduğunda posta kutunuz ortak bir havuzdaki diğerleriyle günde birkaç e-posta alışverişi yapar ve panel bunların nereye düştüğünü gösterir: gelen kutusu, bir Gmail sekmesi veya spam; Google ve diğer sağlayıcılar için ayrı ayrı. Bülten aracınızdan veya CRM’inizden gelen e-postaları test etmez, çünkü onlar posta kutunuzdan hiç geçmez; Microsoft 365 veya Outlook.com posta kutularını da henüz bağlayamaz. Günde 10 ısıtma e-postası için ücretsizdir. Üstbilgi dmarc=pass gösterdiğinde posta kutunuzu bağlayın.

Sık sorulan sorular

SPF geçiyor ve hizalı, DKIM hizalı değil. Bu yeterli mi?

DMARC için evet. Hizalı tek bir pass yeterlidir. Bir alıcı e-postanızı yönlendirdiğinde yetmez hale gelir, çünkü o zaman SPF artık eşleşmez. Google ayrıca gönderen SSS’sinde hem SPF hem DKIM ile hizalamanın büyük olasılıkla bir şart haline geleceğini yazar; bu yüzden alan adınız için DKIM’i yine de kurun.

DMARC neden bazı alıcılarda başarısız oluyor, bazılarında geçiyor?

Çünkü e-posta onlara farklı yollardan veya farklı gönderenlerden ulaşır. Başka bir posta kutusuna yönlendirme yapan bir alıcı veya bir e-posta listesi, SPF’nin ve bazen DKIM’in gördüğünü değiştirir. Birkaç gönderim hizmetinden henüz kurulmamış biri de olabilir. Toplu raporlar sonuçları gönderen sunucuya göre listeler ve hangi durumun söz konusu olduğunu gösterir.

Reply-To adresi DMARC’ta rol oynar mı?

Hayır. DMARC yalnızca From üstbilgisindeki alan adını kullanır. Reply-To adresi, görünen ad ve Sender üstbilgisi kontrolün parçası değildir.

Üstbilgileri açmadan hizalama sorunlarını nasıl görürüm?

DMARC toplu raporlarında. Her kayıtta, dkim ve spf sonucu içeren bir policy_evaluated bloğu vardır; bunlar hizalama testinden sonraki sonuçlardır. Altındaki auth_results bloğu ham sonuçları ve bunların hangi alan adları için olduğunu gösterir. Değerlendirilmiş bir fail’in yanındaki ham bir pass, tam olarak bu sayfadaki durumdur. Raporları, DMARC kaydınıza bir rua adresi ekleyerek alırsınız.

Üstbilgide dkim=fail veya dkim=neutral yazıyor. Aynı sorun mu?

Hayır. O zaman imzanın kendisi doğrulanamamıştır; bu farklı bir hatadır. Metinde body hash did not verify yazıyorsa Google’ın sorun giderme sayfası nedeni söyler: Mesaj imzalandıktan sonra değiştirilmiştir; örneğin altbilgi ekleyen bir ağ geçidi tarafından. Hizalama ise geçerli olan ama başka bir alan adına ait bir imzayla ilgilidir.

Benim adıma gönderim yapan her hizmet için ayrı bir DKIM anahtarına ihtiyacım var mı?

Uygulamada evet. Her hizmet kendi anahtarıyla imzalar ve onu alan adınızda _domainkey altında kendi seçici (selector) adıyla yayımlar; böylece birkaç anahtar çakışmadan yan yana durur. Bu, bir alan adının yalnızca tek bir kaydı olabildiği SPF’den farklıdır.