SPF DKIM DMARC Nasıl Kurulur? Kurumsal E-postalar Spam'e Düşmesin

SPF DKIM DMARC nasıl kurulur ve üçü ne işe yarar?

SPF, DKIM ve DMARC, alan adınızdan çıkan e-postanın gerçekten size ait olduğunu alıcı sunucuya kanıtlayan üç DNS kaydıdır. Kurulum sırası şudur: önce adınıza gönderen tüm servisleri listeleyin, sonra SPF ve DKIM kayıtlarını ekleyin, en son DMARC'ı p=none ile açıp raporlara bakarak politikayı kademeli sıkılaştırın.

Bunu bir davetiye kontrolüne benzetebilirsiniz. İlk olarak SPF (Sender Policy Framework), kapıdaki konuk listesidir: hangi sunucuların sizin adınıza gönderebileceğini yazar. DKIM (DomainKeys Identified Mail) mektubun üzerindeki mühürdür; yani iletinin yolda değişmediğini ve imzanın alan adınıza ait olduğunu gösterir. Son olarak DMARC (Domain-based Message Authentication, Reporting and Conformance) kapı görevlisine verdiğiniz talimattır. Üstelik liste ya da mühür tutmazsa ne olacağını söyler ve size rapor gönderir.

Bu rehber, gönderdiği kurumsal e-postalar spam klasörüne düşen ya da reddedilen işletmelere yöneliktir. Gmail'de bir hata kodu görüyorsanız önce Gmail 550 5.7.26 hatası yazımıza bakın. Bu yazı ise kalıcı kurulumu, yani hata gelmeden önce yapmanız gereken işi anlatır. Ayrıca kayıt örneklerinde alan adı olarak yalnızca example.com kullanıyoruz, değerleri ise resmi belgelerden alıyoruz.

E-postalarınız neden spam klasörüne düşer ya da reddedilir?

Alıcı sunucu bir iletiyi kabul etmeden önce şunu sorar: bu alan adı adına gönderme yetkisi bu sunucuda var mı? Cevabı sizin DNS kayıtlarınızda arar. Kayıt yoksa ya da yanlışsa alıcı iletiyi şüpheli bulur. Bu yüzden içerik ne kadar temiz olursa olsun ileti spam klasörüne düşebilir.

Google'ın e-posta gönderici yönergeleri bu konuda nettir: kişisel Gmail adreslerine gönderen herkesin SPF veya DKIM kurması gerekir. Günlük hacmi yüksek göndericilerden ise SPF, DKIM ve DMARC'ın üçünü birden bekler. Öte yandan Yahoo da toplu göndericiler için benzer koşullar yayımlıyor. Ancak hacim eşiklerinin güncel değerini ilgili resmi sayfalardan kontrol edin, çünkü zamanla değişebilir.

Sonuç olarak kimliği doğrulanmayan iletiler spam klasörüne düşer ya da 5.7.26 gibi bir kodla geri döner. Yani sorun çoğu zaman içerikte değil, kimliktedir. Teslimatı etkileyen diğer etkenleri ayrıca e-posta teslimat oranı rehberimizde anlattık. Gönderen IP adresinin ters DNS kaydı da ayrı bir şarttır; onu PTR kaydı yazımızda bulursunuz.

SPF, DKIM ve DMARC arasındaki fark nedir ve birlikte nasıl çalışır?

Üçü birbirinin yerine geçmez, çünkü her biri başka bir soruya cevap verir. Aşağıdaki tablo farkları tek bakışta gösterir. Tabloda geçen TXT, DNS'te metin saklayan kayıt türüdür. CNAME ise bir adı başka bir ada yönlendiren kayıttır.

Kısacası SPF ve DKIM kanıt üretir, DMARC bu kanıtları From adresiyle eşleştirip karar verir. Alıcı sunucu şu sırayı izler:

1. İlk olarak zarf gönderen alan adının SPF kaydına bakar. Gönderen IP listede varsa SPF geçer.
2. Ardından iletideki DKIM imzasını DNS'teki açık anahtarla doğrular.
3. Daha sonra iki sonucu From alan adıyla karşılaştırır; bu karşılaştırmaya hizalama (alignment) denir.
4. Son olarak SPF ya da DKIM'den biri hizalı geçerse DMARC geçer. Aksi halde sizin politikanız devreye girer.

İletinin sunucudan sunucuya nasıl yol aldığını merak ediyorsanız MTA ve SMTP relay yazımıza göz atın.

SPF DKIM DMARC nasıl kurulur: önce hangi hazırlığı yaparsınız?

Kuruluma başlamadan iki şeyi netleştirin: adınıza kimler e-posta gönderiyor ve DNS'i kim yönetiyor. Bu iki cevap hazır olduğunda gerisi çok daha kolaydır, çünkü kalan adımlar mekaniktir. Kurulumu şu sırayla yürütün:

1. Adınıza e-posta gönderen tüm servisleri listeleyin.
2. DNS kayıtlarını hangi panelde yönettiğinizi bulun.
3. Mevcut SPF, DKIM ve DMARC kayıtlarını kontrol edin, değerlerini bir yere not edin.
4. Tek bir SPF kaydı oluşturun ya da mevcut kaydı güncelleyin.
5. Her gönderen servis için DKIM'i açın.
6. DMARC kaydını p=none ve bir rapor adresiyle yayımlayın.
7. Raporları okuyun, hizalanmayan meşru kaynakları düzeltin.
8. Hazır olduğunuzda politikayı quarantine, uygunsa reject seviyesine yükseltin.

Google Workspace kullanan örnek bir alan adında sonuç şuna benzer (anahtar kısaltılmıştır):

@                 TXT  v=spf1 include:_spf.google.com ~all
google._domainkey TXT  v=DKIM1; k=rsa; p=MIIBIjANBgkq...
_dmarc            TXT  v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Sıranın mantığı basittir. DMARC'ı en son açarsınız, çünkü SPF ve DKIM eksikken sıkı bir DMARC politikası meşru iletileri de engelleyebilir. Üstelik ilk günlerde p=none kullandığınız için teslimat değişmez, yalnızca rapor toplarsınız. RFC 9989, eski RFC 7489'un yerini alan güncel DMARC standardıdır. Standart da önce p=none ile başlamayı, ardından raporlara bakmayı önerir.

Adınıza e-posta gönderen servisleri nasıl listelersiniz?

Bu adım atlandığında kurulum yarım kalır. Çünkü sahada en sık gördüğümüz sorun, kimsenin hatırlamadığı bir servisin sessizce adınıza e-posta göndermesidir. Listenize şu kaynakları ekleyin:

• Ana e-posta sağlayıcınız: Google Workspace, Microsoft 365 ya da barındırma firmasının posta sunucusu.
• Web sitenizin iletişim, teklif ve sipariş formları.
• Bülten ve pazarlama otomasyonu araçları.
• CRM, teklif ve fatura programları.
• Destek talebi ve randevu sistemleri.
• E-ticaret altyapısı ve ödeme bildirimleri.
• Tarayıcı, yazıcı gibi cihazlar ve eski sunucu betikleri.

Listeyi tamamlamak için önce her ekibe sorun. Ardından yakın zamanda gönderdiğiniz birkaç iletinin başlığını inceleyin ve geri dönen (bounce) iletilere bakın. Ayrıca her kaynak için üç şeyi yazın: hangi alan adıyla gönderiyor, SPF için ne istiyor, DKIM'i nasıl açıyor. Yine de unuttuğunuz bir kaynak olursa DMARC raporları sonunda onu ortaya çıkarır.

DNS kayıtlarını nerede yönettiğinizi nasıl bulursunuz?

Kayıtları yanlış panele eklemek, sahada en çok zaman kaybettiren hatadır. Kayıt orada durur ama hiçbir etkisi olmaz. Çünkü alıcı sunucular yalnızca alan adının ad sunucularında (name server) yayımlanan kayıtları okur. Yani ad sunucularınız hangi firmayı gösteriyorsa kayıtları orada eklersiniz.

Bunu iki adımda öğrenirsiniz. DNS sorgulama aracımızla alan adınızın NS kayıtlarına bakın. Ardından Whois sorgulama aracımızla alan adının hangi kayıt firmasında durduğunu görün.

Ad sunucuları kayıt firmanızı, barındırma sağlayıcınızı ya da ayrı bir DNS hizmetini gösterebilir. Örneğin siteniz bir sunucuda durabilir, DNS ise başka bir yerde olabilir. Bu durumda sunucudaki panelde gördüğünüz kayıt sizi yanıltır, çünkü alıcılar o kaydı hiç sorgulamaz. Ayrıca panele giriş bilginiz yoksa önce erişimi geri almanız gerekir.

SPF kaydını nasıl oluşturursunuz?

SPF kaydı, alan adınızın kök seviyesine eklediğiniz tek bir TXT kaydıdır. Kayıt v=spf1 ile başlar, yetkili kaynakları sıralar ve bir kuralla biter. Örneğin yalnızca Google Workspace kullanan bir işletme için Google'ın yardım sayfasındaki kayıt şöyledir:

v=spf1 include:_spf.google.com ~all

Buradaki include, Google'ın gönderen sunucu listesini kayda dahil eder. ~all ise listede olmayan kaynakları büyük olasılıkla yetkisiz sayar. Yeni bir servis eklediğinizde ikinci bir kayıt oluşturmazsınız, aynı kayda yeni bir include eklersiniz:

v=spf1 include:_spf.google.com include:servis.example.com ~all

Buradaki servis.example.com, bülten aracınızın yardım sayfasının vereceği değerin yer tutucusudur. Ancak her zaman aynı kuralı hatırlayın: bir alan adında tek SPF kaydı olmalıdır. Nitekim RFC 7208 birden fazla kayıt bulunmasını yasaklar, Microsoft belgesi de bu durumda SPF'nin permerror döndürdüğünü belirtir.

Kaydı eklerken ad (host) alanına çoğu zaman @ yazarsınız, bazı paneller ise alan adının kendisini ister. Ayrıca bazı paneller değeri tırnak içinde bekler, bu ayrıntı için panelinizin yardım sayfasına bakın.

Üç yazım hatasına dikkat edin: include: yerine include= yazmak, iki noktadan sonra boşluk bırakmak ve alan adının sonuna nokta koymak. Ayrıca bulten.example.com gibi bir alt alan adı kullanıyorsanız ona ayrı bir SPF kaydı gerekir, çünkü kök kayıt alt alan adlarını kapsamaz.

SPF kaydındaki 10 DNS sorgusu sınırı nedir?

RFC 7208, bir SPF değerlendirmesinde DNS sorgusu yapan terimlerin toplamını 10 ile sınırlar. Standart include, a, mx, ptr, exists ve redirect terimlerini sorgu olarak sayar. ip4, ip6 ve all ise sayaca girmez. Dolayısıyla sınırı aşan bir kayıt permerror üretir ve SPF doğrulaması çalışmaz.

Ama asıl tuzak iç içe include'lardır. Bir include kendi içinde başka include'lar açabilir ve hepsi toplama girer. Kayıtta yalnızca üç include görürsünüz, ama sayaç bunun çok üstüne çıkmış olabilir. Nitekim Microsoft belgesi de include sayısının az olmasının sorgu sayısının az olacağını garanti etmediğini söyler. Alıcılar kaydı soldan sağa okur ve kaynağı bulduğu yerde durur. Bu yüzden hata bazı alıcılarda ortaya çıkmaz, bazılarında ise ileti geri döner.

Sınıra yaklaştığınızda şu adımları deneyin:

• Kullanmadığınız servislerin include satırlarını silin.
• Yoğun gönderim yapan servisleri bir alt alan adına taşıyın, çünkü her alt alan adının kendi 10 sorgu hakkı vardır.
• Sabit IP aralığını belgeleyen bir sağlayıcı için include yerine ip4 yazabilirsiniz, ancak sağlayıcı aralığı değiştirdiğinde kaydı güncellemeniz gerekir.
• ptr terimini hiç kullanmayın, çünkü RFC 7208 bu terimin yayımlanmamasını önerir.

Ayrıca ücretsiz SPF DKIM DMARC kontrol aracımız mevcut sorgu sayınızı numaralı bir ağaç olarak gösterir.

SPF kaydında ~all mı -all mı kullanmalısınız?

İkisi de geçerlidir ve büyük sağlayıcılar farklı öneriler verir. Google yardım sayfası ~all (yumuşak ret, softfail) kullanmanızı önerir. Microsoft belgeleri ise DKIM ve DMARC ile birlikte -all (sert ret, hardfail) önerir.

Öte yandan RFC 9989 bu seçimin bir riskini hatırlatır. Bazı alıcılar SPF başarısız olunca iletiyi DMARC'a bakmadan SMTP aşamasında geri çevirebilir. Böylece DKIM ile DMARC'ı geçecek bir ileti bile kaybolur ve DMARC raporlarında hiç yer almaz.

Bu nedenle pratik önerimiz şudur: tüm gönderenleri doğrulayana kadar ~all ile kalın. Daha sonra, DKIM ve DMARC çalıştığında -all'a geçip geçmeyeceğinize raporlara bakarak karar verin. İletme kuralları kullanan alan adlarında ~all daha güvenlidir, çünkü iletilen iletide SPF çoğu zaman geçmez ve -all bazı alıcılarda DKIM'e fırsat vermeden ret getirebilir.

Ancak e-posta göndermeyen alan adlarında durum farklıdır. Kullanmadığınız bir alan adı için v=spf1 -all kaydı yayımlayabilirsiniz, Microsoft belgesi de bunu önerir. Böylece kimse o alan adı adına gönderemez. Ayrıca ?all (neutral) yalnızca testler içindir, Microsoft belgesi üretimde önermez.

DKIM anahtarını nasıl üretip DNS'e eklersiniz?

DKIM'de iki anahtar vardır. Gönderen sistem özel anahtarla iletiyi imzalar, siz de açık anahtarı DNS'e yayımlarsınız. Alıcı bu açık anahtarla imzayı doğrular. Anahtar çiftini çoğunlukla e-posta sağlayıcınızın panelinde üretirsiniz, bu yüzden her gönderen servis için ayrı kurulum yaparsınız.

1. Gönderen servisin panelinde DKIM ya da alan adı doğrulama bölümünü açın ve alan adınızı seçin.
2. Panelin verdiği kayıt adını (host) ve değerini kopyalayın. Örneğin Google'da bu bir TXT kaydı, Microsoft 365'te iki CNAME kaydıdır.
3. Ardından DNS yönetim ekranında kaydı birebir ekleyin, yazımı ve satır sonlarını değiştirmeyin.
4. DNS'in yayılmasını bekleyin, sonra panelde imzalamayı etkinleştirin ya da doğrulayın.
5. Son olarak test iletisi gönderin ve başlıkta dkim=pass sonucunu arayın.

Kayıt adı seçici._domainkey.example.com biçimindedir. Seçici (selector), aynı alan adı için birden çok anahtarın yan yana durmasını sağlar. Nitekim RFC 6376 bunu anahtar yenilemeyi kolaylaştırmak için tanımlar. Örneğin Google'ın varsayılan seçicisi google'dır. Anahtar uzunluğunda sağlayıcınızın desteklediği en uzun seçeneği seçin. Google da daha uzun anahtarın daha güvenli olduğunu belirtir. Anahtarı yenilerken ise yeni bir seçici yayımlayın ve eskisini geçiş bitene kadar silmeyin.

DKIM seçici (selector) hatasını nasıl çözersiniz?

DKIM kaydı varken sonuç hâlâ başarısızsa suçlu genellikle seçici, kayıt adı ya da değerdir. Şu sırayla kontrol edin:

• Seçici eşleşmesi: test iletisinin başlığında DKIM-Signature satırındaki s= ve d= değerlerini bulun. DNS'te tam olarak s._domainkey.d adında bir kayıt olmalıdır.
• Çift alan adı: bazı DNS panelleri alan adını kendisi ekler. Bu yüzden tam adı yazarsanız google._domainkey.example.com.example.com gibi hatalı bir kayıt oluşur. Böyle bir panelde yalnızca google._domainkey yazın.
• Eksik anahtar: uzun değeri kopyalarken sonunu kaçırmış, satır sonu ya da fazladan tırnak eklemiş olabilirsiniz. Ayrıca bir DNS dizesi en çok 255 karakter taşır, bu yüzden uzun anahtarlar parçalara bölünür. Bazı paneller bunu kendisi yapar, bazıları parçaları ayrı girmenizi ister.
• Kapalı imzalama: kayıt doğru olsa bile servisin panelinde imzalamayı açmayı unutmuş olabilirsiniz.
• Yanlış alan adıyla imza: servis iletiyi kendi alan adıyla imzalıyorsa DKIM geçer ama sizin alan adınızla eşleşmez.
• Çift kayıt: RFC 6376 her seçici için tek bir TXT kaydı bekler.

Düzeltmeden sonra sonucu hemen göremeyebilirsiniz, çünkü DNS önbellekleri eski değeri bir süre tutar. Bu yüzden kaydı tekrar tekrar değiştirmeyin. Bekleyin ve yeniden test edin.

DMARC kaydını nasıl oluşturursunuz ve p=none ne demektir?

DMARC kaydı, alan adınızın altındaki _dmarc adında bir TXT kaydıdır. İlk olarak raporları alacağınız bir adres hazırlayın. Çünkü rapor akışı yoğun olabilir; Google kişisel adres yerine ayrı bir posta kutusu ya da grup kullanmanızı önerir. Ardından kaydı ekleyin:

Ad: _dmarc.example.com
Tür: TXT
Değer: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

v=DMARC1 ilk etiket olmalıdır. p politikayı belirler, rua ise toplu raporların gideceği adrestir. p=none, iletilere dokunma, yalnızca raporla demektir. RFC 9989 bu politikanın mevcut posta işleyişini değiştirmemesi gerektiğini söyler.

Rapor adresi başka bir alan adındaysa, o alan adının sizin için rapor almayı onaylayan bir DNS kaydı yayımlaması gerekir. Buna karşılık aynı alan adındaki bir adres bu adımı gerektirmez. Dahası, DMARC kaydı kendi kaydı olmayan alt alan adlarını da kapsar. Ayrı bir alt alan adı politikası için sp etiketini kullanırsınız.

Son olarak sıra önemlidir: SPF ve DKIM kayıtlarının yayılmasını bekledikten sonra DMARC'ı ekleyin.

Hizalama (alignment) nedir, DMARC neden başarısız olur?

Hizalama, SPF ya da DKIM'in doğruladığı alan adının ekranda görünen From alan adıyla eşleşmesidir. Gevşek (relaxed) modda iki alan adı aynı ana alan adını (organizational domain) paylaşıyorsa yeterlidir. Örneğin news.example.com ile example.com gevşek modda eşleşir. Buna karşılık sıkı (strict) modda alan adları birebir aynı olmalıdır. Varsayılan gevşek moddur ve çoğu işletme için yeterlidir.

Özellikle SPF için DMARC, HELO bilgisine değil, zarf gönderen (MAIL FROM) alan adına bakar. DKIM için ise imzadaki d= alan adına bakar. Sonuç olarak ikisinden biri hizalı geçerse DMARC geçer.

Örnek senaryo: info@example.com adresinden bir bülten gidiyor. Bülten aracı zarf göndereni olarak kendi alan adını kullanıyor ve imzayı da kendi alan adıyla atıyor. SPF ve DKIM ayrı ayrı geçer, ama ikisi de example.com ile eşleşmediği için DMARC başarısız olur.

Çözüm basittir. Aracın panelinde özel alan adı doğrulamasını açın. Böylece servis iletiyi sizin alan adınızla da imzalar ve DKIM eşleşir. Nitekim Microsoft belgesi, birçok barındırılan e-posta servisinin önce kendi alan adıyla imzaladığını, müşteri ayarladıktan sonra ise müşterinin alan adıyla da imzaladığını anlatır.

DMARC raporlarını nasıl okursunuz?

Toplu (aggregate) raporlar, alıcı posta sistemlerinin gönderdiği XML dosyalarıdır. Çoğu zaman küçük bir sıkıştırma dosyası olarak gelir ve alıcılar genellikle günde bir kez gönderir. Raporu elle okuyabilirsiniz, ancak RFC 9989 makineyle ayrıştırmayı önerir. Bunun için rapor işleyen araçlar ve hizmetler vardır. Her raporda şu bilgileri bulursunuz:

• Raporu gönderen kuruluşun adı ve raporun tarih aralığı.
• Kaynak IP adresi ve o IP'den gelen ileti sayısı.
• DMARC değerlendirmesi: disposition (uygulanan işlem) ile hizalı DKIM ve SPF sonuçları.
• Ekranda görünen From alan adı.
• Ham doğrulama sonuçları: DKIM alan adı, seçici ve sonuç; SPF alan adı ve sonuç.

İlk olarak kaynakları IP adresine ya da servise göre gruplayın. Ardından tanıdığınız ve geçen kaynakları olduğu gibi bırakın. Tanıdığınız ama başarısız olan kaynakları hizalama ayarıyla düzeltin. Son olarak tanımadığınız ve çok ileti gönderen kaynaklara dikkat edin, çünkü bunlar sahte gönderim olabilir.

Başarısızlık (failure) raporları ayrı bir konudur. Gmail bunları desteklemez, çoğu alıcı da gizlilik nedeniyle göndermez. Üstelik toplu raporlar bile küçük işletmelerde gönderim alışkanlıklarını gösterebilir. Bu yüzden rapor kutusuna kimlerin eriştiğini belirleyin. Kişisel veri sorusu doğarsa bu yazı hukuki danışmanlık değildir, uzmanınıza danışın.

DMARC politikasını quarantine ve reject'e nasıl geçirirsiniz?

Geçişte acele etmeyin. Şu sırayı izleyin:

1. p=none ve rua ile başlayın, raporları toplayın.
2. Adınıza gönderen tüm meşru kaynaklar hizalı geçene kadar raporları izleyin.
3. Hizalanmayan her meşru kaynağı düzeltin.
4. Raporlar temizlendiğinde p=quarantine yapın ve sonuçları izlemeye devam edin.
5. Yalnızca gerçekten gerekiyorsa ve etkiyi anladıktan sonra p=reject yapın.

Ne kadar süreceği gönderim sıklığınıza bağlıdır. RFC 9989, bazı alan adlarında bu sürenin aylar alabileceğini belirtir. Bu yüzden takvim vermiyoruz, çünkü ölçüt sürenin kendisi değil, raporların temiz olmasıdır.

Bazı sağlayıcı belgeleri kademeli geçiş için pct etiketini anlatır. Buna karşılık RFC 9989 bu etiketi kaldırıp yerine test bayrağı olan t etiketini getirmiştir. Alıcıların hangisini desteklediği değişebilir. Bu nedenle sağlayıcınızın güncel belgesine bakın.

Ayrıca e-posta göndermeyen alan adlarında işiniz kolaydır: v=spf1 -all kaydını yayımlayın ve DMARC'ı p=reject ile açın.

Her işletme için p=reject doğru mu?

Her zaman değil. RFC 9989, p=reject politikasının dolaylı posta akışlarını bozabileceğini belirtir. Bu akışlara e-posta listeleri, rol tabanlı yönlendirmeler ve iletme kuralları girer. Çünkü iletme sırasında SPF çoğu zaman geçmez, DKIM ise ileti değişmezse geçerli kalır.

Standart iki net uyarı yapar:

• p=reject yayımlayan alan adları yalnızca SPF'ye güvenmemeli, iletilerini geçerli DKIM imzasıyla göndermelidir.
• Kullanıcıları e-posta listelerine yazabilecek alan adları p=reject yayımlamamalıdır. Yine de yayımlamak isteyenler önce en az bir ay p=none, ardından aynı süre p=quarantine ile etkiyi ölçmelidir.

Kısacası yalnızca sipariş bildirimi, form ve bülten gönderen bir alan adı reject'i değerlendirebilir. Öte yandan çalışanların her yere yazdığı genel amaçlı bir alan adında quarantine çoğu zaman daha akıllıca bir duraktır. Kararı raporlara bakarak verin.

Google Workspace'te SPF DKIM DMARC nasıl kurulur?

Google Workspace'te üç kaydın ikisini tamamen DNS'te yaparsınız. Yönetici konsolunda SPF ve DMARC için ayar yoktur, kayıtları alan adınızı yöneten yerde eklersiniz. DKIM ise konsoldan başlar. Alan adınızı Google iş ortağından aldıysanız bazı kayıtlar hazır gelebilir, bu yüzden önce mevcut kayıtlara bakın.

1. SPF: yalnızca Google kullanıyorsanız DNS'e v=spf1 include:_spf.google.com ~all yazın. Ancak başka gönderenleriniz varsa aynı kayda ekleyin.
2. DKIM: yönetici konsolunda Gmail ayarlarındaki e-posta kimlik doğrulama bölümünden alan adını seçin ve yeni kayıt üretin. Varsayılan seçici google'dır.
3. Panelin verdiği kayıt adını ve değeri DNS'e ekleyin. Kayıt adı google._domainkey biçimindedir, değer ise v=DKIM1; k=rsa; p= ile başlar.
4. Kayıt yayıldığında aynı bölümden kimlik doğrulamayı başlatın.
5. DMARC: DNS'e önceki bölümdeki _dmarc kaydını p=none ile ekleyin.

Test ederken kendinize ileti göndermeyin, çünkü Google DKIM'i bu yolla doğrulayamayacağınızı belirtir. Başka bir Gmail ya da Workspace adresine gönderin. Ayrıca Gmail'i yeni açtıysanız DKIM anahtarının konsolda hazır olması zaman alabilir. Ayrıntılar için Google Workspace Yönetici Yardımı'ndaki DKIM sayfası yararlıdır. Hangi sağlayıcıyı seçeceğinize henüz karar vermediyseniz Google Workspace mi Microsoft 365 mi karşılaştırmamıza bakın.

Microsoft 365'te SPF DKIM DMARC nasıl kurulur?

Microsoft 365'te SPF ve DMARC için yönetim portalında ya da PowerShell'de bir ayar yoktur. Bu iki kaydı alan adı kayıt firmasında ya da DNS hizmetinde oluşturursunuz. DKIM ise iki aşamalıdır.

1. SPF: yalnızca Microsoft 365 kullanıyorsanız DNS'e v=spf1 include:spf.protection.outlook.com -all yazın. Microsoft örnekte -all kullanır, bu seçimi SPF bölümünde tartıştık. Başka gönderenleriniz varsa aynı kayda ekleyin.
2. DKIM: özel alan adlarında imzalama kendiliğinden açık gelmez. Microsoft Defender portalındaki e-posta kimlik doğrulama ayarlarında DKIM sekmesinden alan adınızı seçin.
3. Portal iki CNAME kaydı gösterir: selector1._domainkey ve selector2._domainkey. Hedef değerleri portaldan birebir kopyalayın ve DNS'e ekleyin.
4. Portal kayıtları algıladığında imzalamayı açın.
5. DMARC: DNS'e _dmarc kaydını p=none ile ekleyin.

Hedef değerleri tahmin etmeyin. Çünkü Microsoft belgesi, yeni eklenen alan adlarında CNAME hedef biçiminin eskilerden farklı olabildiğini söyler. Belgedeki örnekler de yalnızca açıklama amaçlıdır. Ayrıntılar için Microsoft Learn'deki DKIM sayfası yararlıdır. Ayrıca her alt alan adı için ayrı DKIM yapılandırması gerektiğini unutmayın.

Barındırma sağlayıcısında ve cPanel'de SPF DKIM DMARC nasıl kurulur?

Sitenizi bir cPanel sunucusunda barındırıyorsanız panelde Email Deliverability ekranı bulunabilir. Bu ekran alan adlarınızın SPF, DKIM ve DMARC durumunu gösterir ve sorunlu kayıtlar için önerilen değeri sunar. Onarım seçeneğiyle önerilen kaydı kurabilirsiniz. Ancak ekranı açmak barındırma sağlayıcınızın elindedir.

Kritik nokta şudur: kayıtların işe yaraması için sunucunun alan adının yetkili ad sunucusu olması gerekir. cPanel belgelerindeki Email Deliverability sayfası bunu açıkça belirtir. Aksi halde kayıt yalnızca sunucuda yerel kalır ve etkisiz olur. O zaman önerilen kaydı kopyalayıp DNS'i yöneten yerde eklersiniz.

Karma kurulumlar sahada sık karşımıza çıkar. Örneğin posta kutularınız Google Workspace'te, siteniz ise cPanel sunucusunda olabilir. Bu durumda site formları sunucudan çıkar ve SPF kaydınıza her iki kaynak da girmelidir. Sunucunun IP adresine ait ters DNS kaydı ise barındırma sağlayıcınızın işidir; PTR kaydı yazımız bunu açıklıyor.

Biz hosting ya da e-posta sağlayıcısı değiliz. Web sitesini ve kurumsal e-postayı Google Workspace, Microsoft 365 ya da barındırma sağlayıcınızda kurar, taşır ve yönetiriz.

Bülten aracı, CRM ve web sitesi formu e-postalarını nasıl doğrularsınız?

Üçüncü taraf servisler adınıza gönderdiği için her birinin kendi kurulumu vardır. Bülten ve CRM araçlarının panelinde genellikle alan adı doğrulama bölümü vardır. Orada servis size DKIM kayıtları verir, bazen de özel bir zarf gönderen alan adı ister. Bu kayıtları DNS'e eklediğinizde servis iletileri sizin alan adınızla imzalar ve hizalama kendiliğinden oluşur. Ancak SPF include satırını yalnızca servisin yardım sayfası istiyorsa ekleyin.

Microsoft belgesi, kontrolünüz altında olmayan toplu gönderim servisleri için ana alan adı yerine bir alt alan adı önerir. Örneğin bulten.example.com, ana alan adınızın itibarını korur. Ayrıca her alt alan adının kendi 10 sorgu hakkı olur.

Web sitesi formları ayrı bir tuzaktır. Formlar çoğu zaman sunucunun kendi posta fonksiyonuyla gider ve SPF listenizde olmayan bir kaynaktan çıkar. Daha güvenli yol şudur: From alanına kendi alan adınızdan bir adres yazın, ziyaretçinin adresini Reply-To alanına koyun ve iletiyi e-posta sağlayıcınızın kimlik doğrulaması yapan SMTP hesabıyla gönderin. WordPress kullanıyorsanız WordPress e-posta gönderme rehberimiz adımları anlatıyor.

SPF DKIM DMARC kurulumunu nasıl test edersiniz?

Kayıtları eklemek işin yarısıdır, asıl sonucu testte görürsünüz. Sırayla şunları yapın:

1. SPF DKIM DMARC kontrol aracımıza alan adınızı yazın. Araç SPF sorgu ağacını, DKIM seçicilerini ve DMARC politikasını gösterir. Seçiciyi bilmiyorsanız boş bırakın, yaygın seçicileri kendisi tarar.
2. Ham kayıtları görmek için DNS sorgulama aracını kullanın. DKIM için seçici._domainkey.example.com adını ayrıca sorgulayın ve host adlarının tam doğru olduğundan emin olun.
3. Her gönderen servisten başka bir Gmail adresine gerçek bir ileti gönderin. Form, bülten ve CRM için ayrı ayrı deneyin.
4. Gmail'de iletiyi açıp Orijinali göster ekranına bakın. SPF, DKIM ve DMARC için pass sonucunu arayın.
5. Başlığı kontrol aracına yapıştırın, araç hizalamayı da gösterir.

Sonuç beklediğiniz gibi değilse kaydı hemen değiştirmeyin. Çünkü DNS değişikliklerinin yayılması TTL değerine (kaydın önbellekte kalma süresine) ve önbelleklere bağlıdır. Google yardım sayfaları da kayıtların etkinleşmesinin zaman alabileceğini belirtir. Bu yüzden bekleyin, sonra yeniden test edin.

SPF DKIM DMARC kurarken en sık hangi hataları yaparsınız?

Aşağıdaki tablo, sahada en sık gördüğümüz hataları belirtileri ve çözümleriyle özetler.

Hataların çoğu birkaç temel kuralı çiğnemekten çıkar: tek SPF kaydı, doğru host adı ve her gönderen için DKIM.

Kurulumdan sonra neleri kontrol etmeli, ne zaman destek almalısınız?

Kurulum, bir kez yapıp unutacağınız bir iş değildir. Çünkü yeni bir servis eklediğinizde ya da sağlayıcı değiştirdiğinizde kayıtlar eskir. Bu yüzden şu kontrol listesini düzenli uygulayın:

• Gönderen servis listesi yazılı ve güncel mi?
• Alan adında tek bir SPF kaydı ve 10 sorgunun altında bir ağaç var mı?
• Her servis için DKIM geçiyor ve alan adınızla eşleşiyor mu?
• DMARC raporlarını düzenli okuyor musunuz?
• Kullanmadığınız servislerin include ve DKIM kayıtlarını sildiniz mi?
• E-posta göndermeyen alan adlarında v=spf1 -all var mı?

Örneğin bu kontrolü aylık web sitesi bakım kontrol listenize ekleyebilirsiniz. Sağlayıcı değiştirirken de kurumsal e-posta taşıma rehberimiz bu kayıtları unutmamanız için iyi bir hatırlatıcıdır.

Birden çok alan adınız varsa, DNS erişimi sizde değilse ya da DMARC'ı reject seviyesine taşıyacaksanız uzman desteği zaman kazandırır. Web sitesi ve kurumsal e-posta kurulumu ya da taşıması için teklif alın.