# Mailskop

> Alan adlarının e-posta güvenliğini (SPF, DKIM, DMARC, BIMI, MTA-STS, DNSSEC)
> tek istekte inceleyen ücretsiz araç. Kinetik Bilişim tarafından yayınlanır.

Tüm sonuçlar herkese açık ve salt-okunurdur; kayıt ya da anahtar gerekmez.
Her sonuç sayfası `Accept: text/markdown` başlığıyla Markdown olarak da sunulur.
Yapılandırılmış çıktı için JSON API ve MCP sunucusu vardır.

**Sohbet asistanları için:** getirme aracınız özel başlık gönderemiyorsa
`https://mailskop.com/tara/{alan}?bicim=md` (Markdown) ya da `?bicim=json` adresini açın.
`/api/` yolu robots.txt'de tarayıcılara kapalıdır; kullanıcı adına çalışan ve
robots.txt'ye uyan getiriciler orayı açamaz. Aracınız yalnızca sohbette geçen
adresleri açabiliyorsa kullanıcıdan tam adresi isteyin, örneğin
https://mailskop.com/tara/kinetikbilisim.net?bicim=md

**Ayırt edici nokta:** değerlendirme RFC 9989 (DMARCbis, Mayıs 2026) esas alınarak
yapılır. `pct`, `ri`, `rf` etiketleri "historic" oldu, standart onları artık tanımlamıyor; `t=y` test modu ve
`np` etiketi doğru yorumlanır; organizasyon alan adı Public Suffix List ile değil
DNS Tree Walk (RFC 9989 §4.10) ile bulunur.

## Araçlar

- [Alan adı incele](https://mailskop.com/tara/{alan}): tam rapor (HTML veya Markdown)
- [JSON API](https://mailskop.com/api/tara?d={alan}): aynı raporun yapılandırılmış hâli
- [SPF zincirinin tamamı](https://mailskop.com/tara/{alan}/spf): include ağacı, sonuna kadar
- [Geniş DKIM taraması](https://mailskop.com/tara/{alan}/dkim): 60+ seçici denenir
- [Karşılaştırma](https://mailskop.com/karsilastir?a={alan1}&b={alan2}): iki alan adı yan yana
- [Header analizi API](https://mailskop.com/yapay-zeka-ve-api): `POST https://mailskop.com/api/baslik` — gövdede ham header; JSON ya da `?bicim=md` ile Markdown. Header saklanmaz
- [MCP sunucusu](https://mailskop.com/mcp): salt-okunur, iki araç (`alan_adi_incele`, `baslik_analizi`)
- [OpenAPI tanımı](https://mailskop.com/openapi.json)
- [Tam metin](https://mailskop.com/llms-full.txt): kalıcı sayfaların tamamı tek dosyada, Markdown
- [Kimlik doğrulama](https://mailskop.com/auth.md): gerekmiyor — anahtar, kayıt ve jeton yok

## Sayfalar

- [Ana sayfa](https://mailskop.com/)
- [Toplu tarama](https://mailskop.com/toplu): liste hâlinde çok sayıda alan adı
- [Karşılaştırma](https://mailskop.com/karsilastir): iki alan adının e-posta güvenliği yan yana
- [SPF sorgulama](https://mailskop.com/spf-sorgulama): Alan adınızın SPF kaydını okuyun: include ağacı, 10 DNS-lookup sınırı, void sayacı, açıkta duran IP blokları ve "all" niteleyicisi. Ücretsiz, kayıt gerekmez.
- [DKIM sorgulama](https://mailskop.com/dkim-sorgulama): DKIM seçicilerinizi arayın, açık anahtarın uzunluğunu ve test/iptal durumunu okuyun. Seçici bilmiyorsanız yaygın seçiciler taranır. Ücretsiz, kayıt gerekmez.
- [DMARC sorgulama](https://mailskop.com/dmarc-sorgulama): Her alan adının DMARC kaydını ücretsiz kontrol edin: politika, hizalama, rapor adresleri ve sözdizimi hataları, RFC 9989’a göre. Sonuç anında, kayıt gerekmez.
- [MX sorgulama](https://mailskop.com/mx-sorgulama): MX kayıtlarınızı, sağlayıcınızı ve önündeki güvenlik geçidini görün; MTA-STS, TLS-RPT ve DANE durumunu okuyun. Ücretsiz, kayıt gerekmez.
- [BIMI sorgulama](https://mailskop.com/bimi-sorgulama): BIMI kaydınızı, logonuzun SVG Tiny PS uyumunu ve VMC/CMC sertifikanızı denetleyin. DMARC ön koşulu da birlikte kontrol edilir.
- [DNSSEC sorgulama](https://mailskop.com/dnssec-sorgulama): Alan adınızda DNSSEC açık mı, DS kaydı üst bölgeye işlenmiş mi, imza zinciri gerçekten doğrulanıyor mu — ölçerek gösterir.
- [Yapay zekâ ve API](https://mailskop.com/yapay-zeka-ve-api): Claude, ChatGPT, Gemini, Copilot, Perplexity, Grok ve DeepSeek için hazır istem, MCP bağlayıcısı kurulumu, anahtarsız API uçları
- [Header analizi](https://mailskop.com/header-analizi): e-posta header’ının (üst bilgi) çözümü: mailin çıktığı sunucu ve ağ, geçtiği duraklar, SPF/DKIM/DMARC/ARC ve güvenlik filtresi kararları; header tarayıcıdan çıkmaz. Ücretsiz mail header analyzer
- [E-posta güvenliği ölçümü, Eylül 2026: 21.197 alan adında DMARC, SPF ve DKIM](https://mailskop.com/arastirma/2026-09): Mailskop’ta ölçülen 8.673 .tr alan adının %47,2’sinde geçerli bir DMARC kaydı yok; sahte e-postayı reddedenler %8,9. Yöntem, sınırlar ve indirilebilir veri. [Veri (CSV)](https://mailskop.com/arastirma/2026-09/veri.csv)
- [Türkiye DMARC oranı: .tr alan adlarında DMARC, aylara göre](https://mailskop.com/arastirma/turkiye-dmarc-orani): sabit adres, her ay yeni ölçüm raporuyla güncellenir. .tr alan adlarında geçerli DMARC kaydı ve uygulayan (quarantine/reject) politika oranı, ölçüm günü ve paydayla; aylara göre tablo, yöntem ve sınırlar (toplu taramalar dahil)
- [Borsa İstanbul e-posta güvenliği karnesi: 625 şirkette DMARC ve DNSSEC (Ekim 2026)](https://mailskop.com/arastirma/2026-10-borsa-istanbul): Borsa İstanbul’da işlem gören şirketlerin 600 e-posta alan adının %51,8’i DMARC uyguluyor, %16,7 sahte e-postayı reddediyor; DNSSEC yalnız 5 alan adında açık. Endeks, sektör ve altyapı kırılımı, indirilebilir veri. [Veri (CSV)](https://mailskop.com/arastirma/2026-10-borsa-istanbul/mailskop-2026-10-borsa-istanbul.csv)
- [ABD borsalarının e-posta güvenliği karnesi: 4.707 şirkette DMARC ve DNSSEC (Ekim 2026)](https://mailskop.com/arastirma/2026-10-abd-borsalari): NYSE ve NASDAQ şirketlerinin 4.640 alan adının %66,9’u DMARC uyguluyor, %38,6 sahte e-postayı reddediyor; DNSSEC alan adlarının %9,2’sinde açık. Endeks, piyasa değeri, sektör, NYSE ve NASDAQ kırılımı, indirilebilir veri. [Veri (CSV)](https://mailskop.com/arastirma/2026-10-abd-borsalari/mailskop-2026-10-abd-borsalari.csv)
- [Rehberler](https://mailskop.com/rehber)
- [Ölçüm raporları](https://mailskop.com/arastirma): her ay sonu ölçüm, her çeyrek ve yıl sonu eğilim
- [RFC 7489’dan RFC 9989’a: DMARC kaydınızda neyi değiştirmelisiniz](https://mailskop.com/rehber/rfc-7489-den-rfc-9989-a-gecis): RFC 9989 (Mayıs 2026) DMARC’ın yeni standardıdır ve RFC 7489’u geçersiz kılar. Kaydınızda ri, rf ya da pct=100 varsa silin; pct=0 ile test ediyorsanız silmeyin, yanına t=y ekleyin. np ile var olmayan alt alan adlarını kapatın.
- [DMARC’ta p=none’dan p=reject’e adım adım](https://mailskop.com/rehber/dmarc-p-none-dan-p-reject-e): p=none izler ama korumaz: sahte e-posta yine teslim edilir. RFC 9989 §5.1, raporlarla bütün meşru gönderimi doğruladıktan sonra quarantine ve reject’e geçmeyi anlatır; her adımı pct=0; t=y ile bir kademe aşağıda test edebilirsiniz.
- [SPF’te 10 DNS sorgusu sınırı: neden aşılır, nasıl düzeltilir](https://mailskop.com/rehber/spf-10-dns-sorgusu-siniri): RFC 7208’e göre bir SPF değerlendirmesi en çok 10 DNS sorgusu gerektiren terim içerebilir; aşılırsa sonuç permerror olur ve SPF hiç çalışmaz. Sayılanlar include, a, mx, ptr, exists ve redirect; ip4, ip6 ve all sayılmaz.
- [Microsoft 365 için SPF, DKIM ve DMARC kurulumu](https://mailskop.com/rehber/microsoft-365-spf-dkim-dmarc): Microsoft 365, özel alan adınızla gönderilen postayı kendiliğinden DKIM ile imzalamaz: iki CNAME kaydı yayımlayıp imzalamayı açmanız gerekir. SPF için tek include:spf.protection.outlook.com yeter; DMARC’ı p=none’dan reject’e kademeli taşıyın.
- [Google Workspace için SPF, DKIM ve DMARC kurulumu](https://mailskop.com/rehber/google-workspace-spf-dkim-dmarc): Google Workspace’te SPF için tek include:_spf.google.com yeter. DKIM anahtarını Yönetici konsolunda üretip google._domainkey TXT kaydı olarak yayımlar, sonra kimlik doğrulamayı başlatırsınız. DMARC’ı en az 48 saat sonra p=none ile açın.
- [Gmail, Yahoo ve Outlook toplu gönderici kuralları](https://mailskop.com/rehber/gmail-yahoo-outlook-toplu-gonderici-kurallari): Kişisel Gmail hesaplarına günde 5.000’e yakın ya da daha fazla ileti gönderen toplu gönderici sayılır: SPF ve DKIM, en az p=none DMARC, tek tıkla abonelikten çıkma ve %0,3’ün altında spam oranı gerekir. Yahoo ve Outlook benzer kurallar uygular.
- [Header analyzer karşılaştırması: Mailskop, MxToolbox, Microsoft ve Google](https://mailskop.com/rehber/header-analyzer-karsilastirmasi): Dört ücretsiz header analyzer da teslim gecikmesini gösterir. Mailskop ayrıca mailin yolunu ülke haritasında çizer, header’ı tarayıcıda çözer, .eml/.msg kabul eder ve DKIM imzasını yeniden doğrular; MxToolbox ve Google header’ı sunucusunda işler.
- [Mail nereden gönderildi? Header’dan mailin yolunu ve IP konumunu bulmak](https://mailskop.com/rehber/mail-nereden-gonderildi): Mailin nereden gönderildiği header’daki Received satırlarında yazar: alttan üste okunur, her satır bir durağı ve o durağın IP’sini verir. Mailskop Header analizi bu yolu ülke ya da bölge düzeyinde haritada çizer, kanıtlanamayan konumu uydurmaz.
- [E-posta güvenliği sözlüğü](https://mailskop.com/sozluk)
- [SPF](https://mailskop.com/sozluk/spf): SPF, bir alan adının kendi adına e-posta göndermeye yetkili sunucuları DNS’te ilan ettiği kayıttır (RFC 7208).
- [DKIM](https://mailskop.com/sozluk/dkim): DKIM, gönderen alan adının iletiye eklediği şifreli bir imzadır; alıcı imzayı o alan adının DNS’te yayımladığı açık anahtarla doğrular (RFC 6376).
- [DMARC](https://mailskop.com/sozluk/dmarc): DMARC, bir alan adının, “Kimden” adresinde kendi adını taşıyan ama SPF ya da DKIM ile doğrulanamayan e-postaya alıcıların ne yapmasını istediğini ve raporların nereye gönderileceğini ilan ettiği DNS kaydıdır (RFC 9989).
- [Hizalama](https://mailskop.com/sozluk/hizalama): Hizalama, SPF ya da DKIM ile doğrulanan alan adının iletinin “Kimden” adresindeki alan adıyla eşleşmesidir; DMARC’tan geçmek için doğrulanan sonuçlardan en az biri hizalı olmalıdır (RFC 9989 §4.4).
- [ARC](https://mailskop.com/sozluk/arc): ARC, iletiyi yolda değiştiren aracıların (e-posta listeleri, yönlendiriciler) iletinin kendilerine ulaştığı andaki kimlik doğrulama sonuçlarını imzalı olarak kaydetmesini sağlayan protokoldür (RFC 8617).
- [DMARC politikası (p)](https://mailskop.com/sozluk/dmarc-politikasi): DMARC politikası, p etiketiyle bildirilen ve alan adı sahibinin DMARC’tan geçemeyen e-postaya alıcıların ne yapmasını tercih ettiğini söyleyen değerdir: none, quarantine ya da reject (RFC 9989 §4.7).
- [DMARC sp](https://mailskop.com/sozluk/dmarc-sp): sp, DMARC kaydında kuruluş alan adının var olan alt alan adları için ayrı bir politika belirleyen etikettir; yazılmazsa alt alan adlarına p uygulanır (RFC 9989 §4.7).
- [DMARC np](https://mailskop.com/sozluk/dmarc-np): np, DMARC kaydında kuruluş alan adının var olmayan alt alan adları için politika belirleyen etikettir; yazılmazsa önce sp, o da yoksa p uygulanır (RFC 9989 §4.7).
- [DMARC test modu (t)](https://mailskop.com/sozluk/dmarc-test-modu): t=y, DMARC kaydında alan adı sahibinin politikasını henüz test ettiğini bildiren etikettir; alıcıdan politikayı bir kademe aşağı uygulaması beklenir (RFC 9989 §4.7).
- [DMARC pct](https://mailskop.com/sozluk/dmarc-pct): pct, RFC 7489’da DMARC politikasının başarısız iletilerin yüzde kaçına uygulanacağını belirten etiketti; RFC 9989 onu kaldırdı ve yerine t etiketini getirdi.
- [DMARC rua](https://mailskop.com/sozluk/dmarc-rua): rua, DMARC kaydında alıcıların toplu (aggregate) raporları göndereceği adresleri belirten etikettir; yazılmazsa alıcılar toplu rapor üretmez (RFC 9989 §4.7).
- [DMARC ruf](https://mailskop.com/sozluk/dmarc-ruf): ruf, DMARC kaydında alıcıların tek tek başarısız iletiler hakkında hata (failure) raporu göndereceği adresleri belirten etikettir (RFC 9989 §4.7, RFC 9991).
- [SPF all](https://mailskop.com/sozluk/spf-all): all, SPF kaydının sonunda yer alan ve kayıttaki önceki terimlerle eşleşmeyen her gönderici için sonucu belirleyen mekanizmadır (RFC 7208 §5.1).
- [SPF include](https://mailskop.com/sozluk/spf-include): include, bir SPF kaydının başka bir alan adının SPF kaydını değerlendirmeye katmasını sağlayan mekanizmadır; o kayıt pass verirse include eşleşir (RFC 7208 §5.2).
- [SPF 10 DNS sorgusu sınırı](https://mailskop.com/sozluk/spf-dns-sorgu-siniri): Bir SPF değerlendirmesi DNS sorgusu gerektiren en çok 10 terim içerebilir; sınır aşılırsa sonuç permerror olur ve SPF hiç çalışmaz (RFC 7208 §4.6.4).
- [SPF permerror](https://mailskop.com/sozluk/spf-permerror): permerror, bir alan adının yayımladığı SPF kaydının doğru yorumlanamadığını ve ancak DNS’te düzeltilerek giderilebileceğini bildiren SPF sonucudur (RFC 7208 §2.6.7).
- [SPF boş sorgu](https://mailskop.com/sozluk/spf-bos-sorgu): Boş sorgu (void lookup), SPF değerlendirmesi sırasında yanıtı boş dönen ya da alan adı bulunamadı diyen DNS sorgusudur; RFC 7208 bunların ikiyle sınırlanmasını ister ve sınır aşılırsa sonuç permerror olur (RFC 7208 §4.6.4).
- [SPF düzleştirme](https://mailskop.com/sozluk/spf-duzlestirme): SPF düzleştirme, include zincirindeki alan adlarını çözüp yerlerine doğrudan IP adreslerini (ip4, ip6) yazarak DNS sorgusu sayısını azaltma yöntemidir.
- [SPF redirect](https://mailskop.com/sozluk/spf-redirect): redirect, kayıttaki hiçbir mekanizma eşleşmezse değerlendirmeyi başka bir alan adının SPF kaydına devreden değiştiricidir; o kaydın sonucu bu alan adının sonucu olur (RFC 7208 §6.1).
- [SPF ptr](https://mailskop.com/sozluk/spf-ptr): ptr, gönderen IP adresinin ters DNS adının belirli bir alan adı altında olup olmadığına bakan SPF mekanizmasıdır; RFC 7208 bu mekanizmanın yayımlanmamasını söyler (RFC 7208 §5.5).
- [SPF mx](https://mailskop.com/sozluk/spf-mx): mx, gönderen IP adresi bir alan adının MX sunucularından birinin adresiyse eşleşen SPF mekanizmasıdır (RFC 7208 §5.4).
- [SPF kayıt türü (TXT, tip 99)](https://mailskop.com/sozluk/spf-kayit-turu): SPF kaydı yalnız DNS TXT kaydı olarak yayımlanmalıdır; deneme döneminde kullanılan ayrı “SPF” kayıt türü (tip 99) artık desteklenmiyor (RFC 7208 §3.1).
- [DKIM seçicisi](https://mailskop.com/sozluk/dkim-secici): DKIM seçicisi, bir alan adının birden çok DKIM anahtarını birbirinden ayıran addır; anahtar <seçici>._domainkey.<alan adı> adresinde yayımlanır (RFC 6376 §3.1).
- [DKIM anahtar uzunluğu](https://mailskop.com/sozluk/dkim-anahtar-uzunlugu): DKIM anahtar uzunluğu, imzalamada kullanılan RSA anahtarının bit sayısıdır; RFC 8301’e göre imzalayanlar en az 1024 bit kullanmak zorundadır ve en az 2048 bit kullanmaları önerilir (RFC 8301 §3.2).
- [DKIM anahtar yenileme](https://mailskop.com/sozluk/dkim-anahtar-yenileme): DKIM anahtar yenileme, imzalama anahtarını düzenli aralıklarla yenisiyle değiştirmektir; M3AAWG anahtarların en az altı ayda bir yenilenmesini önerir.
- [DKIM-Signature başlığı](https://mailskop.com/sozluk/dkim-imza-basligi): DKIM-Signature, imzalayan sunucunun iletiye eklediği ve imzanın kendisini, imzalayan alan adını, seçiciyi ve neyin imzalandığını etiketlerle taşıyan başlıktır (RFC 6376 §3.5).
- [MTA-STS](https://mailskop.com/sozluk/mta-sts): MTA-STS, bir alan adının kendisine e-posta gönderen sunuculardan bağlantıyı geçerli bir sertifikayla TLS üzerinden kurmalarını istediğini ilan ettiği mekanizmadır (RFC 8461).
- [TLS-RPT](https://mailskop.com/sozluk/tls-rpt): TLS-RPT, gönderen sunucuların bir alan adına TLS bağlantısı kurarken yaşadığı sorunları o alan adına toplu raporlarla bildirmesini sağlayan mekanizmadır (RFC 8460).
- [DANE](https://mailskop.com/sozluk/dane): DANE, bir posta sunucusunun TLS sertifikasını ya da anahtarını DNSSEC ile imzalı TLSA kayıtlarında yayımlayarak gönderen sunucuların onu doğrulamasını sağlar (RFC 7672).
- [DNSSEC](https://mailskop.com/sozluk/dnssec): DNSSEC, DNS yanıtlarını dijital imzalarla koruyan uzantılardır; doğrulama yapan bir çözümleyici yolda değiştirilmiş ya da sahte bir yanıtı fark eder (RFC 4033).
- [BIMI](https://mailskop.com/sozluk/bimi): BIMI, bir alan adının, DMARC’tan geçen e-postalarının yanında posta istemcilerinde gösterilmek üzere logosunu DNS’te ilan ettiği mekanizmadır.
- [VMC](https://mailskop.com/sozluk/vmc): VMC, bir sertifika otoritesinin, BIMI logosunun alan adı sahibine ait tescilli bir marka olduğunu doğrulayarak verdiği sertifikadır.
- [SVG Tiny PS](https://mailskop.com/sozluk/svg-tiny-ps): SVG Tiny PS, BIMI logosu için tanımlanmış, betik, bağlantı, animasyon ve dış kaynak içermeyen kısıtlı bir SVG Tiny 1.2 profilidir.
- [MX kaydı](https://mailskop.com/sozluk/mx-kaydi): MX kaydı, bir alan adına gönderilen e-postayı hangi sunucuların kabul ettiğini ve hangi sırayla denenmeleri gerektiğini bildiren DNS kaydıdır (RFC 5321 §5.1).
- [SOA kaydı](https://mailskop.com/sozluk/soa-kaydi): SOA kaydı, bir DNS bölgesinin başında duran ve birincil ad sunucusunu, yönetici adresini, bölgenin sürüm numarasını ve ikincil sunucuların zamanlamasını bildiren kayıttır (RFC 1035 §3.3.13).
- [NS kaydı](https://mailskop.com/sozluk/ns-kaydi): NS kaydı, bir alan adının DNS bölgesine hangi ad sunucularının yetkili olarak yanıt verdiğini bildirir; aynı liste üst bölgede (ör. .com.tr) yetki devri olarak da durur (RFC 1034 §4.2).
- [Glue kaydı](https://mailskop.com/sozluk/glue-kaydi): Glue kaydı, bir ad sunucusunun adı yetki devrettiği bölgenin içindeyse üst bölgede o sunucunun IP adresini veren ek kayıttır; olmasa sunucuya ulaşmak için önce sunucunun kendisine sormak gerekirdi (RFC 1034 §4.2.1).
- [Açık özyinelemeli DNS sunucusu](https://mailskop.com/sozluk/acik-ozyinelemeli-dns): Açık özyinelemeli DNS sunucusu, internetteki herkesin sorgusunu kendi adına çözen bir ad sunucusudur; RFC 5358, ad sunucularının varsayılan olarak dış ağlara özyinelemeli hizmet vermemesini söyler.
- [Bölge aktarımı (AXFR)](https://mailskop.com/sozluk/bolge-aktarimi-axfr): Bölge aktarımı (AXFR), bir DNS bölgesindeki bütün kayıtların ikincil sunuculara kopyalanması için kullanılan işlemdir (RFC 5936).
- [CNAME kaydı](https://mailskop.com/sozluk/cname-kaydi): CNAME kaydı, bir adın başka bir adın takma adı olduğunu bildirir; bir adda CNAME varsa o adda başka kayıt bulunmamalıdır (RFC 1034 §3.6.2).
- [SMTP karşılama satırı](https://mailskop.com/sozluk/smtp-karsilama-satiri): SMTP karşılama satırı, posta sunucusunun bağlantı açılınca gönderdiği, 220 koduyla başlayan ve sunucunun adını taşıyan ilk yanıttır (RFC 5321 §4.2).
- [Açık röle](https://mailskop.com/sozluk/acik-role): Açık röle, kimliği doğrulanmamış herkesin iletisini başka alan adlarına ileten posta sunucusudur; istenmeyen posta göndericileri tarafından kötüye kullanılır (RFC 2505).
- [Ters DNS (PTR) ve FCrDNS](https://mailskop.com/sozluk/ters-dns-ptr): Ters DNS, bir IP adresini in-addr.arpa (IPv6’da ip6.arpa) altındaki PTR kaydıyla bir ada bağlar; o ad da aynı IP’yi gösteriyorsa buna ileri doğrulamalı ters DNS (FCrDNS) denir.
- [STARTTLS](https://mailskop.com/sozluk/starttls): STARTTLS, açık metinle başlayan bir SMTP bağlantısını aynı bağlantı içinde TLS şifrelemesine yükselten SMTP uzantısıdır (RFC 3207).
- [DNSBL (kara liste)](https://mailskop.com/sozluk/dnsbl-kara-liste): DNSBL, istenmeyen posta kaynağı olarak görülen IP adreslerini DNS üzerinden sorgulanabilir biçimde yayımlayan listedir; alan adlarını listeleyenlerine RHSBL denir (RFC 5782).
- [E-posta sahteciliği](https://mailskop.com/sozluk/e-posta-sahteciligi): E-posta sahteciliği (spoofing), bir iletinin “Kimden” adresine gerçek gönderici olmayan bir alan adının yazılmasıdır; SMTP bunu kendiliğinden engellemez.
- [BEC](https://mailskop.com/sozluk/bec): BEC (iş e-postası dolandırıcılığı), saldırganın bir yöneticiyi, çalışanı ya da tedarikçiyi taklit ederek kurumu ödeme yapmaya ya da bilgi vermeye ikna ettiği dolandırıcılık türüdür.
- [Kuruluş alan adı](https://mailskop.com/sozluk/kurulus-alan-adi): Kuruluş alan adı, bir alan adının aynı yönetim yetkisi altındaki en üst düzeyidir; posta.ornek.com.tr için ornek.com.tr’dir (RFC 9989 §3.2.14).
- [DNS Tree Walk](https://mailskop.com/sozluk/dns-tree-walk): DNS Tree Walk, RFC 9989’un DMARC kaydını ve kuruluş alan adını bulmak için alan adından köke doğru etiket etiket DNS sorgusu yaptığı yöntemdir; en çok sekiz sorgu yapılır (RFC 9989 §4.10).
- [SPF, DKIM, DMARC nedir](https://mailskop.com/nedir)
- [Aydınlatma metni (KVKK)](https://mailskop.com/kvkk)
- [Sürüm bilgisi](https://mailskop.com/surum)

Örnek rapor: [kinetikbilisim.net](https://mailskop.com/tara/kinetikbilisim.net) ·
[Markdown](https://mailskop.com/tara/kinetikbilisim.net?bicim=md)

## Dürüstlük kuralları

Bu araç, bilmediği şeyi bildiğini söylemez. Ajanların çıktıyı aktarırken
korumasını beklediğimiz üç ayrım:

1. **DKIM seçicisi bulunamaması, DKIM'in olmadığını kanıtlamaz.** Seçici adı
   keyfîdir ve DNS'te listelenemez. Yalnızca platformun seçici adını zorunlu
   kıldığı durumlarda (Microsoft 365, Google Workspace) yokluk kanıt sayılır.
2. **MX (gelen posta) ile SPF (giden posta) meşru olarak farklı olabilir.**
   "SPF, MX'teki platformu yetkilendirmiyor" tek başına kusur değildir.
3. **Sorgulanamayan bir dal, "kayıt yok" demek değildir.** Rapor bu ikisini
   ayrı ayrı işaretler.

## İletişim

Kinetik Bilişim · contact@mailskop.com · +90 850 244 32 97

---

## Mailskop (English)

> Free tool that audits a domain's email authentication (SPF, DKIM, DMARC, BIMI,
> MTA-STS, DNSSEC) in a single request. Published by Kinetik Bilişim, Türkiye.

Every page exists in Turkish and English (English under `/en`); machine outputs
are available in both languages. JSON field names are stable and language-independent.

## Pages (English)

- [Home](https://mailskop.com/en)
- [Bulk check](https://mailskop.com/en/bulk): many domains from a list
- [Compare](https://mailskop.com/en/compare): two domains’ email security side by side
- [SPF lookup](https://mailskop.com/en/spf-lookup): Read your domain’s SPF record: the include tree, the 10 DNS-lookup limit, the void counter, exposed IP blocks and the "all" qualifier. Free, no sign-up.
- [DKIM lookup](https://mailskop.com/en/dkim-lookup): Find your DKIM selectors, read the public key length and the test/revoked state. If you do not know the selector, common ones are scanned. Free, no sign-up.
- [DMARC lookup](https://mailskop.com/en/dmarc-lookup): Check any domain’s DMARC record for free: policy, alignment, report addresses and syntax errors, read against RFC 9989. Instant result, no sign-up.
- [MX lookup](https://mailskop.com/en/mx-lookup): See your MX records, your provider and any security gateway in front of it; read MTA-STS, TLS-RPT and DANE state. Free, no sign-up.
- [BIMI lookup](https://mailskop.com/en/bimi-lookup): Check your BIMI record, your logo’s SVG Tiny PS conformance and your VMC/CMC certificate. The DMARC prerequisite is checked alongside.
- [DNSSEC lookup](https://mailskop.com/en/dnssec-lookup): Whether DNSSEC is on for your domain, whether the DS record is published in the parent zone, and whether the chain actually validates — measured, not assumed.
- [AI and API](https://mailskop.com/en/ai-and-api): ready-made prompt for Claude, ChatGPT, Gemini, Copilot, Perplexity, Grok and DeepSeek, MCP connector setup, keyless API endpoints
- [Email header analyzer](https://mailskop.com/en/header-analyzer): the server and network a message left from, every hop, SPF/DKIM/DMARC/ARC and security filter verdicts; the header never leaves the browser
- [Email security measurement, September 2026: DMARC, SPF and DKIM across 21,197 domains](https://mailskop.com/en/research/2026-09): Of 8,673 .tr domains measured on Mailskop, 47.2% have no valid DMARC record and 8.9% reject forged mail. Method, limits and downloadable data. [Data (CSV)](https://mailskop.com/arastirma/2026-09/veri.csv)
- [DMARC adoption in Türkiye: .tr domains by month](https://mailskop.com/en/research/turkey-dmarc-adoption): fixed address, updated with every monthly measurement report. Share of .tr domains with a valid DMARC record and with an enforcing (quarantine/reject) policy, with measurement date and denominator; table by month, method and limits (bulk scans included)
- [Borsa Istanbul email security report card: DMARC and DNSSEC in 625 companies (Oct 2026)](https://mailskop.com/en/research/2026-10-borsa-istanbul): Of 600 email domains of companies listed on Borsa Istanbul, 51.8% enforce DMARC and 16.7% reject forged mail; DNSSEC is on for 5. By index, sector and mail platform, with downloadable data. [Data (CSV)](https://mailskop.com/arastirma/2026-10-borsa-istanbul/mailskop-2026-10-borsa-istanbul.csv)
- [US stock exchanges email security report card: DMARC and DNSSEC in 4,707 firms (Oct 2026)](https://mailskop.com/en/research/2026-10-abd-borsalari): Of 4,640 domains of NYSE and NASDAQ companies, 66.9% enforce DMARC and 38.6% reject forged mail; DNSSEC is on for 9.2%. By index, market cap, sector, NYSE and NASDAQ, with downloadable data. [Data (CSV)](https://mailskop.com/arastirma/2026-10-abd-borsalari/mailskop-2026-10-abd-borsalari.csv)
- [Guides](https://mailskop.com/en/guides)
- [Measurement reports](https://mailskop.com/en/research): monthly measurement, quarterly and annual trends
- [From RFC 7489 to RFC 9989: what to change in your DMARC record](https://mailskop.com/en/guides/rfc-7489-to-rfc-9989-migration): RFC 9989 (May 2026) is the new DMARC standard and obsoletes RFC 7489. If your record has ri, rf or pct=100, delete them; if you are testing with pct=0, keep it and add t=y next to it. Close off non-existent subdomains with np.
- [DMARC from p=none to p=reject, step by step](https://mailskop.com/en/guides/dmarc-p-none-to-p-reject): p=none monitors but does not protect: forged mail is still delivered. RFC 9989 §5.1 describes confirming every legitimate sender with reports, then moving to quarantine and reject; you can test each step one level lower with pct=0; t=y.
- [The SPF 10 DNS lookup limit: why it is exceeded and how to fix it](https://mailskop.com/en/guides/spf-10-dns-lookup-limit): Under RFC 7208 an SPF evaluation may involve at most 10 terms that cause DNS lookups; beyond that the result is permerror and SPF does not work at all. include, a, mx, ptr, exists and redirect count; ip4, ip6 and all do not.
- [Setting up SPF, DKIM and DMARC for Microsoft 365](https://mailskop.com/en/guides/microsoft-365-spf-dkim-dmarc): Microsoft 365 does not DKIM-sign mail from your custom domain by default: you need to publish two CNAME records and turn signing on. For SPF a single include:spf.protection.outlook.com is enough; take DMARC from p=none to reject in stages.
- [Setting up SPF, DKIM and DMARC for Google Workspace](https://mailskop.com/en/guides/google-workspace-spf-dkim-dmarc): In Google Workspace a single include:_spf.google.com is enough for SPF. You generate the DKIM key in the Admin console, publish it as a google._domainkey TXT record and then start authentication. Turn DMARC on with p=none at least 48 hours later.
- [Gmail, Yahoo and Outlook bulk sender requirements](https://mailskop.com/en/guides/gmail-yahoo-outlook-bulk-sender-requirements): Anyone sending close to 5,000 or more messages a day to personal Gmail accounts is a bulk sender: SPF and DKIM, DMARC of at least p=none, one-click unsubscribe and a spam rate below 0.3% are required. Yahoo and Outlook apply similar rules.
- [Email header analyzer comparison: Mailskop, MxToolbox, Microsoft and Google](https://mailskop.com/en/guides/email-header-analyzer-comparison): All four free header analyzers show delivery delays. Mailskop also draws the message’s route on a country map, parses the header in your browser, accepts .eml/.msg and re-verifies DKIM; MxToolbox and Google process the header on their servers.
- [Where was an email sent from? Tracing its route and IP location from the header](https://mailskop.com/en/guides/email-header-trace-route-map): Where an email was sent from is written in the Received lines of its header: read from the bottom up, each line gives a hop and its IP. Mailskop’s header analyzer maps this route at country or region level and never makes up a location.
- [Email security glossary](https://mailskop.com/en/glossary)
- [SPF](https://mailskop.com/en/glossary/spf): SPF is the DNS record in which a domain declares which servers are authorised to send email on its behalf (RFC 7208).
- [DKIM](https://mailskop.com/en/glossary/dkim): DKIM is a cryptographic signature that the sending domain adds to a message; the recipient verifies it with the public key that domain publishes in DNS (RFC 6376).
- [DMARC](https://mailskop.com/en/glossary/dmarc): DMARC is the DNS record in which a domain states what it wants receivers to do with email that carries its name in the “From” address but cannot be authenticated by SPF or DKIM, and where reports should be sent (RFC 9989).
- [Alignment](https://mailskop.com/en/glossary/alignment): Alignment is the match between the domain authenticated by SPF or DKIM and the domain in the message’s “From” address; to pass DMARC, at least one authenticated result must be aligned (RFC 9989 §4.4).
- [ARC](https://mailskop.com/en/glossary/arc): ARC is a protocol that lets intermediaries which modify a message in transit (mailing lists, forwarders) record, in signed form, the authentication results the message had when it reached them (RFC 8617).
- [DMARC policy (p)](https://mailskop.com/en/glossary/dmarc-policy): The DMARC policy is the value of the p tag stating what the domain owner prefers receivers to do with email that fails DMARC: none, quarantine or reject (RFC 9989 §4.7).
- [DMARC sp](https://mailskop.com/en/glossary/dmarc-sp): sp is the DMARC tag that sets a separate policy for existing subdomains of the organizational domain; if it is absent, p applies to subdomains (RFC 9989 §4.7).
- [DMARC np](https://mailskop.com/en/glossary/dmarc-np): np is the DMARC tag that sets the policy for non-existent subdomains of the organizational domain; if it is absent, sp applies, and if that is absent too, p (RFC 9989 §4.7).
- [DMARC testing mode (t)](https://mailskop.com/en/glossary/dmarc-testing-mode): t=y is the DMARC tag by which the domain owner signals that it is still testing its policy; receivers are expected to apply the policy one level lower (RFC 9989 §4.7).
- [DMARC pct](https://mailskop.com/en/glossary/dmarc-pct): pct was the RFC 7489 tag that set the percentage of failing messages the DMARC policy applied to; RFC 9989 removed it and introduced the t tag instead.
- [DMARC rua](https://mailskop.com/en/glossary/dmarc-rua): rua is the DMARC tag listing the addresses to which receivers send aggregate reports; if it is absent, receivers do not generate aggregate reports (RFC 9989 §4.7).
- [DMARC ruf](https://mailskop.com/en/glossary/dmarc-ruf): ruf is the DMARC tag listing the addresses to which receivers send failure reports about individual failing messages (RFC 9989 §4.7, RFC 9991).
- [SPF all](https://mailskop.com/en/glossary/spf-all): all is the mechanism at the end of an SPF record that sets the result for every sender not matched by the earlier terms (RFC 7208 §5.1).
- [SPF include](https://mailskop.com/en/glossary/spf-include): include is the mechanism by which an SPF record brings another domain’s SPF record into the evaluation; if that record returns pass, the include matches (RFC 7208 §5.2).
- [SPF 10 DNS lookup limit](https://mailskop.com/en/glossary/spf-dns-lookup-limit): An SPF evaluation may involve at most 10 terms that cause DNS lookups; beyond that the result is permerror and SPF does not work at all (RFC 7208 §4.6.4).
- [SPF permerror](https://mailskop.com/en/glossary/spf-permerror): permerror is the SPF result stating that a domain’s published SPF record could not be interpreted correctly and can only be resolved by fixing DNS (RFC 7208 §2.6.7).
- [SPF void lookup](https://mailskop.com/en/glossary/spf-void-lookup): A void lookup is a DNS query during SPF evaluation that returns no answer or says the name does not exist; RFC 7208 asks implementations to limit them to two, and exceeding the limit yields permerror (RFC 7208 §4.6.4).
- [SPF flattening](https://mailskop.com/en/glossary/spf-flattening): SPF flattening is the practice of resolving the domains in an include chain and writing their IP addresses (ip4, ip6) into the record directly, to reduce the number of DNS lookups.
- [SPF redirect](https://mailskop.com/en/glossary/spf-redirect): redirect is the modifier that hands evaluation over to another domain’s SPF record when no mechanism in the record matches; that record’s result becomes this domain’s result (RFC 7208 §6.1).
- [SPF ptr](https://mailskop.com/en/glossary/spf-ptr): ptr is the SPF mechanism that checks whether the reverse DNS name of the sending IP address falls under a given domain; RFC 7208 says this mechanism should not be published (RFC 7208 §5.5).
- [SPF mx](https://mailskop.com/en/glossary/spf-mx): mx is the SPF mechanism that matches when the sending IP address is the address of one of a domain’s MX servers (RFC 7208 §5.4).
- [SPF record type (TXT, type 99)](https://mailskop.com/en/glossary/spf-record-type): An SPF record must be published only as a DNS TXT record; the separate “SPF” record type (type 99) used in the experimental phase is no longer supported (RFC 7208 §3.1).
- [DKIM selector](https://mailskop.com/en/glossary/dkim-selector): A DKIM selector is the name that distinguishes a domain’s DKIM keys from one another; the key is published at <selector>._domainkey.<domain> (RFC 6376 §3.1).
- [DKIM key length](https://mailskop.com/en/glossary/dkim-key-length): DKIM key length is the size in bits of the RSA key used for signing; under RFC 8301 signers must use at least 1024 bits and should use at least 2048 bits (RFC 8301 §3.2).
- [DKIM key rotation](https://mailskop.com/en/glossary/dkim-key-rotation): DKIM key rotation is replacing the signing key with a new one at regular intervals; M3AAWG recommends rotating keys at least every six months.
- [DKIM-Signature header](https://mailskop.com/en/glossary/dkim-signature-header): DKIM-Signature is the header the signing server adds to a message, carrying in tags the signature itself, the signing domain, the selector and what was signed (RFC 6376 §3.5).
- [MTA-STS](https://mailskop.com/en/glossary/mta-sts): MTA-STS is the mechanism by which a domain declares that servers sending it email must connect over TLS with a valid certificate (RFC 8461).
- [TLS-RPT](https://mailskop.com/en/glossary/tls-rpt): TLS-RPT is the mechanism by which sending servers report to a domain, in aggregate reports, the problems they had establishing TLS connections to it (RFC 8460).
- [DANE](https://mailskop.com/en/glossary/dane): DANE lets sending servers verify a mail server’s TLS certificate or key by publishing it in DNSSEC-signed TLSA records (RFC 7672).
- [DNSSEC](https://mailskop.com/en/glossary/dnssec): DNSSEC is a set of extensions that protect DNS answers with digital signatures; a validating resolver detects an answer that was altered or forged in transit (RFC 4033).
- [BIMI](https://mailskop.com/en/glossary/bimi): BIMI is the mechanism by which a domain declares in DNS the logo to be shown next to its DMARC-passing email in mail clients.
- [VMC](https://mailskop.com/en/glossary/vmc): A VMC is a certificate issued by a certificate authority after verifying that the BIMI logo is a registered trademark owned by the domain owner.
- [SVG Tiny PS](https://mailskop.com/en/glossary/svg-tiny-ps): SVG Tiny PS is a restricted SVG Tiny 1.2 profile defined for BIMI logos, with no scripts, links, animation or external resources.
- [MX record](https://mailskop.com/en/glossary/mx-record): An MX record is the DNS record that states which servers accept email for a domain and in which order they should be tried (RFC 5321 §5.1).
- [SOA record](https://mailskop.com/en/glossary/soa-record): The SOA record sits at the top of a DNS zone and states the primary name server, the administrator’s address, the zone’s version number and the timing for secondary servers (RFC 1035 §3.3.13).
- [NS record](https://mailskop.com/en/glossary/ns-record): An NS record states which name servers answer authoritatively for a domain’s DNS zone; the same list also sits in the parent zone (such as .com) as the delegation (RFC 1034 §4.2).
- [Glue record](https://mailskop.com/en/glossary/glue-record): A glue record is the extra record in the parent zone giving a name server’s IP address when the server’s name lies inside the zone it is delegated; without it, reaching the server would require asking that very server first (RFC 1034 §4.2.1).
- [Open recursive resolver](https://mailskop.com/en/glossary/open-recursive-resolver): An open recursive resolver is a name server that resolves queries on behalf of anyone on the internet; RFC 5358 says name servers should not offer recursive service to external networks by default.
- [Zone transfer (AXFR)](https://mailskop.com/en/glossary/zone-transfer-axfr): A zone transfer (AXFR) is the operation used to copy all records of a DNS zone to secondary servers (RFC 5936).
- [CNAME record](https://mailskop.com/en/glossary/cname-record): A CNAME record declares that one name is an alias of another; if a name has a CNAME, no other records should exist at that name (RFC 1034 §3.6.2).
- [SMTP banner](https://mailskop.com/en/glossary/smtp-banner): The SMTP banner is the first reply a mail server sends when a connection opens, starting with code 220 and carrying the server’s name (RFC 5321 §4.2).
- [Open relay](https://mailskop.com/en/glossary/open-relay): An open relay is a mail server that forwards anyone’s messages to other domains without authentication; it is abused by spammers (RFC 2505).
- [Reverse DNS (PTR) and FCrDNS](https://mailskop.com/en/glossary/reverse-dns-ptr): Reverse DNS maps an IP address to a name through a PTR record under in-addr.arpa (ip6.arpa for IPv6); when that name also points back to the same IP, it is called forward-confirmed reverse DNS (FCrDNS).
- [STARTTLS](https://mailskop.com/en/glossary/starttls): STARTTLS is the SMTP extension that upgrades a connection that started in plain text to TLS encryption within the same connection (RFC 3207).
- [DNSBL (blocklist)](https://mailskop.com/en/glossary/dnsbl-blocklist): A DNSBL is a list that publishes IP addresses seen as sources of unwanted mail in a form queryable over DNS; lists of domain names are called RHSBLs (RFC 5782).
- [Email spoofing](https://mailskop.com/en/glossary/email-spoofing): Email spoofing is putting a domain that is not the real sender into a message’s “From” address; SMTP does not prevent this by itself.
- [BEC](https://mailskop.com/en/glossary/bec): BEC (business email compromise) is a type of fraud in which an attacker impersonates an executive, employee or supplier to persuade an organisation to make a payment or hand over information.
- [Organizational domain](https://mailskop.com/en/glossary/organizational-domain): The organizational domain is the highest level of a domain that is under the same administrative authority; for mail.example.com it is example.com (RFC 9989 §3.2.14).
- [DNS Tree Walk](https://mailskop.com/en/glossary/dns-tree-walk): The DNS Tree Walk is the method RFC 9989 uses to find the DMARC record and the organizational domain by querying DNS label by label from the domain towards the root; at most eight queries are made (RFC 9989 §4.10).
- [About](https://mailskop.com/en/about)
- [Privacy notice](https://mailskop.com/en/privacy)

Example report: [kinetikbilisim.net](https://mailskop.com/en/check/kinetikbilisim.net) ·
[Markdown](https://mailskop.com/en/check/kinetikbilisim.net?format=md)

**What makes it different:** DMARC is evaluated against **RFC 9989 (DMARCbis,
May 2026)**, not the obsolete RFC 7489. The `pct`, `ri` and `rf` tags are
marked "historic" in the registry and no longer defined by the standard; `t=y` test mode and the `np` tag are interpreted
correctly; the organizational domain is discovered through the DNS Tree Walk
(§4.10) rather than the Public Suffix List. Results will therefore differ from
tools that still assume RFC 7489 — those differences are deliberate.

## Endpoints

- `GET https://mailskop.com/api/check?domain={domain}` — full report as JSON
- `GET https://mailskop.com/en/check/{domain}` with `Accept: text/markdown` — same report as Markdown
- `GET https://mailskop.com/en/check/{domain}` with `Accept: application/json` — same report as JSON
- `GET https://mailskop.com/en/check/{domain}?format=md` — Markdown WITHOUT any header. Use this
  when your fetcher cannot set custom HTTP headers (most chat assistants cannot).
  `?format=json` returns JSON the same way.
- Chat assistants: `/api/` is disallowed in robots.txt, so user-triggered fetchers that
  obey robots.txt cannot open it; use `/en/check/{domain}?format=json` instead. If your fetch
  tool may only open URLs that already appear in the conversation, ask the user to paste
  the full URL, e.g. https://mailskop.com/en/check/kinetikbilisim.net?format=md
- Command-line clients (curl, wget, httpie, python-requests, Go, PowerShell) receive
  Markdown automatically, no header needed: `curl https://mailskop.com/en/check/example.com`
- Always send a `User-Agent`. Requests with an empty User-Agent are rejected at the edge.
- `GET https://mailskop.com/en/check/{domain}/spf` — complete SPF include chain, resolved to the end
- `GET https://mailskop.com/en/check/{domain}/dkim` — wide DKIM selector sweep (60+ selectors)
- `POST https://mailskop.com/api/header` — email header analysis: raw header in the body (text/plain, or JSON `{"header": "..."}`); JSON report, or Markdown with `?format=md`; `?lang=tr` for Turkish. The header is processed in the request and never stored
- `POST https://mailskop.com/en/mcp` — MCP server (JSON-RPC 2.0), two tools: `check_domain` (domain audit) and `analyze_header` (email header analysis). `https://mailskop.com/mcp` is the same server with Turkish tool names
- `GET https://mailskop.com/en/openapi.json` — machine-readable API description
- `GET https://mailskop.com/llms-full.txt` — full text of every permanent page (guides, report, lookup pages) in Markdown
- `GET https://mailskop.com/auth.md` — authentication: there is none, and why

No authentication, no registration, no cost. Rate limit: 60 scans per minute per IP on `/en/check/{domain}` and `/api/check`; automated clients calling `/api/check` directly: 12 scans per minute (one every 5 s), 429 with `Retry-After` beyond that.

## Three distinctions to preserve when relaying results

1. **A missing DKIM selector does NOT prove DKIM is disabled.** Selector names are
   arbitrary and cannot be enumerated from DNS. `score.uncertain` is `true` in that
   case. Only where the platform mandates selector names (Microsoft 365, Google
   Workspace) is absence treated as proof, and the report says so explicitly.
2. **MX (inbound) and SPF (outbound) may legitimately differ.** "SPF does not
   authorize the platform seen in MX" is not a defect on its own.
3. **A branch that could not be queried is not a branch that is missing.** The
   report marks these separately from a genuine permerror.