No DMARC record found: alan adınızda eksik olan tek satır

Kısaca

• Bu mesaj, _dmarc.yourdomain.com adresinde TXT kaydı olmadığı anlamına gelir. Posta sunucunuz bozuk değildir.
• Host adı _dmarc ve değeri v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com olan tek bir TXT kaydı ekleyin. p=none ile teslim tam olarak eskisi gibi kalır.
• Gmail, Yahoo ve Outlook.com bu kaydı yalnızca toplu gönderenlerden şart koşar. Yine de ekleyin: Google bütün bir alan adını sayar ve toplu gönderen statüsünü hiç kaldırmaz; raporlar da ancak bir kayıt var olduğunda başlar.
• Bir kontrol aracı hâlâ hiçbir şey bulamıyorsa yanlış DNS sağlayıcısına, iki kez yazılmış host adına veya iki DMARC kaydına bakın. İki kayıt birbirini geçersiz kılar.
• Standart Mayıs 2026’da RFC 9989 ile değişti: pct kalktı, t ve np yeni. Google’ın yardım sayfası Ekim 2026 itibarıyla hâlâ pct’yi anlatıyor.

“No DMARC record found” (DMARC kaydı bulunamadı), bir kontrol aracının DNS’e _dmarc.yourdomain.com adresindeki TXT kaydını sorduğu ve yanıt alamadığı anlamına gelir. Posta sunucunuzda bozuk bir şey yoktur. Çözüm, host adı _dmarc ve değeri v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com olan tek bir TXT kaydıdır. p=none ile e-postalarınız tam olarak eskisi gibi teslim edilir. Yalnızca alıcılara katıldığınızı bildirirsiniz ve rapor almaya başlarsınız.

DMARC, SPF ve DKIM’in yanındaki üç e-posta kaydının üçüncüsüdür. SPF, alan adınız adına gönderim yapabilecek sunucuları listeler. DKIM her mesajı imzalar. DMARC ise alıcıya, ikisinden hiçbiri From (Kimden) adresinizdeki alan adına kefil olmadığında ne yapacağını ve günlük özeti nereye göndereceğini söyler. Mayıs 2026’dan beri, eski RFC 7489’un yerini alan RFC 9989 ile tanımlanıyor. Birçok rehber hâlâ eski sürümü anlatıyor; Ekim 2026 itibarıyla Google’ın yardım sayfası da öyle.

Eklenecek kayıt

Alan adınızın DNS’inin yönetildiği yerde oturum açın. Bu, ad sunucularınızın işaret ettiği şirkettir; her zaman alan adını satın aldığınız şirket olmayabilir. Şu değerlerle yeni bir kayıt ekleyin:

Bir bölge dosyasında satır olarak yazıldığında tamamlanmış kayıt şöyle görünür:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

example.com yerine kendi alan adınızı yazın. Üç bölüm şunları yapar:

• v=DMARC1 satırı bir DMARC kaydı olarak işaretler. DMARC1 büyük harflerle yazılmış halde en başta gelmelidir. Gelmezse alıcılar kaydın tamamını yok sayar.
• p=none politikadır: E-postalarıma her zamanki gibi davranın. Bu kayıt yüzünden hiçbir şey engellenmez veya spama taşınmaz.
• rua=mailto:… günlük raporların gideceği adrestir. Kaydı yayımlamadan önce bu adresi veya size yönlendiren bir takma adı oluşturun.

Google aynı üç alanı Set up DMARC (DMARC’ı kurma) sayfasında listeler. Ayrıca DMARC’ı eklemeden önce SPF ve DKIM’in 48 saattir çalışıyor olmasını ister. Kontrol aracınız o ikisini de işaretliyorsa önce onları düzeltin.

İşe yaradığını nasıl kontrol edersiniz

DNS’e kendiniz sorun. macOS veya Linux’ta bir terminal açın ve dig kullanın. Windows’ta nslookup kullanın.

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com

Kayıt yayındaysa satır tırnak içinde geri gelir. Google’ın kendi alan adı 5 Ekim 2026’da şu yanıtı verdi:

$ dig +short TXT _dmarc.google.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

Boş bir yanıt, kaydın henüz orada olmadığı veya alıcıların onu aradığı yerde olmadığı anlamına gelir. Kendi sorgunuz satırı gösterdiğinde, size bu mesajı veren kontrol aracını yeniden çalıştırın. Örneğin MXToolbox sorunu “No DMARC Record found” diye ifade eder ve “your domain does not have a published DMARC record” (alan adınızın yayımlanmış bir DMARC kaydı yok) diye açıklar.

DMARC kaydının her bölümü ne anlama gelir

Bir kayıt, noktalı virgülle ayrılmış tag=value (etiket=değer) çiftlerinden oluşan bir listedir. Standartta yalnızca v zorunludur ve ilk sırada olmalıdır. p etiketini ikinci sıraya koyun: Google’ın yardım sayfası “v ve p etiketleri ilk sırada listelenmelidir” der ve eski standart da aynı sırayı bekliyordu. RFC 9989, bölüm 4.7 etiketleri şunlardır:

Eski kayıtlar çoğu zaman pct=100 ile biter. Bu etiket, bir politikayı başarısız olan e-postaların bir bölümüne uygulamak için düşünülmüştü. RFC 9989 onu rf ve ri ile birlikte kaldırdı ve gerekçesini verir:

Uygulama deneyimi, belirtilen değer 0 veya 100 (varsayılan) olmadıkça “pct” etiketinin genellikle doğru uygulanmadığını ve diğer değerlerdeki hataların bir uygulamadan ötekine büyük farklılıklar gösterdiğini ortaya koydu.

Alıcılar bilmedikleri etiketleri yok saymak zorundadır; dolayısıyla eski bir pct=100 zarar vermez. yahoo.com ve microsoft.com kayıtları 5 Ekim 2026’da hâlâ onu taşıyordu; Google’ın yardım sayfası da kademeli geçiş için hâlâ pct öneriyor. Yeni bir kayıtta onu yazmayın.

Günde yalnızca birkaç e-posta gönderiyorsanız DMARC gerekli mi?

Büyük e-posta sağlayıcılarının yayımlanmış kurallarına göre DMARC kaydı, toplu gönderim yaptığınızda zorunludur. Bunun altında bir öneridir.

Kaynaklar, tümü Ekim 2026 itibarıyla, Google’ın Email sender guidelines, Yahoo’nun Sender Best Practices sayfaları ve Microsoft’un yüksek hacimli gönderenlere yönelik duyurusudur. Tek bir posta kutusundan günde otuz e-posta gönderiyorsanız hiçbiri bu kaydı şart koşmaz. Yine de onu şimdi eklemek için üç neden var.

• Eşik alan adı başına sayılır ve sıfırlanmaz. Google, alt alan adları dahil aynı birincil alan adından kişisel Gmail hesaplarına giden tüm mesajları toplar. Gönderen SSS’si şöyle der: “Yukarıdaki ölçütleri en az bir kez karşılayan gönderenler kalıcı olarak toplu gönderen sayılır.”
• Google da Yahoo da bunu herkese önerir. Google “alan adlarınız için her zaman SPF, DKIM ve DMARC kurmanızı öneririz” diye yazar. Yahoo “tüm gönderenleri, e-posta gönderen her alan adı için bir DMARC politikası yayımlamaya kuvvetle teşvik eder”.
• Kayıt olmadan rapor alamazsınız. From satırında alan adınız bulunan e-postaları hangi sunucuların gönderdiğini raporlar sayesinde görürsünüz; kendi araçlarınızı da yabancıları da.

Toplu gönderenler için eksik kaydın sonuçları vardır. Google’ın gönderen SSS’si bunun için 4.7.31 geçici hatasını listeler: “gönderen alan adının DMARC kaydı yok veya DMARC kaydı bir DMARC politikası belirtmiyor”. Aynı sayfa, Kasım 2025’ten beri şartları karşılamayan e-postaların “geçici ve kalıcı retlerle” karşılaştığını söyler.

Kaydı eklediniz, kontrol aracı hâlâ bir şey bulamıyor mu?

O zaman neden çoğunlukla şunlardan biridir. Yukarıdaki dig sorgusuyla bunları sırayla kontrol edin.

• DNS’i yanlış yerde düzenlediniz. Ad sunucularınız alan adı kayıt şirketinizden farklı bir şirketteyse kayıt şirketinde girilen kayıtlar hiç sorgulanmaz. dig +short NS example.com, alan adınız adına kimin yanıt verdiğini gösterir.
• Host adı yanlış. Kayıt doğrudan example.com üzerinde veya yukarıda anlatıldığı gibi iki kez yazılmış bir adın üzerinde duruyor. Alıcılar yalnızca _dmarc.example.com adresini sorar.
• İki DMARC kaydı var. Standart burada katıdır: “Tek bir hedef için birden fazla DMARC Politika Kaydı dönerse hepsi atılır.” Bunları tek bir kayıtta birleştirin. İki rapor adresi, virgülle ayrılarak tek bir rua içine yazılır.
• İlk etiket tam olarak v=DMARC1 değil. Küçük harf, DMARC 1 gibi bir yazım hatası veya önüne yazılmış bir p= kaydı geçersiz kılar.
• Kayıt türü TXT değil veya değer bir belgeden kıvrık tırnak işaretleriyle yapıştırılmış. Değeri düz metin olarak yazın; DNS sağlayıcınızın yardım sayfası istemedikçe tırnak kullanmayın.
• Eski bir yanıt hâlâ önbellekte. Çözümleyiciler “böyle bir kayıt yok” yanıtını bir süre hatırlar. Kendi ad sunucularınızdan birine, adını sorguya ekleyerek doğrudan sorun; örneğin dig +short TXT _dmarc.example.com @ns1.example.net. Kayıt orada görünüyorsa kontrol araçları da arkadan gelir.

Raporlar nereye gider ve onlarla ne yapılır

From satırında alan adınız bulunan e-posta almış her alıcı, rua adresine bir rapor gönderir. Google’ın About DMARC reports (DMARC raporları hakkında) sayfasına göre bunlar “genellikle günde bir kez e-postayla gönderilir”. Rapor, bir e-postaya eklenmiş, çoğunlukla sıkıştırılmış bir XML dosyasıdır. Biçimi RFC 9990 tanımlar.

Google, büyük kuruluşların “günde yüzlerce, hatta binlerce rapor alabileceği” konusunda uyarır ve bir grup veya bu işe ayrılmış bir posta kutusu önerir. Sayı ne kadar gönderdiğinize ve kaç alan adına gönderdiğinize bağlıdır; dolayısıyla bir iki posta kutusu çok daha azını üretir. Kendi klasörüne yönlendiren bir filtresi olan dmarc@ gibi bir takma ad yeterlidir.

Adres, kayıtla aynı alan adında olmalıdır. Raporları başka bir yerde istiyorsanız diğer alan adının kendi kaydını yayımlayarak bunu kabul etmesi gerekir. Bu kayıt olmadan alıcılar adresi yok saymak zorundadır (RFC 9990, bölüm 4).

example.com._report._dmarc.otherdomain.net.  IN  TXT  "v=DMARC1;"

Ücretsiz bir Gmail adresinin rapor adresi olarak işe yaramamasının nedeni budur: 5 Ekim 2026’da kontrol ettiğimizde gmail.com böyle bir kayıt yayımlamıyordu.

Dosyada her record bloğu bir gönderen sunucuyu temsil eder: IP adresi, mesaj sayısı ve policy_evaluated altında DKIM ile SPF’nin alan adınız için geçip geçmediği. İki şey ararsınız. fail gösteren tanıdığınız sunucuların düzeltilmesi gerekir; nasıl yapılacağını SPF ve DKIM geçtiği halde DMARC başarısız rehberi açıklar. Tanımadığınız sunucular ya unuttuğunuz bir araçtır ya da adınızı kullanan biridir.

p=none’dan sonra: politika ne zaman sıkılaştırılır

p=none bir izleme modudur. E-posta sağlayıcılarının istediği asgariyi karşılar ve kimsenin adresinizi taklit etmesini engellemez. Bunu yalnızca alıcılardan başarısız e-postaları şüpheli saymalarını isteyen p=quarantine ile onları reddetmelerini isteyen p=reject yapar.

Sıkılaştırmadan önce e-postalarınızın her meşru kaynağının geçmesi gerekir. RFC 9989, bu tür eksiklerin yaptırım uygulamaya yönelik “herhangi bir girişimden önce giderilmesi GEREKTİĞİNİ” ve ne sıklıkta gönderdiğinize bağlı olarak emin olmak için raporların “aylarca sürebileceğini” söyler. Google’ın kademeli geçiş sayfası bir haftalık raporu “genellikle yeterli” bulur. Tek bir posta kutusu ve bir iki araçla Google’ın rakamına daha yakınsınız; yine de aylık fatura gönderiminin ve iletişim formunun da görünmesi için birkaç hafta tanıyın.

Adımın kendisi konusunda iki kaynak ayrışır. Google hâlâ p=quarantine; pct=5 ile başlayıp sayıyı yükseltmeyi önerir. Standart pct etiketini bırakmıştır ve onun yerine şunu sunar:

v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com

t=y, alıcılardan başarısızlıkları şimdilik bir düzey aşağıda, yani none olarak ele almalarını ister. Raporlar temiz kalırsa t=y etiketini kaldırın. Şunu bilin: Etiketi tanımayan bir alıcı onu yok sayar ve quarantine politikasını tam olarak uygular; Google’ın sayfaları da Ekim 2026 itibarıyla t etiketinden söz etmez. Daha katı bir politika henüz düzeltemediğiniz e-postaları vuracaksa p=none üzerinde kalın.

WarmupBay burada ne yapar

Bir posta kutusu bağladığınızda WarmupBay onun alan adı için SPF, DKIM ve DMARC’ı kontrol eder. DMARC kaydı eksikse size kopyalamanız için hazır bir kayıt gösterir. Isıtmayı yine de başlatabilirsiniz. Kayıtlar 72 saat sonra hâlâ eksikse ısıtma durur.

WarmupBay kaydı sizin yerinize ekleyemez, çünkü DNS’iniz size aittir; DMARC raporlarını toplamaz ve okumaz. Yaptığı şey kayıtlardan sonraki adımdır: Posta kutunuz ortak bir havuzdaki diğer posta kutularıyla günde birkaç e-posta alışverişi yapar; üçle başlar ve her gün bir artar, böylece gönderim etkinliği kademeli olarak oluşur. Günde 10 e-posta için ücretsizdir. Kontrolün ve ısıtmanın neleri kapsadığına bakın veya kayıt yerine oturduğunda posta kutunuzu bağlayın.

Sık sorulan sorular

example.com üzerindeki bir DMARC kaydı news.example.com gibi alt alan adlarını da kapsar mı?

Evet. Alıcı önce _dmarc.news.example.com adresinde bir kayıt sorar. Yoksa kuruluş alan adının, yani example.com’un kaydına döner. Alt alan adına uygulanan politika, ayarladıysanız sp içindeki, aksi halde p içindeki politikadır.

v=DMARC1; p=none kaydını rua adresi olmadan yayımlayabilir miyim?

Evet. Bu geçerli bir kayıttır ve yayımlanmış bir politika sayılır. Rapor almazsınız; dolayısıyla kendi e-postalarınızın geçip geçmediğini veya alan adınızı başka kimin kullandığını görmezsiniz. Yahoo çalışan bir rua adresini kuvvetle önerir, Google da her zaman bir tane eklemenizi tavsiye eder.

Yalnızca soğuk e-posta için kullandığım ikinci bir alan adı için DMARC kaydına ihtiyacım var mı?

Evet. Alıcılar her mesajın From (Kimden) adresindeki alan adına bakar; dolayısıyla ana alan adınızdaki bir kayıt farklı bir alan adını kapsamaz. İkinci alan adında aynı satırı kullanın. Raporları ana alan adınızdaki bir adrese gidecekse ana alan adının, “Raporlar nereye gider” başlığı altında anlatılan yetkilendirme kaydını yayımlaması gerekir.

Hiç e-posta göndermeyen bir alan adı ne yayımlamalı?

Katı ikiliyi. M3AAWG, hiç e-posta göndermeyen alan adları için v=spf1 -all SPF kaydını ve p=reject içeren bir DMARC kaydını önerir; böylece kimse onları bir From adresinde kullanamaz. DMARC için bu, _dmarc üzerindeki v=DMARC1; p=reject satırıdır.

p=none e-postalarım için p=quarantine veya p=reject’ten daha mı kötü?

Gmail, Yahoo ve Outlook.com’un yayımlanmış gönderen kuralları en az p=none ister, daha katısını istemez. Politika, DMARC’tan geçemeyen e-postalara ne olacağını belirler; sizin adınıza gönderilen sahte e-postalar da buna dahildir. Bir özellik daha fazlasını gerektirir: Mesajlarınızın yanındaki logo olan BIMI, Google’ın yardım sayfasına göre quarantine veya reject şart koşar.

Kaynaklar

1. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), May 2026
2. RFC 9990: DMARC Aggregate Reporting, May 2026
3. Email sender guidelines – Gmail Help
4. Email sender guidelines FAQ – Gmail Help
5. Set up DMARC – Google Workspace Help
6. Recommended DMARC rollout – Google Workspace Help
7. About DMARC reports – Google Workspace Help
8. Troubleshoot DMARC issues – Google Workspace Help
9. Sender Best Practices – Yahoo Sender Hub
10. Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders – Microsoft Community Hub
11. DMARC Record Published – MXToolbox
12. M3AAWG Email Authentication Recommended Best Practices, September 2020 (PDF)
13. M3AAWG Protecting Parked Domains Best Common Practices, December 2015 (PDF)