E-posta Güvenliği Rehberi: SPF, DKIM, DMARC, MTA-STS ve BIMI

E-posta Güvenliği neleri kontrol eder

Alıcı posta sunucuları, alan adınızdan geldiğini söyleyen bir iletinin gerçek olup olmadığına birkaç DNS kaydını okuyarak karar verir. E-posta Güvenliği bunların hepsini tek bir alan adı için okur: SPF gönderme izni olan sunucuları listeler, DKIM e-postanızı imzalayan anahtarları yayımlar, DMARC ikisi de başarısız olduğunda alıcılara ne yapacaklarını ve nereye rapor göndereceklerini söyler, MTA-STS ile TLS-RPT posta sunucuları arasındaki şifrelemeyi korur ve izler, BIMI ise DMARC zorlandıktan sonra logonuzu gösterebilir.

Kontrol edilen kayıtlar ve bulundukları yer
Kayıt	DNS adı	Standart	Puandaki ağırlık
SPF	`example.com` (TXT)	RFC 7208	25
DKIM	`<selector>._domainkey.example.com` (TXT)	RFC 6376	20
DMARC	`_dmarc.example.com` (TXT)	RFC 7489	30
MTA-STS	`_mta-sts.example.com` (TXT) ve `https://mta-sts.example.com/.well-known/mta-sts.txt`	RFC 8461	10
TLS-RPT	`_smtp._tls.example.com` (TXT)	RFC 8460	10
BIMI	`default._bimi.example.com` (TXT)	BIMI Group taslağı	5

Bu rehber, ayrı SPF Checker ve DMARC Checker rehberlerinin yerini alır: her iki araç da artık E-posta Güvenliği'nin parçasıdır ve ilgili bölümleri aşağıda yer alır.

E-posta Güvenliği nasıl kullanılır

E-posta Güvenliği aracını açın ve From adresindeki alan adını girin, örneğin example.com. Yapıştırılan bir URL ya da e-posta adresi alan adına indirgenir.
İsterseniz bir DKIM seçicisi girin. Bu, gönderdiğiniz bir iletideki DKIM-Signature başlığının s= etiketidir; yaygın seçiciler her zaman denenir.
XGM, SPF kaydını her include ve redirect ile birlikte çözümler, _dmarc kaydını arar (bulamazsa üst alan adına düşer) ve en fazla üç harici rapor adresinin yetkilendirilmiş olup olmadığına bakar.
Aynı anda XGM sunucusu DKIM seçicilerini dener, MTA-STS, TLS-RPT ve BIMI kayıtlarını okur ve MTA-STS politika dosyasını HTTPS üzerinden çeker.
Puanı ve alanlar tablosunu okuyun, sonra bulguları en ağırdan başlayarak ele alın. Düzeltmesi olan bulgular, DNS sağlayıcınıza kopyalayacağınız bir kayıt gösterir.
Sonucu kalıcı bağlantıyla (/tools/email-security?d=example.com) paylaşın, dışa aktarın ya da öncelik sırasına konmuş önerileri içeren puanlı sunucu raporu için Tam rapor sekmesini açın.

Bir DNS sorgusu zaman aşımına uğrarsa araç bunu eksik kayıt olarak değil zaman aşımı olarak bildirir ve o alan puana katılmaz. Kontrolü yeniden çalıştırmak genellikle yeterlidir.

Puan ve DMARC yol haritası

Her alan bir durum alır: geçen alan ağırlığının tamamını, iyileştirme gereken alan yarısını, başarısız ya da kurulmamış alan ise hiç puan almaz. p=none durumundaki DMARC ve test modundaki MTA-STS, koruma değil izleme sağladıkları için iyileştirme gereken sayılır. Puan; alan adlarını karşılaştırmak ve ilerlemeyi izlemek için hızlı bir yön göstergesidir, bir sertifika değildir.

Puanın altındaki DMARC yol haritası, alan adının alışılmış yolun neresinde durduğunu gösterir: rapor adresiyle birlikte p=none yayımlayın, her meşru gönderici hizalandığında p=quarantine aşamasına, ardından p=reject aşamasına geçin. p=none'dan p=reject'e rehberi bu geçişi hafta hafta anlatır.

DMARC nedir

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489), eski iki e-posta kimlik doğrulama yöntemini insanların gerçekten gördüğü adrese bağlar. SPF, zarf göndericisi adına hangi sunucuların gönderebileceğini kontrol eder; DKIM ise gönderen sistemin eklediği kriptografik imzayı doğrular. İkisi de tek başına görünen From başlığına bakmaz.

DMARC bu boşluğu kapatır. Bir ileti, SPF ya da DKIM geçtiğinde ve geçen alan adı From alan adıyla hizalı olduğunda DMARC'ı geçer. Alan adı sahibi; bir ileti başarısız olduğunda alıcıların ne yapacağını söyleyen bir politika ve alan adıyla gönderilen tüm e-posta hakkında rapor alacak adresler yayımlar.

Alıcı sunucu SPF ve DKIM'i kontrol eder, geçen alan adlarını From alan adıyla karşılaştırır, yayımlanan politikayı uygular ve sonrasında bir toplu rapor gönderir.

Alıcılar politikaya uymak zorunda değildir ve büyük posta sağlayıcıları onu kendi spam sinyalleriyle birleştirir. Pratikte p=reject büyük sağlayıcılar tarafından uygulanır ve alan adınızın doğrudan taklit edilmesine karşı yayımlayabileceğiniz en güçlü korumadır.

DMARC neden önemli

DMARC olmadan herkes From başlığında sizin alan adınızla e-posta gönderebilir ve bundan hiç haberiniz olmaz. Fatura, parola sıfırlama ya da yönetici taklidi yapan oltalama tam olarak buna dayanır. Bir DMARC kaydı kendi e-postanızın nasıl değerlendirildiğini de değiştirir: kimliği doğrulanmış ve hizalı e-postaya alıcıların güvenmesi daha kolaydır.

Şubat 2024'ten bu yana Google ve Yahoo, toplu göndericilerin (kullanıcılarına günde yaklaşık 5.000 ve üzeri ileti gönderenler) SPF ve DKIM'in yanında en az p=none olacak şekilde bir DMARC kaydı yayımlamasını istiyor. E-posta gönderen her alan adı aynı kurulumdan yararlanır; hiç e-posta göndermeyen alan adları ise kötüye kullanılamasınlar diye p=reject yayımlamalıdır.

E-posta göndermeyen alan adları

_dmarc altında v=DMARC1; p=reject; yayımlayın; yanına v=spf1 -all SPF kaydı ekleyin ve alan adı e-posta almıyorsa MX kaydı da bırakmayın. Park edilmiş alan adları kimse izlemediği için taklit saldırılarının gözde hedefidir.

Her DMARC etiketini okumak

Bir DMARC kaydı, noktalı virgülle ayrılmış tag=value çiftlerinden oluşur. Kayıt v=DMARC1 ile başlamak zorundadır ve p etiketi gereklidir; alışılmış sıralamada hemen v etiketinden sonra gelir. Bilinmeyen etiketler alıcılar tarafından yok sayılır; bir yazım hatasının bir ayarı sessizce devre dışı bırakmasının nedeni budur.

DMARC etiketleri (RFC 7489 §6.3)
Etiket	Anlamı	Varsayılan
`v`	Sürüm. `DMARC1` olmalı ve ilk sırada gelmeli.	zorunlu
`p`	Alan adı için politika: `none`, `quarantine` ya da `reject`.	zorunlu
`sp`	Kendi kaydı olmayan alt alan adları için politika.	`p` ile aynı
`pct`	Politikanın uygulandığı başarısız e-posta yüzdesi; kalanına bir alt kademe politika uygulanır.	`100`
`rua`	Günlük toplu raporların adresleri; virgülle ayrılmış `mailto:` URI'leri.	yok
`ruf`	Hata (adli) raporlarının adresleri; büyük sağlayıcıların pek azı gönderir.	yok
`adkim`	DKIM hizalaması: `r` gevşek (aynı kurumsal alan adı) ya da `s` katı (birebir eşleşme).	`r`
`aspf`	SPF hizalaması, `adkim` ile aynı değerler.	`r`
`fo`	Hata raporlarının ne zaman üretileceği: `0`, `1`, `d` ya da `s`.	`0`
`ri`	Toplu raporlar arasında istenen aralık, saniye cinsinden.	`86400`

IETF'teki DMARC çalışma grubu standardı gözden geçiriyor; bu çalışma çoğunlukla DMARCbis olarak anılır. Revizyon, var olmayan alt alan adları için np gibi etiketler ekliyor ve pct yerine t test bayrağını getiriyor. XGM bu etiketleri tanır, bu yüzden onları bilinmeyen olarak bildirmez.

Kontrol aracındaki kararlar

XGM kararı ne anlama gelir
Karar	Anlamı
DMARC kaydı yok	`_dmarc` altında `v=DMARC1` ile başlayan bir TXT kaydı yok. Alıcılar hiçbir DMARC politikası uygulamaz.
DMARC uygulanmıyor (birden fazla kayıt)	Birden fazla DMARC kaydı bulundu; alıcılar hepsini yok saymak zorundadır (RFC 7489 §6.6.3).
DMARC kaydı geçersiz	`p` etiketi eksik ya da none, quarantine, reject dışında bir değer taşıyor.
Yalnızca izleme (p=none)	Kayıt çalışıyor ve raporlar akıyor, ama başarısız e-posta her zamanki gibi teslim ediliyor.
Zorlanıyor (p=quarantine) / (p=reject)	Başarısız e-posta spam'e gidiyor ya da reddediliyor. Aşağıdaki uyarılar yine de ilgi isteyebilir.

Yaygın DMARC hataları ve çözümleri

İki DMARC kaydı

Bu genellikle yeni bir sağlayıcının kurulum sihirbazı eskisinin yanına ikinci bir kayıt eklediğinde olur. Çözüm, ikisini tek bir kayıtta birleştirmektir; aracın gösterdiği düzeltme temiz bir başlangıç noktası verir.

Kayıt alan adının kendisinde yayımlanmış

example.com üzerinde v=DMARC1 içeren bir TXT kaydı hiçbir işe yaramaz. Kayıt _dmarc.example.com altında olmalıdır. Bazı DNS panelleri bölge adını kendiliğinden eklediği için oraya ana makine adı olarak yalnızca _dmarc yazın.

Başka alan adına giden raporlar düşürülüyor

rua=mailto:reports@dmarc-service.example.net alan adınızın dışını gösteriyorsa, alıcı alan adı raporlarınızı kabul ettiğini belirten bir kayıt yayımlamalıdır. Rapor hizmetleri bunu müşterileri için genellikle kendiliğinden yapar, ama başka bir alan adındaki kendi posta kutunuz için elle eklemeniz gerekir.

example.com._report._dmarc.dmarc-service.example.net. IN TXT "v=DMARC1"

Yıllarca p=none aşamasında kalmak

p=none bir ölçüm aşamasıdır, varış noktası değil. Toplu raporlar meşru göndericilerinizin hizalı biçimde geçtiğini gösterdiğinde quarantine aşamasına, sonra reject aşamasına geçin. p=none'dan p=reject'e rehberi bunu aşama aşama anlatır.

Daha zayıf alt alan adı politikası

p=reject; sp=none, her alt alan adını taklide açık bırakır; saldırganlar tam da bu yüzden billing.example.com gibi adlar kullanır. Bir alt alan adını düzeltirken gerçekten daha yumuşak bir politikaya ihtiyacınız yoksa sp etiketini kaldırın ya da ona p ile aynı değeri verin.

Yönlendirme ve posta listeleri

Yönlendirme çoğu zaman SPF'i bozar; iletileri değiştiren posta listeleri de DKIM'i bozabilir. Zorlamaya geçmeden önce kendi e-postanızın kendi alan adınızla DKIM imzalı olduğundan emin olun: DKIM düz yönlendirmeden sağ çıkar, SPF çıkmaz.

Örnek DMARC kayıtları

example.com alan adını ve rapor adresini kendi değerlerinizle değiştirin. Her aşamada rua etiketini koruyun: raporlar olmadan zorlamanın neyi engelleyeceğini göremezsiniz.

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

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

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

Araç, var olan bir kayıt için sonraki adımı önerdiğinde sp, ruf ya da fo gibi hâlihazırda yayımladığınız diğer etiketleri korur ve yalnızca politikayı değiştirir.

SPF nedir

Sender Policy Framework (RFC 7208), v=spf1 ile başlayan ve bir alan adı için kimin e-posta gönderebileceğini listeleyen bir TXT kaydıdır. Bir sunucu ileti aldığında zarf göndericisine, yani SMTP MAIL FROM komutunda kullanılan adrese bakar ve bağlanan IP'nin o alan adının kaydında izinli olup olmadığını kontrol eder. Sonuç pass, fail, softfail, neutral, none, temperror ya da permerror olur.

Zarf göndericisi çoğu zaman insanların gördüğü adres değildir. Bülten ve bilet hizmetleri genellikle kendi bounce alan adlarını kullanır; böylece SPF onlar için geçer ama sizin From adresiniz hakkında hiçbir şey söylemez. DMARC, SPF alan adının From alan adıyla hizalı olmasını isteyerek ikisini birbirine bağlar.

Alıcı, zarf göndericisinin alan adını alır, o alan adının SPF kaydını çeker, mekanizmaları soldan sağa bağlanan IP'ye karşı değerlendirir ve bir sonuç döndürür.

Bir SPF kaydını okumak

Kayıt, soldan sağa değerlendirilen ve her biri isteğe bağlı bir niteleyici taşıyan mekanizmalardan oluşur. Gönderen IP ile eşleşen ilk mekanizma sonucu belirler; bu yüzden sıra yalnızca hangi niteleyicinin geçerli olacağını etkiler. Kayıt, listelenmeyen her şeye ne olacağını belirlemek için all ile bitmelidir.

Mekanizmalar ve değiştiriciler
Terim	Ne zaman eşleşir	DNS sorgusu
`ip4:192.0.2.0/24`	Gönderen IP, IPv4 aralığındadır	Hayır
`ip6:2001:db8::/32`	Gönderen IP, IPv6 aralığındadır	Hayır
`a` / `a:host.example.com`	IP, alan adının ya da makinenin A/AAAA adresidir	Evet
`mx`	IP, alan adının MX makinelerinden birinin adresidir	Evet
`include:_spf.example.net`	Diğer alan adının SPF kaydı pass döndürür	Evet
`exists:%{i}.example.net`	Oluşturulan adın sorgusu herhangi bir A kaydı döndürür	Evet
`ptr`	Ters DNS eşleşir; kullanımdan kalktı, kullanmayın	Evet
`all`	Her zaman; son varsayılan olarak kullanılır	Hayır
`redirect=example.net`	Değiştirici: onun yerine başka bir alan adının kaydını kullan	Evet

Niteleyiciler
Niteleyici	Sonuç	Tipik kullanım
`+` (varsayılan)	pass	Listelenen göndericiler
`-`	fail	`-all`: geri kalan her şeye izin yok
`~`	softfail	`~all`: izin yok, ama yumuşak davran
`?`	neutral	Beyan yok; hiçbir koruma sağlamaz

SPF bulguları ne anlama gelir

E-posta Güvenliği'ndeki SPF bulguları
Bulgu	Önem	Düzeltme
SPF kaydı bulunamadı	Kritik	Göndericilerinizi listeleyen ve `-all` ya da `~all` ile biten tek bir kayıt yayımlayın.
Birden fazla SPF kaydı	Kritik	Birleştirin; iki `v=spf1` kaydı permerror'a yol açar.
n DNS sorgusu (sınır 10)	Kritik	include'ları kaldırın ya da yeniden düzenleyin; sorgu sınırı rehberine bakın.
+all her sunucuya izin veriyor	Kritik	`+all` yerine `-all` ya da `~all` kullanın.
Geçersiz adres / Bilinmeyen mekanizma	Kritik	Yazım hatasını düzeltin; bir söz dizimi hatası kaydın tamamını geçersiz kılar.
?all hiçbir koruma sağlamıyor	Uyarı	`~all` ya da `-all` kullanın.
all mekanizması yok	Uyarı	Kaydı `~all` ya da `-all` ile bitirin.
all sonrasındaki terimler yok sayılır	Uyarı	Onları `all` öncesine taşıyın.
ptr mekanizması kullanımdan kalktı	Uyarı	`ip4`/`ip6` ya da `a` ile değiştirin.
SPF kaydı olmayan include'lar	Uyarı ya da kritik	Hiçbir şeyi göstermeyen include'ları kaldırın; ikiden fazlası permerror'a yol açar.

Sorgu sayacı sekizde uyarır. Bu, bir sağlayıcının kendi kaydına iç içe bir include eklediği ve sizin tarafınızda hiçbir değişiklik olmadan sayınızı yükselttiği gün için pay bırakır. 10 sorgu sınırı rehberi bu sayıyı nasıl düşüreceğinizi anlatır.

SPF için hangi alan adını kontrol etmeli

SPF, zarf göndericisi için değerlendirilir; bu yüzden kontrol edilecek doğru alan adı, teslim edilmiş bir iletinin Return-Path başlığındaki alan adıdır. Doğrudan posta sağlayıcınızdan gönderilen e-postalarda bu genellikle kendi alan adınızdır. Bülten, bilet ve faturalama araçlarında ise çoğu zaman bounces.example.com gibi bir bounce alan adı ya da hizmete ait bir alan adıdır.

Her sistemden gelen yeni bir iletiyi açın, Return-Path ve Authentication-Results başlıklarına bakın ve her zarf alan adını sırayla kontrol edin. E-posta Başlığı Analizi her iki alanı ve alıcının kaydettiği SPF sonucunu gösterir. Sonuç size ait olmayan bir alan adı için pass ise SPF o hizmet için çalışıyordur, ama sizin DMARC değerlendirmenize sayılmaz.

Alıcılar, bounce iletilerinde olduğu gibi zarf göndericisi boş olduğunda bağlanan sunucunun HELO adı için de SPF kontrol eder. Bu yüzden mail.example.com gibi posta sunucusu adlarının kendine ait küçük bir SPF kaydı olmalıdır, örneğin v=spf1 a -all.

Yaygın SPF hataları

Yeni sağlayıcı için ikinci bir kayıt eklemek

Kurulum talimatları çoğu zaman “şu TXT kaydını ekleyin” der ve birincinin yanında ikinci bir v=spf1 kaydı belirir. Bunun yerine yeni include'u var olan kaydın içine ekleyin.

; wrong: two records
example.com. IN TXT "v=spf1 include:_spf.mail.example.net -all"
example.com. IN TXT "v=spf1 include:esp.example.net -all"

; right: one record
example.com. IN TXT "v=spf1 include:_spf.mail.example.net include:esp.example.net -all"

Her şeyi bozan yazım hataları

inlcude:, ip4:192.0.2.0/33 ya da eksik bir iki nokta söz dizimi hatasıdır. Alıcılar yalnızca bozuk terim için değil kaydın tamamı için permerror döndürür; yani tek bir yazım hatası tüm e-postanız için SPF'i devre dışı bırakır.

Yalnızca SPF'e güvenmek

Bir ileti yönlendirildiğinde SPF başarısız olur, çünkü yönlendiren sunucu sizin kaydınızda yoktur. DMARC'ın geçmeyi sürdürmesi için her gönderici sistemde kendi alan adınızla DKIM imzalamayı yapılandırın. DMARC rehberi ikisinin nasıl birleştiğini anlatır.

Hiç e-posta göndermeyen alan adlarını unutmak

Park edilmiş alan adları v=spf1 -all kaydını DMARC p=reject kaydıyla birlikte yayımlamalıdır. Bunlar olmadan alan adı taklit için kolay bir hedeftir, çünkü alıcıların karşılaştıracağı hiçbir şey yoktur.

Kullandığınızdan çok daha fazlasına izin vermek

Eski belgelerden kopyalanmış bütün bir /16 gibi geniş aralıklar ya da bir barındırma sağlayıcısının tamamı için eklenen include, o ağın her müşterisinin sizin adınıza SPF geçmesine izin verir. En dar aralıkları ya da hizmetinizin belgelediği sağlayıcıya özel include'u listeleyin ve barındırma değiştirdiğinizde bunları gözden geçirin.

DKIM: seçiciyi bulmak ve anahtarı değerlendirmek

DKIM her iletiyi özel bir anahtarla imzalar ve açık anahtarı DNS'te bir seçici altında yayımlar: selector1._domainkey.example.com. DNS'te bir alan adının kullandığı seçicileri veren bir liste yoktur; bu yüzden E-posta Güvenliği, büyük sağlayıcıların ve gönderim hizmetlerinin kullandığı 24 adı (örneğin google, selector1, selector2, k1, s1 ve mandrill) ve girdiğiniz seçiciyi dener. Hiçbir şey bulamayan bir tarama DKIM'in olmadığının kanıtı değildir; bu yüzden başarısız değil, iyileştirme gereken sayılır.

Bulunan her anahtar için araç açık anahtarı çözer, türünü ve boyutunu bildirir. RFC 8301, 1024 bitten kısa RSA anahtarlarını yasaklar ve 2048 biti önerir; 1024 bitlik bir anahtar uyarı doğurur. t=y bayrağı anahtarın test modunda olduğunu ve alıcıların imzayı yok sayabileceğini, boş bir p= ise anahtarın bir değişim sonrasında iptal edildiğini gösterir.

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

DKIM seçicileri ve anahtar değişimi rehberi, DNS'e sığan 2048 bitlik anahtarları nasıl yayımlayacağınızı ve yoldaki e-postaların imzalarını bozmadan bunları nasıl değiştireceğinizi anlatır.

MTA-STS ve TLS-RPT

Posta sunucuları STARTTLS ile ancak iki taraf da onu sunduğunda şifreler; ağ yolundaki bir saldırgan bu sunuşu kaldırabilir. MTA-STS, posta sunucularınızın her zaman geçerli bir sertifikayla TLS desteklediğini beyan etmenizi sağlar. İki parçası vardır: _mta-sts.example.com altında bir id taşıyan TXT kaydı ve mta-sts.example.com üzerinden HTTPS ile sunulan bir politika dosyası.

E-posta Güvenliği politikayı gönderen sunucuların yaptığı gibi çeker: HTTPS üzerinden, sertifika doğrulamasıyla ve RFC 8461 §3.3'ün gerektirdiği gibi yönlendirmeleri izlemeden. version, mode, max_age değerlerini ve yayımlanan her MX makinesinin bir mx satırıyla eşleşip eşleşmediğini kontrol eder. Zorlama modunda politikanın kapsamadığı bir MX makinesi kritiktir, çünkü MTA-STS'e uyan göndericiler oraya teslim etmeyi reddeder.

version: STSv1
mode: testing
mx: mx1.example.com
mx: *.mail.example.com
max_age: 604800

TLS-RPT, gönderen sunuculardan TLS hatalarını her gün _smtp._tls.example.com içindeki adrese bildirmelerini ister. MTA-STS'i testten zorlamaya almadan önce bunu yayımlayın ki sorunları e-posta reddedilmeye başlamadan görün. MTA-STS ve TLS-RPT rehberi kurulumu adım adım anlatır.

BIMI

BIMI, default._bimi.example.com altında bir logo yayımlar; bazı posta sağlayıcıları bunu kimliği doğrulanmış e-postanın yanında gösterir. İsteğe bağlıdır ve puandaki ağırlığı en küçük olanıdır. Sağlayıcılar logoyu yalnızca DMARC p=quarantine ya da p=reject ile zorlanıyorsa, logo HTTPS üzerinden sunulan bir SVG Tiny PS dosyasıysa ve Gmail ile Apple Mail için a= içinde bir Verified Mark Certificate ya da Common Mark Certificate listeleniyorsa gösterir.

E-posta Güvenliği, eksik bir kaydı sorun olarak değil not olarak bildirir ve DMARC zorlanmıyorken bir BIMI kaydı varsa uyarır. Sertifika maliyetinin buna değip değmediği BIMI ve VMC rehberi içinde tartışılıyor.

SSS

DMARC için hem SPF hem DKIM gerekli mi?

Hayır. Bir ileti, SPF ya da DKIM hizalı biçimde geçtiğinde DMARC'ı geçer. Yine de ikisini birden kurun: SPF yönlendirilen e-postalarda sık sık başarısız olur ve o iletilerin geçmeyi sürdürmesini sağlayan şey DKIM'dir.

p=reject kendi bültenlerimi ya da faturalarımı engeller mi?

Yalnızca o hizmetler hizalı bir SPF ya da DKIM sonucu olmadan gönderiyorsa. p=none aşamasında toplu raporları okuyun, her hizmette kendi alan adınızla DKIM'i yapılandırın ve zorlamaya ancak meşru e-posta geçtiğinde geçin.

DMARC'taki DNS değişiklikleri ne kadar sürede uygulanır?

Alıcılar yeni kaydı, önbellekteki yanıtların süresi dolduğunda görür; bu süre eski kaydın TTL değeridir (çoğu zaman bir saat ya da daha az). Kontrol aracı XGM çözümleyicisini doğrudan sorgular, bu yüzden değişikliği genellikle hemen gösterir.

rua ile ruf arasındaki fark nedir?

rua, gönderen IP ve sonuç başına sayıları içeren günlük toplu XML raporlarını alır. ruf ise ileti başlıklarını içerebilen tekil hata raporlarını alır; gizlilik kaygıları yüzünden büyük sağlayıcıların pek azı gönderir.

Alt alan adlarının kendi DMARC kaydı olmalı mı?

Şart değil. Kaydı olmayan alt alan adları üst alan adının sp değerini, sp yoksa p değerini kullanır. Ayrı bir kaydı yalnızca bir alt alan adı farklı bir politika ya da rapor adresi gerektirdiğinde yayımlayın.

DMARC oltalamayı durdurmaya yeter mi?

Alan adının birebir taklidini durdurur. examp1e.com gibi benzeyen alan adları kapsam dışıdır; bu yüzden kullanıcı farkındalığı ve benzer kayıtların izlenmesi hâlâ gereklidir.

SPF kaydını nereye yayımlamalıyım?

Zarf göndericisinde kullanılan alan adı altında bir TXT kaydı olarak, genellikle example.com gibi kök alan adına. Kendi bounce adresiyle e-posta gönderen alt alan adlarının kendi kaydı olmalıdır.

Alt alan adları için SPF kaydım olabilir mi?

Evet. SPF tam olarak zarf alan adı için sorgulanır ve alt alan adları üst alan adının kaydını devralmaz. Gönderim yapan her alt alan adının kendi kaydı olmalıdır.

Kaydı ~all ile mi -all ile mi bitirmeliyim?

DMARC zorlanıyorken ikisi de güçlü koruma sağlar, çünkü sonucu DMARC belirler. Listeniz tamamlandığında -all daha açık bir beyandır.

SPF neden geçiyor da DMARC başarısız oluyor?

SPF, From adresiyle hizalı olmayan bir alan adı için geçmiştir; bu genellikle bir gönderim hizmetinin bounce alan adıdır. O hizmette kendi alan adınızla DKIM'i ya da özel bir bounce alan adını yapılandırın.

SPF TXT kayıt türü hâlâ var mı?

Hayır. Kendine ait SPF kayıt türü RFC 7208 ile kaldırıldı; SPF'i yalnızca TXT kaydı olarak yayımlayın.

Değişiklikler ne kadar çabuk etkili olur?

Eski kaydın önbellekteki kopyalarının süresi dolduğunda; bu da kaydın TTL değerine bağlıdır. Kontrol aracı doğrudan sorgular ve yeni kaydı genellikle anında gösterir.

E-posta Güvenliği neden DKIM anahtarımı bulamıyor?

Seçiciyi posta sağlayıcınız seçer ve bu bilgi hiçbir yerde yayımlanmaz. Gönderdiğiniz bir iletiyi açın, DKIM-Signature başlığındaki s= etiketini bulun ve o değeri seçici olarak girin.

DMARC zorlanıyorsa MTA-STS'e ihtiyacım var mı?

İkisi farklı şeyleri korur. DMARC, başkalarının sizin alan adınızla göndermesini engeller; MTA-STS ise posta sunucularınıza şifreli bağlantıyı zorunlu kılarak saldırganların alan adınıza gönderilen e-postaları okumasını ya da değiştirmesini engeller.

Kaynaklar

Araçlar

E-posta Güvenliği Bir alan adı için SPF, DKIM, DMARC, MTA-STS, TLS-RPT ve BIMI'yi kontrol edin ve bunları düzeltecek kayıtları alın.
MX ve SMTP Bir alan adının e-posta sunucularını kontrol edin; SMTP bağlantılarını, STARTTLS'i ve açık aktarımı test edin.
Kayıt Oluşturucular SPF, DMARC, BIMI, MTA-STS ve TLS-RPT kayıtlarını, meta etiketlerini ve robots.txt dosyasını yazdıkça yapılan canlı kontrollerle oluşturun.
Alan Adı Sağlığı DNS, e-posta kimlik doğrulaması, TLS, güvenlik başlıkları ve yönlendirmeler için tek kontrol; her alan için bir not ve tam rapor.
E-posta Başlığı Analizi Teslimat adımlarını izleyin, SPF, DKIM ve DMARC sonuçlarını okuyun ve bunların From adresini gerçekten kapsayıp kapsamadığını görün.

Rehberler

The SPF 10-lookup limit: diagnosis and flattening Why SPF fails with permerror after ten DNS lookups, how to count them including nested includes, and safer alternatives to flattening your record.
DMARC: from p=none to p=reject in 30 days A week-by-week plan to move a domain from DMARC monitoring to full enforcement without blocking your own invoices, newsletters or support mail.
How to read DMARC aggregate reports What is inside a DMARC rua report, how to tell your own senders from forwarding and spoofing, and how to summarise the XML in your browser.
DKIM: selectors, key rotation and 2048-bit keys How DKIM selectors work, how to publish 2048-bit keys that fit in DNS, and a rotation procedure that never breaks signatures on mail in transit.
MTA-STS and TLS-RPT: step-by-step setup Require encrypted delivery to your mail servers with MTA-STS (RFC 8461) and see TLS failures with TLS-RPT (RFC 8460), from testing mode to enforce.
BIMI and VMC: is it worth it? What BIMI shows in the inbox, the DMARC and logo requirements, VMC versus CMC certificates, the costs and a checklist for deciding whether to adopt it.
Email deliverability checklist (2026) The DNS, authentication, infrastructure and list practices that decide whether your mail reaches the inbox, with a check for each item.