"SPF ekledim, DKIM ekledim, DMARC da ekledim — ama Gmail hâlâ maillerimi reddediyor." Bu cümleyi yılda onlarca kez duyuyorum ve neredeyse her seferinde sebep aynı: üç kayıt da var, üçü de geçerli, ama hiçbiri From: satırındaki alan adıyla hizalı değil. Gmail gönderici kuralları ve Yahoo gönderici şartları, "kayıt var mı" diye bakmaz; "bu mesaj gerçekten bu alan adına ait mi" diye bakar. Hizalama (alignment) tam olarak bu sorunun cevabıdır ve Türkçe kaynakların neredeyse tamamının atladığı yer burasıdır.
Bu yazıda önce kuralların ne olduğunu ve kimi kapsadığını net koyacağım; sonra asıl mesele olan SPF hizalaması ile DKIM hizalamasını gerçek başlık çıktıları üzerinden göstereceğim; ardından tek tıkla abonelik iptali, spam şikâyet oranı eşiği ve PTR kaydı gibi diğer şartları tek tek geçeceğiz. Sonda da elinizi attığınız gibi uygulayabileceğiniz bir doğrulama ve uyum kontrol listesi var. Amacım "şu üç kaydı ekleyin" demek değil — o cümle sizi buraya getiren cümle zaten. Amacım eklediğiniz kayıtların neden işe yaramadığını göstermek.
Gmail ve Yahoo Tam Olarak Ne İstiyor#
Google ve Yahoo'nun toplu göndericilerden istediği şartlar üç başlıkta toplanır: kimlik doğrulama, kolay abonelikten çıkma ve düşük şikâyet oranı. Microsoft da benzer bir eşiği kendi tarafında uygulamaya aldı, yani bu artık tek bir sağlayıcının politikası değil, sektörün ortak asgari çizgisi.
Şartların listesi şu şekildedir:
- SPF ve DKIM'in ikisi de kurulu olacak. Eskiden biri yeterliydi; toplu gönderici iseniz artık ikisi de isteniyor.
- Gönderen alan adında DMARC kaydı bulunacak. Politika en azından
p=noneolabilir, ama kaydın var olması şart. - DMARC geçmeli, yani SPF veya DKIM'den en az biri hizalı olacak. Kuralın gerçek ağırlığı burada.
- Gönderim IP'sinin geçerli bir PTR (ters DNS) kaydı olacak ve ileri/geri DNS tutarlı olacak.
- Bağlantılar TLS ile şifrelenecek.
- Pazarlama maillerinde tek tıkla abonelikten çıkma bulunacak ve talep en geç iki gün içinde uygulanacak.
- Spam şikâyet oranı binde 3'ün altında kalacak, binde 1 hedeflenecek.
- Mesaj biçimi standartlara uygun olacak (geçerli
From:,Message-ID,Datebaşlıkları;From:alanında alıcı alan adının taklit edilmemesi).
Uymamanın sonucu kademelidir: önce bir kısmı spam klasörüne düşer, sonra geçici erteleme (4xx) başlar, en son kalıcı reddetme (5xx) gelir. Reddetme mesajı genelde şuna benzer:
550-5.7.26 This mail has been blocked because the sender is unauthenticated.
550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.
550-5.7.26 Authentication results: DKIM = did not pass, SPF [sirketiniz.com.tr] with ip: [203.0.113.25] = did not pass
Bu mesajı gördüğünüzde "ama benim SPF kaydım var" demeyin; mesaj SPF'in var olmadığını değil, geçmediğini söylüyor. Aradaki fark hizalamadır.
Kimler Toplu Gönderici Sayılıyor#
Bir Gmail veya Yahoo adresine günde 5.000'in üzerinde mesaj gönderiyorsanız toplu gönderici sayılırsınız. Bu eşiğin okunması gereken üç ayrıntısı var:
- Eşik alan adı bazındadır, IP bazında değil. Aynı alan adından farklı sunucular üzerinden gönderim yapıyorsanız hepsi toplanır.
- Eşik bir kez aşıldığında kalıcıdır. Yılda bir kez büyük bir kampanya gönderip eşiği geçtiyseniz, o alan adı sonrasında da toplu gönderici muamelesi görür.
- Alt alan adları ayrı sayılmaz; kurumsal alan adı (organizational domain) düzeyinde değerlendirilir.
Eşiğin altındaysanız da rahatlamayın. Küçük gönderici olmak sizi kimlik doğrulama şartından muaf tutmuyor; sadece bazı maddelerde (özellikle tek tıkla iptal) esneklik sağlıyor. Pratikte doğru yaklaşım, eşikten bağımsız olarak sekiz maddenin hepsini uygulamaktır — çünkü bu şartlar aynı zamanda maillerinizin spam'e düşmemesinin de reçetesidir. Gmail'e özgü teşhis adımları için Gmail'e mail gitmiyor yazısına bakabilirsiniz.
Hizalama (Alignment) Nedir ve İşi Neden O Bozuyor#
Hizalama, kimlik doğrulamayı geçen alan adının, kullanıcının gördüğü From: alan adıyla aynı olması demektir. DMARC'ın tek işi budur; SPF ve DKIM'i denetlemez, onların hangi alan adı adına geçtiğini denetler.
Karışıklığın kaynağı şudur: bir e-posta mesajında iki ayrı "gönderen" vardır.
| Alan | Nerede yer alır | Kim görür | Hangi doğrulamada kullanılır |
|---|---|---|---|
Zarf göndericisi (MAIL FROM / Return-Path) | SMTP oturumunda, mesaj gövdesinden önce | Kullanıcı görmez | SPF bunu doğrular |
Başlık göndericisi (From:) | Mesaj başlıklarında | Kullanıcının gördüğü tek adres | DMARC buna bakar |
DKIM imza alanı (d= etiketi) | DKIM-Signature başlığında | Kullanıcı görmez | DKIM bunun adına imzalar |
DMARC'ın kuralı tek cümledir: SPF'in doğruladığı alan adı ya da DKIM'in d= alan adı, From: alan adıyla eşleşmelidir. İkisinden biri eşleşirse DMARC geçer; hiçbiri eşleşmezse SPF ve DKIM ayrı ayrı "pass" olsa bile DMARC fail verir.
En sık gördüğüm senaryo şudur: firma, bültenini bir dış gönderim servisi üzerinden atıyor. Servis kendi altyapısından gönderdiği için Return-Path adresi [email protected] oluyor ve DKIM imzasını da kendi alan adıyla atıyor. Sonuç:
Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=s1;
spf=pass (google.com: domain of [email protected]
designates 198.51.100.10 as permitted sender)
[email protected];
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=sirketiniz.com.tr
Bu çıktıyı okuyun: dkim=pass, spf=pass, ama dmarc=fail. Çünkü SPF gonderimservisi.com adına geçti, DKIM de gonderimservisi.com adına imzaladı; oysa kullanıcının gördüğü From: adresi sirketiniz.com.tr. Hiçbir doğrulama sizin alan adınız adına yapılmadı. Google açısından bu mesaj "kimliği doğrulanmamış"tır ve DMARC politikanız p=none olsa bile toplu gönderici kuralları gereği reddedilebilir.
İki hizalama modu: relaxed ve strict#
DMARC kaydında iki etiket bu davranışı belirler: aspf (SPF hizalama modu) ve adkim (DKIM hizalama modu). Her ikisinin de varsayılanı r yani relaxed'dır.
- relaxed (r): Kurumsal alan adı düzeyinde eşleşme yeterlidir.
From:adresisirketiniz.com.triken DKIMd=kampanya.sirketiniz.com.trolabilir; hizalama geçer. - strict (s): Alan adları harfi harfine aynı olmalıdır.
kampanya.sirketiniz.com.trilesirketiniz.com.trstrict modda hizalanmaz.
Uygulamada relaxed modda kalın. Strict, alt alan adlarından gönderim yapan her yapıyı kırar ve karşılığında pratikte fazladan koruma sağlamaz.
Hizalamanın dört olası sonucu#
| SPF sonucu | SPF hizalı mı | DKIM sonucu | DKIM hizalı mı | DMARC |
|---|---|---|---|---|
| pass | evet | fail | — | pass |
| fail | — | pass | evet | pass |
| pass | hayır | pass | hayır | fail |
| fail | — | fail | — | fail |
Üçüncü satır, bu yazının varlık sebebidir: her iki doğrulama da geçiyor, DMARC yine de başarısız.
Hizalamayı nasıl düzeltirsiniz#
İki yoldan biri yeterlidir, ama ikisini birden yapmak en sağlamıdır.
- DKIM'i kendi alan adınızla imzalatın. Gönderim servisiniz size bir DKIM seçicisi (selector) ve CNAME/TXT kaydı verir; bunu DNS'inize eklediğinizde imza
d=sirketiniz.com.trolur. Bu, en dayanıklı çözümdür çünkü DKIM iletme (forwarding) sırasında da hayatta kalır. - Özel bir Return-Path (custom bounce domain) tanımlayın. Servis size
bounce.sirketiniz.com.trgibi bir alt alan adı için CNAME verir; zarf göndericisi artık sizin alan adınız olur ve SPF hizalanır.
Kendi sunucunuzdan gönderiyorsanız zaten ikisi de doğal olarak hizalıdır — yeter ki DKIM anahtarını doğru alan adıyla üretmiş olun. DKIM tarafındaki tipik arızalar ve teşhisi için DKIM doğrulaması başarısız yazısına, üç kaydın temel kurulumu için SPF, DKIM ve DMARC yazısına bakın.
Kayıtlarınızı Adım Adım Doğrulama#
Kayıtları panelden "var mı" diye kontrol etmeyin; DNS'ten sorgulayın. Panelde görünen kayıt yayılmamış ya da yanlış bölgede duruyor olabilir.
# 1. SPF — tek bir v=spf1 kaydı olmalı, birden fazlası SPF'i geçersiz kılar
dig +short TXT sirketiniz.com.tr | grep spf1
# 2. DKIM — seçici adını mesaj başlığındaki s= etiketinden alın
dig +short TXT s1._domainkey.sirketiniz.com.tr
# 3. DMARC — alt alan adı politikası için sp= etiketine de bakın
dig +short TXT _dmarc.sirketiniz.com.tr
# 4. PTR — gönderim IP'si kendi hostname'ine, o hostname de aynı IP'ye çözülmeli
dig +short -x 203.0.113.25
dig +short mail.sirketiniz.com.tr
Beklenen çıktılar şuna benzemelidir:
sirketiniz.com.tr. IN TXT "v=spf1 include:_spf.saglayici.com ip4:203.0.113.25 -all"
s1._domainkey.sirketiniz.com.tr. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."
_dmarc.sirketiniz.com.tr. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; fo=1"
Üç sık hata: SPF kaydında -all yerine ?all bırakmak (hiçbir şey doğrulamaz), aynı alan adında iki ayrı v=spf1 kaydı tutmak (ikisi de geçersiz olur) ve SPF'te on include/DNS sorgusu sınırını aşmak (permerror alırsınız). Üç kaydın tamamı TXT tipindedir; panelde "SPF" ya da "DMARC" diye ayrı bir kayıt tipi ararsanız bulamazsınız. dig kullanımına yabancıysanız dig komutu kullanımı yazısı işinizi görür.
Doğrulamanın son ve en kesin adımı: kendinize bir Gmail hesabından test maili atın, mesajı açın, üç nokta menüsünden Orijinali göster deyin ve Authentication-Results satırını okuyun. dmarc=pass ... header.from=sirketiniz.com.tr görüyorsanız hizalama tamamdır.
Tek Tıkla Abonelikten Çıkma#
Pazarlama maillerinde alıcının tek tıkla abonelikten çıkabilmesi zorunludur ve bunun iki başlıkla ilan edilmesi gerekir:
List-Unsubscribe: <https://kampanya.sirketiniz.com.tr/cikis?t=TOKEN>, <mailto:[email protected]>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
Dört kural:
List-Unsubscribe-Postbaşlığı olmadan Gmail bu özelliği tanımaz; sadeceList-Unsubscribekoymak yetmez.- Bağlantı adresine POST isteği geleceğini unutmayın. Sunucunuz o adrese gelen POST'u karşılamalı ve aboneliği onay ekranı sormadan iptal etmelidir.
- Bu başlık, mesaj gövdesindeki abonelikten çık bağlantısının yerini almaz; ikisi de bulunmalıdır.
- Talebi en geç iki gün içinde uygulamanız gerekir. Pratikte anında uygulayın; çıkamayan kullanıcı "spam" düğmesine basar ve bu size iptalden çok daha pahalıya mal olur.
İşlem mailleri (sipariş onayı, şifre sıfırlama, fatura) bu şartın kapsamı dışındadır — ama işlem maili ile pazarlama mailini aynı mesajda karıştırırsanız mesajın tamamı pazarlama sayılır.
Spam Şikâyet Oranı ve İzleme#
Spam şikâyet oranınız kullanıcı bazında binde 3'ün altında kalmalı, hedefiniz binde 1 olmalıdır. Buradaki "oran" gönderdiğiniz mesaj sayısına göre değil, teslim edilen mesaja göre hesaplanır ve gün bazında değerlendirilir; yani tek bir kötü kampanya bütün ayı bozabilir.
Oranınızı ölçmenin tek güvenilir yolu, alıcı tarafın kendi araçlarını kullanmaktır. Google'ın gönderici paneline alan adınızı bir TXT kaydıyla doğrulayıp ekleyin; orada şikâyet oranı, kimlik doğrulama başarı yüzdesi, IP itibarı ve şifreleme oranı günlük olarak görünür. Yahoo tarafında da geri bildirim döngüsüne (feedback loop) kaydolmanız gerekir; kaydolduğunuzda "spam" işaretlenen mesajların bildirimi size döner ve o adresleri anında listeden çıkarabilirsiniz.
Şikâyet oranını düşürmenin teknik olmayan üç yolu: çift onaylı abonelik kullanmak, gönderim sıklığını abone beklentisiyle uyumlu tutmak ve pasif segmentleri (6 aydır hiç açmayanlar) listeden çıkarmak. Yılda bir kez yaptığınız "liste temizliği" şikâyet oranını hemen hemen her seferinde yarıya indirir.
Uyum Kontrol Listesi ve Sık Yapılan Hatalar#
Gönderime çıkmadan önce şu listeyi baştan sona geçin:
From:alan adı için SPF kaydı var, tek ve-allile bitiyor.- DKIM imzası
d=etiketinde sizin alan adınızı taşıyor, anahtar en az 1024 bit (tercihen 2048). _dmarckaydı yayında; başlangıçtap=noneverua=ile rapor topluyorsunuz.- Bir test mesajının
Authentication-Resultssatırındadmarc=passgörüyorsunuz. - Gönderim IP'sinin PTR kaydı var ve ileri/geri DNS tutarlı.
- Gönderim TLS ile yapılıyor (587 + STARTTLS ya da 465 + implicit TLS).
- Pazarlama maillerinde
List-Unsubscribe+List-Unsubscribe-Postbaşlıkları var ve POST isteği çalışıyor. - Gönderici panelinde şikâyet oranı binde 3'ün altında.
- Hard bounce alan adresler aynı gün listeden çıkarılıyor.
- Pazarlama gönderimi ana alan adından değil, ayrı bir alt alan adından yapılıyor.
En sık yapılan dört hata da şunlar: DMARC'ı doğrudan p=reject ile yayına almak (raporları okumadan yapıldığında kendi meşru gönderimlerinizi kesersiniz), tek bir alan adına iki SPF kaydı koymak, DKIM anahtarını değiştirdikten sonra eski seçiciyi DNS'ten hemen silmek (yolda olan mesajlar doğrulanamaz) ve dış servisin verdiği CNAME'leri "gerek yok" diye eklememek — ki bu son madde tam olarak hizalamayı bozan şeydir.
Sıkça Sorulan Sorular#
SPF DKIM ve DMARC eklediğim hâlde Gmail neden hâlâ reddediyor#
Büyük ihtimalle kayıtlarınız var ama hizalı değil. SPF, From: adresini değil zarf göndericisini (Return-Path) doğrular; DKIM de imzayı d= etiketindeki alan adı adına atar. Dış bir gönderim servisi kullanıyorsanız bu ikisi genelde servisin alan adına ait olur ve DMARC "fail" verir. Bir test mesajının Authentication-Results başlığına bakın: dmarc=fail yazıyorsa çözüm, servisin verdiği DKIM ve bounce domain CNAME kayıtlarını kendi DNS'inize eklemektir.
DMARC politikasını none bırakmak yeterli mi#
Kuralların asgarisi için yeterlidir, koruma için değildir. Gmail ve Yahoo, kaydın var olmasını ve DMARC'ın geçmesini ister; politikanın p=none olması bu şartı karşılar. Ancak p=none, alan adınızı taklit eden sahte maillere karşı hiçbir şey yapmaz — sadece rapor toplar. Doğru yol, birkaç hafta p=none ile rapor toplayıp tüm meşru gönderim kaynaklarınızı tespit etmek, sonra p=quarantine, ardından p=reject seviyesine kademeli geçmektir.
Günde 5000 mailin altındaysam bu kurallar beni bağlamıyor mu#
Kimlik doğrulama şartları sizi de bağlar, sadece bazı maddelerde esneklik olur. Eşiğin altındaki göndericilerden de geçerli SPF veya DKIM, PTR kaydı ve TLS beklenir; tek tıkla abonelik iptali maddesi ise özellikle toplu göndericiler için zorunlu tutulur. Ayrıca eşik alan adı bazında ve bir kez aşıldığında kalıcı sayıldığı için, yılda tek bir büyük kampanya sizi kalıcı olarak toplu gönderici konumuna taşıyabilir. Pratik tavsiye: eşiği hiç dikkate almadan tüm maddeleri uygulayın.
Hizalamayı hangi araçla kontrol ederim#
En kesin yol, Gmail'e bir test maili atıp mesajın orijinalindeki Authentication-Results başlığını okumaktır. O satırda dmarc=pass ile birlikte header.from= değerinin sizin alan adınız olduğunu görmelisiniz. Ayrıca spf=pass satırındaki smtp.mailfrom= ve dkim=pass satırındaki header.i= değerlerini From: adresinizle karşılaştırın; ikisi de farklı alan adı gösteriyorsa hizalama yoktur. DMARC raporlarında (rua=) da aynı bilgi kaynak bazında toplu olarak gelir.
Return-Path adresini nasıl kendi alan adım yapabilirim#
Gönderim servisinizin "özel bounce alan adı" (custom return-path / custom MAIL FROM) özelliğini açıp verdiği CNAME kaydını DNS'inize eklemeniz gerekir. Tipik olarak bounce.sirketiniz.com.tr gibi bir alt alan adı için bir CNAME ve o alt alan adı için ayrı bir SPF TXT kaydı istenir. Kaydı ekledikten sonra servis tarafında doğrulamayı tetikleyin; doğrulandığında zarf göndericisi sizin alt alan adınız olur ve SPF hizalaması sağlanır. Kendi sunucunuzdan gönderiyorsanız bu ayara zaten ihtiyacınız yoktur.
Alt alan adından gönderim yaparsam DMARC geçer mi#
Geçer, çünkü hizalama modu varsayılan olarak relaxed'dır ve kurumsal alan adı düzeyinde eşleşme yeterlidir. From: adresi [email protected] iken DKIM d=sirketiniz.com.tr olabilir; hizalama sağlanır. Ancak DMARC kaydınızda adkim=s ya da aspf=s yazdıysanız strict moda geçmiş olursunuz ve alt alan adı eşleşmesi kırılır. Ayrıca alt alan adları için ayrı politika belirlemek isterseniz ana kayıttaki sp= etiketini kullanın.
PTR kaydını kim ayarlar#
PTR kaydını IP adresinin sahibi, yani hosting veya sunucu sağlayıcınız ayarlar; kendi DNS panelinizden ekleyemezsiniz. Paylaşımlı hosting kullanıyorsanız çıkış IP'si zaten sağlayıcının hostname'ine çözülür ve sizin bir şey yapmanız gerekmez. Kendi sunucunuz varsa sağlayıcının panelinden ya da destek talebiyle IP'nin mail.sirketiniz.com.tr gibi bir isme çözülmesini isteyin, sonra o ismin de aynı IP'ye çözüldüğünden emin olun. İleri ve geri DNS tutarsızsa Gmail bunu doğrulanmamış kaynak sayar.
Tek tıkla abonelik iptali işlem maillerinde de gerekli mi#
Gerekli değildir; şart pazarlama ve tanıtım içerikli toplu mesajlar için geçerlidir. Sipariş onayı, kargo bildirimi, şifre sıfırlama, fatura gibi kullanıcının talebi üzerine üretilen işlem mailleri kapsam dışıdır. Ancak bir işlem mailinin içine kampanya bloğu koyduğunuzda mesajın niteliği değişir ve pazarlama maili muamelesi görür. Bu yüzden iki türü ayrı şablonlarda, tercihen ayrı alt alan adlarından göndermek en temiz kurgudur.
Kapanış#
Gmail ve Yahoo'nun gönderici kuralları özünde tek bir şey soruyor: bu mesaj gerçekten From: satırındaki alan adına mı ait. SPF, DKIM ve DMARC kayıtlarını eklemiş olmak bu sorunun cevabı değil; kayıtların sizin alan adınız adına çalışıyor olması cevaptır. Hizalamayı sağlamanın yolu da net: DKIM imzasını kendi alan adınızla attırın, mümkünse özel bir bounce alan adı tanımlayın, sonra bir test mesajının Authentication-Results satırında dmarc=pass gördüğünüzden emin olun. Geri kalan maddeler — PTR, TLS, tek tıkla iptal, düşük şikâyet oranı — bunun üzerine kurulan ve düzenli bakım isteyen katmanlardır.
Bu yapıyı kurarken teknik tarafı devretmek isterseniz Clou.TR'nin ayrı gönderim IP'si, hazır DKIM anahtarı ve PTR kaydıyla teslim edilen SMTP sunucu paketleri işi baştan doğru kurar; günlük kurumsal yazışma için kurumsal e-posta hizmetinde SPF ve DKIM kayıtları sizin adınıza hazır gelir. DNS kayıtlarını yönetmek için alan adınızı alan adı tarafından takip edebilir, kayıtların yayına çıkıp çıkmadığını SMTP test aracı ile hızlıca doğrulayabilirsiniz.