Toplu E-posta Gönderici Kuralları: SPF, DKIM, DMARC

Gmail hesaplarına günde 5.000'den fazla ileti gönderiyorsanız Google, alan adınız için SPF, DKIM ve DMARC kurulumunu, From alanıyla hizalamayı ve pazarlama iletilerinde tek tıkla abonelikten çıkışı şart koşar. Daha az gönderen herkes için de SPF veya DKIM, geçerli ters DNS kaydı, TLS ve düşük spam oranı beklenir. Bülten, kampanya e-postası ya da sipariş bildirimi gönderen blog, yayıncı ve e-ticaret sahipleri için asıl iş, bu şartları kendi gönderici envanterine bağlayıp doğru sırayla kurmaktır.

Konuda iki ayrı soru vardır. Birincisi iznin yanıdır: kime, hangi onayla e-posta gönderebileceğiniz. O kısım için e-bülten aboneliği, izin ve KVKK yazısına bakın. İkincisi teknik sorudur: gönderdiğiniz iletinin gerçekten sizden geldiğini alıcı sunucuya nasıl kanıtlarsınız ve alıcı sizi nasıl bir gönderici olarak sınıflandırır. Teknik kurulum doğru olsa bile izinsiz liste şikayet oranını düşürmez; izin doğru olsa bile kimlik doğrulaması eksikse ileti sorun yaşar. İkisi birbirini tamamlar.

Gönderici kurallarının kapsamı: kimler etkilenir

Google'ın e-posta göndericisi yönergeleri sayfası (yeni sekmede açılır) kuralları iki kademede sıralar. Birinci kademe, kişisel Gmail hesaplarına ileti gönderen herkes içindir. İkinci kademe, kişisel Gmail hesaplarına günde 5.000 veya daha fazla ileti gönderen göndericileri kapsar. Sayfa, eşiği "günde 5.000'den fazla ileti" biçiminde de anar ve kuralların 1 Şubat 2024 itibarıyla geçerli olduğunu belirtir. Kişisel Gmail hesabı, sayfaya göre @gmail.com veya @googlemail.com ile biten hesaptır. Google belgelerindeki sınırlar ve şartlar değişebilir; uygulamadan önce güncel sayfaya bakın.

Eşiği nasıl okumalısınız

Eşik, tek bir bülten kampanyasının büyüklüğü değil, Gmail hesaplarına giden günlük ileti sayısıdır. Sayfa hangi iletilerin sayıldığını ayrıntılı tarif etmez; bu konuda emin değilseniz kendinizi üst kademede varsayın. Uygulama önerisi: abone listenizin Gmail adreslerini ayrı bir segment olarak görün ve bülten, sipariş bildirimi, sistem e-postası gibi tüm akışlarınızı aynı alan adı altında birlikte değerlendirin. İtibar yalnız tek bir kampanyaya değil, alan adına ve gönderici altyapısına bağlanır.

Küçük bir bülteniniz olsa bile üst kademenin şartlarını baştan kurmak, büyüdüğünüzde kurulumu yeniden yapmanızı gerektirmez. Bu da bir uygulama önerisidir; sayfada küçük göndericiler için üst kademeyi ön koşul yapan bir ifade yoktur.

Tüm göndericiler için temel şartlar

Sayfaya göre kişisel Gmail hesaplarına ileti gönderen herkes şunlara uymalıdır: gönderen alan adı için SPF veya DKIM kurmak, gönderen alan adı veya IP adresinde geçerli ileri ve ters DNS (PTR) kayıtları bulundurmak, iletiyi TLS ile iletmek, Postmaster Tools'ta görünen spam oranını yüzde 0,3'ün altında tutmak, iletileri RFC 5322 biçimine uygun hazırlamak ve Gmail From: başlıklarını taklit etmemek. Sayfa ayrıca From: başlığında yalnızca tek bir e-posta adresi bulunmasını ve aynı kategorideki iletilerde aynı From: adresinin kullanılmasını söyler.

Günde 5.000 ve üzeri için ek şartlar

Üst kademede SPF ve DKIM'in ikisi birden gerekir, tek başına biri yetmez. DMARC kurulumu da zorunludur; sayfa uygulama politikasının "none" olabileceğini açıkça yazar. Doğrudan gönderilen iletilerde From: alan adı, SPF alan adıyla veya DKIM alan adıyla hizalanmalıdır. Pazarlama ve abonelik iletileri tek tıkla abonelikten çıkışı desteklemeli ve ileti gövdesinde açıkça görünen bir abonelikten çıkış bağlantısı içermelidir.

Workspace ile gönderenler için not

Sayfa, büyük hacimde e-posta için Google Workspace kullananların Gmail'deki spam ve kötüye kullanım politikasını da incelemesini söyler. O politikanın ayrıntıları bu konunun dışındadır; Workspace ile bülten gönderiyorsanız ilgili politika sayfasını ayrıca okuyun.

Üç kimlik doğrulama katmanı: SPF, DKIM, DMARC

Üç kısaltma birbirinden farklı üç soruya cevap verir. SPF, "bu IP adresi bu alan adı adına ileti gönderebilir mi" sorusunu DNS kaydıyla yanıtlar. DKIM, "bu ileti yola çıktığı anda bu alan adının anahtarıyla imzalandı mı" sorusunu yanıtlar. DMARC ise bu ikisinden en az birinin sonucunu, alıcının gördüğü From alan adıyla ilişkilendirir ve alıcıya hangi politikayı istediğinizi bildirir.

SPF: yetkili gönderici listesi

SPF, bir alan adı için DNS'te yayımlanan TXT kaydıdır. RFC 7208 (yeni sekmede açılır)'e göre doğrulayıcılar HELO kimliğini ve MAIL FROM (zarf göndereni) kimliğini denetler (Bölüm 2.3 ve 2.4); ileti içindeki görünen From başlığı SPF'nin doğrudan baktığı alan değildir. Bu fark, hizalama konusunda belirleyici olacak. Google'ın sayfası alan adınızın tüm e-posta göndericilerini içeren bir SPF kaydı yayımlamanızı ister ve listelenmemiş üçüncü taraf göndericilerin spam olarak işaretlenme ihtimalinin yüksek olduğunu söyler. SPF'nin yazımı, DNS sorgu sınırı ve sık hatalar ayrı bir konudur.

DKIM: ileti imzası

DKIM'de gönderen sunucu veya e-posta servisi, ileti başlıklarının ve gövdenin bir özetini özel anahtarla imzalar; imza DKIM-Signature başlığında ilerler. Alıcı, imzadaki d= (alan adı) ve s= (seçici) değerlerinden DNS'te herkese açık anahtarı bulur ve doğrular. RFC 6376 (yeni sekmede açılır) Bölüm 3.6.2.1'e göre anahtar, seçici + "._domainkey." + alan adı biçimindeki bir TXT kaydında durur. Gmail sayfası, kişisel Gmail hesaplarına göndermek için 1024 bit veya daha uzun anahtar gerektiğini, alan adı sağlayıcınız destekliyorsa güvenlik için 2048 bit önerdiğini yazar. Fark şudur: 1024 bit bir gerekliliktir, 2048 bit sayfanın önerisidir.

DMARC: politika ve raporlama

DMARC kaydı, alan adının _dmarc alt alanında bir TXT kaydı olarak yayımlanır (RFC 7489 (yeni sekmede açılır), Bölüm 6.1). Kaydın p etiketi none, quarantine veya reject değerlerini alır (Bölüm 6.3). p=none, alan sahibinin teslimat için özel bir işlem istemediği anlamına gelir. Raporlar rua etiketinde belirtilen adreslere gider. RFC 7489 sayfası, kendisinin sonradan RFC 9989, 9990 ve 9991 ile değiştirildiğini belirtir; kavramlar aşağıda RFC 7489 bölüm numaralarıyla verilir, ayrıntı için güncel RFC'lere de bakın. DMARC yalnızca alan adını doğrular; ileti içeriğini değerlendirmez ve doğrulanmış iletiye öncelikli teslimat sağlamaz (RFC 7489, Bölüm 4.2 ve özet bölümü).

Kurulum sırası

Google Workspace DMARC sayfası (yeni sekmede açılır), DMARC'tan önce SPF ve/veya DKIM'in açık olması gerektiğini söyler ve SPF veya DKIM kurulumundan sonra DMARC için 48 saat beklenmesini ister. Bu yüzden sıra şudur: önce gönderici envanteri, sonra SPF ve DKIM, ardından DMARC. DMARC kaydı, Admin konsolunda değil alan adı sağlayıcınızın DNS panelinde eklenir.

Hizalama ve From alanı tutarlılığı

Sık görülen bir kurulum hatası, kimlik doğrulama sonucunun "geçti" görünmesine rağmen hizalamanın tutmamasıdır. Gmail sayfası şunu yazar: kimlik doğrulayan alan adı, ileti From: başlığında görünen alan adıyla aynı olmalıdır; doğrudan gönderimde From: alan adı SPF alan adıyla veya DKIM alan adıyla hizalanmalıdır.

İki ayrı kimlik meselesi

Bir e-posta servisi bülteninizi gönderirken zarf göndereni olarak kendi alan adını, DKIM imzasında da kendi alan adını kullanıyorsa SPF ve DKIM kendi içinde geçer, ama ikisi de sizin From alan adınızla hizalı değildir. Alıcı sunucu bu durumda iletinin servisinizden geldiğini doğrular, sizin alan adınız adına geldiğini doğrulayamaz. Çözüm, servisin panelinde kendi alan adınızı doğrulatmak ve servisin size verdiği DNS kayıtlarını eklemektir; böylece imza veya zarf gönderen sizin alan adınız altında atılır.

RFC 7489 Bölüm 3.1, hizalamayı kimliklerin eşleşmesi olarak tanımlar. Bir ileti, hizalı bir kimlik için en az bir mekanizma "pass" ürettiğinde DMARC'tan geçer (Bölüm 4.2). Birden çok DKIM imzası varsa hizalı ve doğrulanan tek bir imza yeterlidir (Bölüm 3.1.1). Yani bir ileti hem servisin hem sizin alan adınızla imzalandığında sizin imzanız hizalamayı kurtarabilir.

Gevşek ve sıkı hizalama

RFC 7489, hizalamanın iki kipini tanımlar. Gevşek kipte kurumsal alan adları karşılaştırılır; sıkı kipte tam alan adı eşleşmesi aranır (Bölüm 3.1.1 ve 3.1.2). adkim ve aspf etiketlerinin varsayılanı gevşektir ve s değeriyle sıkıya çevrilebilir (Bölüm 6.3). Kurumsal alan adı, kamu son eki listesine bakılarak bulunur; RFC bu yöntemin bir sezgisel yöntem olduğunu belirtir (Bölüm 3.2). Uygulama önerisi: bülten için ayrı bir alt alan adı kullanıyorsanız gevşek kipte kalın; sıkı kip, alt alan adı kullanan servislerle hizalamayı bozabilir.

From alanı için pratik kurallar

• From: başlığında tek bir adres bulunsun; Gmail sayfası bunu açıkça ister.
• Aynı kategorideki iletiler aynı From: adresinden gitsin; sayfa bunu da yazar.
• Gmail adresini From: olarak kullanmayın. Sayfa Gmail From: başlıklarını taklit etmeyi yasaklar; bülteni kendi alan adınızdan gönderin.
• Gerçek gönderici alan adı ile From alan adı arasında tutarsızlık yaratan eski formları (iletişim formu eklentileri gibi) tek tek kontrol edin.

Örnek senaryo: kitap blogu

Örnek senaryo: Bir kitap blogu, haftalık bülteni bir e-posta servisinden, yorum ve hesap bildirimlerini ise blogun kendi sunucusundan gönderiyor. Her iki akış da aynı alan adını From olarak kullanıyor. Bülten tarafında servisin alan adı doğrulaması yapılmamışsa SPF ve DKIM geçse de hizalama yoktur. Blog sunucusundan çıkan bildirimlerde SPF kaydı yalnızca sunucunun IP'sini içeriyorsa ve DKIM imzası eklenmemişse, bülten servisini SPF'ye eklemek ya da servis için ayrı bir DKIM anahtarı yayımlamak gerekir. İki akışı aynı tabloda, hangi kimliğin hangi alan adıyla hizalandığıyla birlikte yazmak sorunu çabuk gösterir.

Abonelikten çıkış akışı ve şikayet oranı

Kimlik doğrulama, iletinin kimden geldiğini söyler. Abonelikten çıkış ve şikayet oranı ise alıcının sizden gelen iletiyi isteyip istemediğini ölçer. Gmail sayfası ikincisini de açık sayılarla tarif eder.

Tek tıkla abonelikten çıkış

Günde 5.000 ve üzeri gönderenlerin pazarlama ve abonelik iletileri tek tıkla abonelikten çıkışı desteklemelidir. Sayfa iki başlığın birlikte eklenmesini ister: List-Unsubscribe-Post başlığı ve değeri List-Unsubscribe=One-Click, ayrıca List-Unsubscribe başlığı ve içinde bir https adresi. Alıcı çıkış yaptığında gönderici, gövdesinde List-Unsubscribe=One-Click bulunan bir POST isteği alır. Sayfa, alıcıların tek tek listeleri yönetmesine izin vermek veya birden fazla geri dönüşten sonra otomatik çıkarmak gibi seçeneklerin tek tıkla çıkışın yerini almamasını, onu tamamlayabileceğini söyler.

Gövdede ayrıca açıkça görünür bir abonelikten çıkış bağlantısı olmalıdır. Bu iki gereklilik birbirinin yerine geçmez: başlık posta istemcisinin kendi düğmesi içindir; gövdedeki bağlantı alıcının iletiyi okurken göreceği yerdir (bu ayrım bir yorumdur). Sayfada çıkış isteğinin kaç gün içinde işleneceğine dair bir süre yazmıyor; süre için ilgili resmi kaynağa ayrıca bakın.

Spam oranı ve eşikler

Postmaster Tools'ta görünen spam oranı için Gmail sayfası şunları söyler: tüm göndericiler için oran yüzde 0,3'ün altında kalmalı; 5.000 ve üzeri gönderenler için yüzde 0,30'un altında kalmalı. İzleme bölümünde ise oranı yüzde 0,10'un altında tutmanızı ve hiçbir zaman yüzde 0,30 veya üstüne çıkmamanızı önerir. Kullanıcı spam şikayetlerinin zamanla alan adının itibarını düşürebileceğini de ekler. İki sayı farklı statüdedir: yüzde 0,30 gereklilik, yüzde 0,10 öneridir.

Hacmi küçük bir bültende tek bir şikayet oranı büyük oynatabileceği için sayıyı yorumlarken tek haftalık değişime değil eğilime bakmak mantıklıdır. Bu bir uygulama önerisidir, Google'ın yazdığı bir kural değildir.

Abonelikten çıkışı şikayetten daha kolay yapın

Alıcı için en kısa yol "spam olarak işaretle" düğmesi olduğunda şikayet oranı yükselir. Bu nedenle çıkış bağlantısını gizlemeyin, çıkış sayfasında ek giriş veya soru istemeyin ve onayı hemen verin. İzin tarafında doğru toplanmış bir liste de şikayeti azaltır; çift onay ve kayıt tutma gibi konular için yukarıda anılan izin ve KVKK yazısındaki akışı bu teknik kurulumla birlikte düşünün.

Kimlik doğrulamadan sonra sıradaki işler: sponsor etiketi, medya kiti, ölçüm

Kimlik doğrulaması tamamlandığında iş bitmez; yayıncı olarak bültenin içeriğinden doğan sorumluluklar da vardır. Bültende sponsorlu bir bölüm yer alıyorsa bunun açıkça etiketlenmesi gerekir; bağlantı niteliği ve etik açıklama için sponsorlu içerik etiketleme yazısına bakın. Abone sayısını reklam verenlere göstermek isterseniz bu bilgiyi medya kiti içinde doğru ve güncel biçimde sunmanız gerekir. Bülten bağlantılarının tıklamalarını ölçmek için UTM etiketlerini nasıl kullanacağınız ise raporlama ve UTM yazısında ele alınıyor.

Karar kuralı: hangi gönderici hangi kimliği taşımalı

Elinizde birden fazla gönderen sistem varsa her biri için aynı üç soruyu sorun ve cevabı bir tabloya yazın. Aşağıdaki kural, Gmail sayfasındaki şartlardan türetilmiş bir uygulama önerisidir.

1. Sistem Gmail adreslerine e-posta gönderiyor mu? Hayırsa bile kimlik doğrulamasını yapın, ama önceliği düşük tutun.
2. Sistem sizin alan adınızı From: olarak kullanıyor mu? Evetse SPF veya DKIM'den en az biri sizin alan adınızla hizalı olmalıdır; 5.000 eşiğinin üstündeyseniz ikisi de kurulu olmalıdır.
3. Sistem pazarlama veya abonelik iletisi mi gönderiyor? Evetse tek tıkla abonelikten çıkış başlıkları ve gövdede görünür çıkış bağlantısı eklenmelidir.

Bu üç sorunun hiçbirinde güvenli bir cevabı olmayan bir sistem, aynı alan adı altındaki öteki sistemlerin itibarını da etkiler. Sorunlu bir aracı kapatmak ya da ayrı bir alt alan adına taşımak, tek bir alan adında karışık akış sürdürmekten daha güvenli olabilir. Bu da bir uygulama önerisidir.

Gönderici envanteri için kontrol listesi

• Bülten servisi (kampanya ve otomatik e-postalar)
• Site sunucusunun gönderdiği sistem e-postaları (parola sıfırlama, sipariş, yorum bildirimi)
• İletişim formu ve destek sistemi
• Fatura veya ödeme servisinin gönderdiği makbuzlar
• Ekip üyelerinin kendi posta kutularından gönderdikleri e-postalar
• Eski veya kullanılmayan, ama DNS'te hâlâ yetkili görünen servisler

Listeye eklenen her kalem için üç şey kaydedin: hangi From alan adını kullandığı, SPF kaydında yer alıp almadığı ve DKIM imzasını kimin alan adıyla attığı. Boş kalan hücre, kurulum eksiğinin yeridir.

30 günlük kurulum planı

Aşağıdaki takvim bir öneridir; Google'ın bir takvimi yoktur, yalnızca Workspace sayfasında SPF veya DKIM'den sonra 48 saat beklenmesi istenir. Takvimi göndericilerinize göre kısaltabilir ya da uzatabilirsiniz.

1. hafta: envanter ve ölçüm başlangıcı

1. Gönderici envanterini çıkarın ve her akış için From alan adını yazın.
2. Postmaster Tools'a alan adınızı ekleyip doğrulayın; spam oranını izlemeye başlayın. Arayüzü Türkçe kullanıyorsanız menü adları farklı görünebilir.
3. Mevcut DNS TXT kayıtlarını kopyalayıp bir yere kaydedin. Değişiklik yapmadan önce geri dönüş noktanız olsun.

2. hafta: SPF ve DKIM

1. Tüm yetkili göndericileri tek bir SPF kaydında birleştirin. RFC 7208 Bölüm 4.5'e göre aynı alan adı için birden fazla SPF kaydı permerror üretir.
2. Bülten servisinin ve gerekirse site sunucusunun DKIM anahtarını yayımlayın. Alan adı sağlayıcınız destekliyorsa 2048 bit seçeneğini tercih edin.
3. Test iletisi gönderip başlıklarda SPF ve DKIM sonuçlarını kontrol edin.

3. hafta: DMARC izleme kipi

1. SPF ve DKIM'in üzerinden 48 saat geçtikten sonra _dmarc alt alanına TXT kaydı ekleyin. Workspace sayfası, kaydın v ve p etiketleriyle başlamasını ve p=none ile izlemeye başlamayı önerir.
2. rua etiketiyle raporların gideceği ayrı bir posta kutusu belirleyin. Sayfa, raporların büyük hacimde gelebileceğini söyleyip ayrı bir posta kutusu önerir. ruf etiketinin Gmail tarafından desteklenmediği de aynı sayfada yazar.
3. Kaydı yayımladıktan sonra çevrimiçi bir DMARC denetleyicisiyle sözdizimini doğrulayın. Bazı DNS panelleri alan adını kendiliğinden eklediği için ana bilgisayar adının doğru yazıldığını kontrol edin; sayfa bu noktayı özellikle vurgular.

4. hafta: abonelikten çıkış, rapor okuma, politika kararı

1. Bülten servisinizde tek tıkla abonelikten çıkış başlıklarının açık olduğunu doğrulayın; açık değilse servis desteğine sorun. Gövdedeki çıkış bağlantısını da kontrol edin.
2. Raporları inceleyin: tanımadığınız gönderenler var mı, beklenen akışlar hizalı geçiyor mu?
3. Her akış hizalı geçiyorsa quarantine veya reject politikasına geçişi planlayın. Workspace sayfası, kimlik doğrulama davranışını anladıktan sonra politikanın yükseltilmesini söyler. pct etiketi, geçiş sırasında politikayı iletilerin bir yüzdesine uygulamaya izin verir.

Kimlik doğrulama dışındaki şartlar: ters DNS, TLS, ileti biçimi

Kurulum denetimlerinde SPF, DKIM ve DMARC'a odaklanmak kolaydır; oysa Gmail sayfası ağ ve ileti biçimi tarafında da ölçütler sayar. Bülten servisi kullanıyorsanız bunlar servisin altyapısına aittir; kendi sunucunuzdan ileti gönderiyorsanız doğrudan sizin sorumluluğunuzdadır.

Ters DNS (PTR) kaydı

Sayfaya göre gönderen IP adresi, PTR kaydındaki ana bilgisayar adının IP adresiyle eşleşmelidir ve o ana bilgisayar adının A (IPv4) ya da AAAA (IPv6) kaydı yine aynı IP'ye çözülmelidir. Yani iki yönlü bir doğrulama istenir: IP adresinden ada, adan tekrar IP adresine. Bülten servisi kullanıyorsanız bu kayıtları servis yönetir; yine de servisin hangi IP'lerden gönderdiğini sormak, sorun çıktığında zaman kazandırır. Kendi sunucunuzdan gönderiyorsanız PTR kaydı IP adresinin sahibi olan hosting veya IP sağlayıcısı tarafından ayarlanır; bunun için sağlayıcınıza başvurmanız gerekebilir.

TLS ve ileti biçimi

İletinin TLS ile iletilmesi tüm göndericiler için şarttır. İleti biçimi için sayfa RFC 5322'yi gösterir ve üç somut ölçüt sayar: her iletide geçerli bir Message-ID bulunmalı; From:, To:, Subject: ve Date: gibi tek örnekli başlıklar yalnızca bir kez yer almalı; From: başlığında tek bir e-posta adresi olmalı. Kendi yazdığınız bildirim betikleri bu ölçütleri sessizce bozabilir. Örneğin bir betik yanlışlıkla iki Subject: başlığı üretiyor ya da Message-ID eklemiyorsa, kimlik doğrulaması kusursuz olsa bile ileti biçimi şartı karşılanmaz.

Bu şartlar için hızlı kontrol listesi

• Gönderen IP adresinin PTR kaydı var mı, ad geri aynı IP'ye çözülüyor mu?
• Gönderim bağlantısı TLS ile mi yapılıyor?
• Her iletide geçerli bir Message-ID var mı?
• From:, To:, Subject: ve Date: başlıklarının her biri yalnızca bir kez mi geçiyor?
• From: başlığında tek bir adres mi var?

Bu listeyi yılda bir ya da gönderim altyapısını değiştirdiğinizde yeniden çalıştırın. Servis değiştirdiğinizde DKIM anahtarlarını ve SPF kaydını da güncellemeyi unutmayın; eski servisin kayıtlarını DNS'te bırakmak, artık kullanılmayan bir göndericiye yetki vermeye devam eder.

Sık yapılan hatalar

Kimlik doğrulama teslimat garantisi değildir

SPF, DKIM ve DMARC, ileti gelen kutusuna düşecek demek değildir. DMARC özeti bunu açıkça yazar: doğrulanmış iletiye öncelikli teslimat sağlamaz; alıcı, politikadan bağımsız olarak yerel politikasına göre davranabilir (RFC 7489, Bölüm 6.7). Google sayfası da spam oranı, itibar ve kullanıcı şikayetlerinin ayrı etkenler olduğunu gösterir. Kimlik doğrulama bir giriş koşuludur; itibar ise içeriğin ve listenin kalitesiyle zamanla oluşur.

Hangi sorun, hangi kanıtla aranır

• İletiler hiç gelmiyorsa: SPF, DKIM ve DMARC sonuçları, ters DNS ve TLS.
• İletiler spam klasörüne düşüyorsa: spam oranı, şikayetler, liste kalitesi ve içeriğin istenip istenmediği.
• Bazı alıcılar alıp bazıları almıyorsa: alıcı sağlayıcıya özel politikalar. Gmail sayfasındaki kurallar Gmail'e aittir; başka sağlayıcıların kuralları kendi belgelerinde aranmalıdır.

Sık Sorulan Sorular

Gmail'in günde 5.000 e-posta kuralı kimi kapsıyor?

Google'ın göndericisi yönergeleri sayfasına göre kişisel Gmail hesaplarına günde 5.000 veya daha fazla ileti gönderen göndericiler ek şartlara tabidir: SPF ve DKIM'in ikisi, DMARC, hizalama ve pazarlama iletilerinde tek tıkla abonelikten çıkış. Daha az gönderenler için de SPF veya DKIM, ters DNS, TLS ve düşük spam oranı beklenir. Sayfanın güncel hâlini kontrol edin.

DMARC politikasını hemen reject yapmam gerekir mi?

Hayır. Gmail sayfası, toplu gönderici için DMARC politikasının none olabileceğini yazar. Google Workspace sayfası da önce none ile başlayıp raporlarla davranışı anlamayı, sonra quarantine veya reject'e geçmeyi önerir.

SPF veya DKIM geçiyor ama DMARC hata veriyor, neden?

Büyük ihtimalle hizalama eksiktir. Gmail sayfasına göre From: alan adı, SPF alan adıyla veya DKIM alan adıyla hizalı olmalıdır. Bülten servisi kendi alan adıyla imzalıyorsa SPF ve DKIM geçse de sizin alan adınızla hizalı olmayabilir; servis panelinde alan adınızı doğrulatın.

Tek tıkla abonelikten çıkış tam olarak nasıl çalışır?

Gmail sayfası, iletide List-Unsubscribe-Post başlığının List-Unsubscribe=One-Click değeriyle ve List-Unsubscribe başlığının bir https adresiyle birlikte bulunmasını ister. Alıcı çıkış yaptığında gönderici, gövdesinde List-Unsubscribe=One-Click bulunan bir POST isteği alır. Gövdede ayrıca görünür bir çıkış bağlantısı da olmalıdır.

Kabul edilebilir spam oranı nedir?

Gmail sayfasına göre Postmaster Tools'taki oran, tüm göndericiler için yüzde 0,3'ün altında, günde 5.000 ve üzeri gönderenler için yüzde 0,30'un altında kalmalıdır. Sayfa ayrıca oranı yüzde 0,10'un altında tutmanızı ve yüzde 0,30'a hiç ulaşmamanızı önerir.

Küçük bir bülten için tüm bu kurulum gerekli mi?

Eşiğin altındaki göndericiler için sayfa SPF veya DKIM, ters DNS, TLS, RFC 5322 biçimi ve düşük spam oranını sayar. DMARC ve tek tıkla çıkış üst kademenin şartıdır. Uygulama önerisi: büyüme ihtimali varsa üst kademeye göre kurmak daha sonra yeniden yapılandırma gerektirmez.

Sonuç

Gönderici kuralları iki kademelidir: kişisel Gmail hesaplarına gönderen herkes SPF veya DKIM, ters DNS, TLS ve düşük spam oranına; günde 5.000 ve üzeri gönderenler ayrıca SPF ve DKIM'e birlikte, DMARC'a, From hizalamasına ve tek tıkla abonelikten çıkışa ihtiyaç duyar. Kurulumun sırası belli: gönderici envanteri, SPF, DKIM, 48 saat sonra DMARC (önce none), hizalamanın sınanması ve rapor okuma. Kimlik doğrulama gelen kutusu garantisi değildir; itibar, listenin onaylı ve çıkışın kolay olmasıyla korunur.

Bültenle ulaştığınız kitleyi reklam verenlere yayıncı olarak sunmak istiyorsanız Akua Adforce'ta tanıtım yazısı ilanlarını inceleyebilirsiniz; kapsam ve koşullar ilgili ürün sayfasında yazılıdır.