SPF Kaydı Nasıl Yazılır? Örnek, include ve 10 Sorgu Sınırı

SPF kaydı, alan adınızın DNS bölgesinde yayımlanan tek satırlık bir TXT kaydıdır ve "bu alan adı adına hangi sunucular ileti gönderebilir" sorusunu yanıtlar. Kaydın "v=spf1" ile başlaması, yetkili göndericilerin include, ip4 veya mx gibi mekanizmalarla sıralanması ve en sonda bir all mekanizmasının bulunması gerekir. Bir alan adı için yalnızca bir SPF kaydı olabilir ve değerlendirme sırasında en fazla 10 DNS sorgusu üreten terim kullanılabilir. Bülten, sipariş bildirimi ya da iletişim formu e-postası gönderen blog ve site sahipleri için asıl zorluk söz diziminden çok, kayda hangi sistemlerin gireceğine karar vermektir.

Abonelerden onay alma tarafı bu konunun dışındadır; onun için e-bülten aboneliği ve KVKK yazısına bakın. SPF yalnızca teknik yetkilendirmedir: kaydın nasıl yazıldığı, nasıl bozulduğu ve yayımlandıktan sonra nasıl kontrol edildiği aşağıda adım adım yer alıyor.

SPF ne yapar, neyi doğrulamaz

SPF, RFC 7208 (yeni sekmede açılır) tarafından tanımlanan bir yetkilendirme yöntemidir. Alan adının sahibi DNS'te hangi IP adreslerinin ve hizmetlerin kendi adına ileti göndermeye yetkili olduğunu yazar; alıcı sunucu, ileti gelen IP adresini bu listeyle karşılaştırır ve bir sonuç üretir.

Hangi kimlik denetlenir

RFC 7208, doğrulayıcıların HELO kimliğini ayrıca denetlemesini önerir (Bölüm 2.3) ve MAIL FROM (zarf gönderen) kimliğini mutlaka denetlemesini şart koşar (Bölüm 2.4). Bu kimlikler, iletiyi okuyan kişinin posta programında gördüğü From satırıyla aynı şey değildir. Dolayısıyla SPF'nin "geçti" demesi, görünen gönderici adresinin sahte olmadığını tek başına kanıtlamaz. Görünen From alan adı ile SPF sonucunu ilişkilendiren katman DMARC'tır ve hizalama kavramını kullanır. Bu konu DKIM ve DMARC yazılarının alanıdır.

Gmail açısından SPF'nin yeri

Google'ın e-posta göndericisi yönergeleri sayfası (yeni sekmede açılır), kişisel Gmail hesaplarına ileti gönderen herkesten gönderen alan adı için SPF veya DKIM kurmasını ister. Günde 5.000 ve üzeri ileti gönderenler için SPF ve DKIM'in ikisi de gerekir. Sayfa ayrıca alan adınızın tüm e-posta göndericilerini içeren bir SPF kaydı yayımlamanızı söyler ve listelenmemiş üçüncü taraf göndericilerin spam olarak işaretlenme ihtimalinin yüksek olduğunu belirtir. Sayfada DNS sorgu sınırı gibi SPF ayrıntıları yoktur; bunlar için RFC 7208'e bakmak gerekir. Google belgelerindeki sınırlar ve şartlar değişebilir; uygulamadan önce güncel sayfayı okuyun.

Yedi sonuç değeri

RFC 7208 Bölüm 2.6, bir değerlendirmenin yedi sonuçtan birini üreteceğini söyler. Aşağıdaki tablo bu sonuçları bir site sahibinin ilgilenebileceği yönüyle özetler.

RFC, temperror için "geçici (genellikle DNS) hata", permerror için "kesinlikle DNS operatörünün müdahalesini gerektiren" ifadelerini kullanır (Bölüm 2.6.6 ve 2.6.7). Yani permerror bir uyarı değil, düzeltilmesi gereken bir hatadır.

TXT kaydının söz dizimi

SPF kaydı DNS'te TXT türünde yayımlanır; RFC 7208 Bölüm 3.1, ayrı SPF kayıt türünün kullanımının sonlandırıldığını söyler. Kayıt, doğrudan e-posta adresinin alan adının sahip adı altında bulunur, alt alan adında değil (Bölüm 3). Yani example.com adına gelen iletiler için kayıt example.com üzerindedir.

Sürüm ve mekanizmalar

Kayıt "v=spf1" ile başlar (Bölüm 4.5). Ardından mekanizmalar gelir. RFC'nin mekanizma listesi (Bölüm 4.6.1) all, include, a, mx, ptr, ip4, ip6 ve exists mekanizmalarını sayar. Pratikte bir site sahibinin karşılaşacakları şunlardır:

RFC, ptr mekanizması için "(do not use)" başlığını koyar ve bu mekanizmanın yayımlanmaması gerektiğini yazar (Bölüm 5.5). Yeni bir kayıtta ptr kullanmak için bir neden yoktur.

Niteleyiciler

Her mekanizmanın önüne isteğe bağlı bir niteleyici konabilir: "+" pass, "-" fail, "~" softfail, "?" neutral anlamına gelir. Niteleyici yazılmazsa varsayılan "+" olur (Bölüm 4.6.2). Bu yüzden "mx" ile "+mx" aynı anlama gelir. Kaydın sonuna konan "-all" kayıtta açıkça yetkilendirilmeyen her şey için fail üretir; "~all" softfail üretir. Hangi niteleyiciyle başlayacağınız bir tercihtir. Uygulama önerisi: gönderici envanterinizden emin değilseniz kaydı önce "~all" ile yayımlayıp sorunsuz çalıştığını gördükten sonra "-all"a geçin. Bu öneri RFC'de yazmaz; RFC yalnızca niteleyicilerin hangi sonucu ürettiğini tanımlar.

all mekanizması ve sıra

RFC 7208 Bölüm 5.1'e göre all mekanizması en sağda durmalıdır; kendisinden sonra yazılan mekanizmalar yok sayılır. Bu yüzden "v=spf1 -all include:servis.example" kaydında include hiçbir zaman değerlendirilmez. Ayrıca kayıtta all mekanizması varsa redirect değiştiricisi yok sayılır (Bölüm 5.1 ve 6.1).

IP aralıkları

ip4 ve ip6 için CIDR uzunluğu eğik çizgiden sonra yazılır; ip4 için 0 ile 32, ip6 için 0 ile 128 arası geçerlidir. Uzunluk yazılmazsa ip4 için /32, ip6 için /128 varsayılır. Kısmi adres yazılamaz; "192.0.2." yerine "192.0.2.0/24" gibi tam bir aralık verilmelidir (Bölüm 5.6).

Uzunluk: 255 ve 512 sınırları

DNS'te tek bir TXT karakter dizisi en fazla 255 sekizli taşıyabilir. Daha uzun bir SPF kaydı birden fazla dizi olarak yazılabilir ve RFC, bu dizilerin aralarına boşluk eklenmeden birleştirileceğini söyler (Bölüm 3.3). Bölüm 3.4 ise kaydın sorgu yanıtının 512 sekiziye sığacak kadar küçük kalmasını önerir. DNS panelinizin bölmeyi kendisinin yapıp yapmadığı panele göre değişir; panel uzun bir kaydı kabul etmiyorsa tırnaklı parçalara bölme seçeneğini araştırın.

Örnek kayıt ve parçaları

Aşağıdaki kayıt kurgusal bir örnektir; alan adları ve IP adresi belgelerde örnek olarak ayrılmış değerlerdir.

v=spf1 ip4:192.0.2.10 include:_spf.postaservisi.example mx ~all

Kayıt hangi alan adına yazılır

SPF kaydı, ait olduğu sahip adı altında yayımlanır; bir üst alan adındaki kayıt kendiliğinden alt alan adlarını kapsayan bir kayıt değildir (RFC 7208, Bölüm 3). Bu yüzden iletinin zarf göndereni hangi alan adını taşıyorsa, sorgu o alan adına yapılır.

Alt alan adları ve ayrı akışlar

Bülteni bulten.siteadi.example gibi bir alt alan adından gönderiyorsanız, o alt alan adının kendi SPF kaydı olmalıdır. Ana alan adının kaydına eklediğiniz terimler bu alt alan adındaki zarf göndereni için sorgulanan kayıt olmaz. Alt alan adı kullanmanın bir yararı da sorgu sınırının her ad için ayrı işlemesidir; ana alan adı kaydınız sade kalırken bülten akışının kaydı kendi içinde yönetilir. Uygulama önerisi: pazarlama ve işlem e-postalarını farklı adlara ayırırsanız bir akıştaki sorun diğerinin kaydını bozmaz.

HELO kimliği

RFC, doğrulayıcıların HELO kimliğini de ayrıca denetlemesini önerir (Bölüm 2.3). Kendi sunucunuzdan ileti gönderiyorsanız sunucunun HELO'da bildirdiği ana bilgisayar adının da bir SPF kaydı olması bu denetimin anlamlı sonuç vermesini sağlar. E-posta servisi kullanıyorsanız bu ad servise aittir ve kaydı servis yönetir.

E-posta göndermeyen alan adları

Hiç ileti göndermeyen bir alan adı için kayıt yazmak da mümkündür: yalnızca "v=spf1 -all" içeren bir kayıt hiçbir IP adresini yetkilendirmez ve her şey için fail üretir. Bu bir söz dizimi sonucudur; RFC mekanizmaların hiçbirini zorunlu kılmaz, all ise varsayılan sonucu belirler (Bölüm 5.1). Uygulama önerisi: yatırım amaçlı satın alınmış ya da yönlendirme için tutulan alan adlarınız varsa, ileti göndermediğinizi DNS'te de belirtmek sahte gönderimin önünde bir engel koyar. Bu önerinin etkisi alıcıların SPF sonucuna nasıl tepki verdiğine bağlıdır.

include ve birden fazla gönderici

Bir site tek bir sunucudan değil, birkaç sistemden ileti gönderebilir: bülten servisi, site sunucusu, destek sistemi. Hepsinin yetkisi tek kayıtta toplanmalıdır.

Tek kayıt kuralı

RFC 7208 Bölüm 4.5'e göre bir alan adı için birden fazla SPF kaydı bulunursa sonuç permerror olur. Bölüm 3.2 de bir alan adında birden fazla kaydın seçilmesine yol açacak durumun bulunmaması gerektiğini yazar. Yeni bir servis eklerken sağlayıcının önerdiği kaydı ayrı bir satır olarak eklemek bu yüzden bir hatadır; servisin include terimini mevcut kayda eklemelisiniz. Servis dokümanı "şu TXT kaydını ekleyin" dese bile, o kaydı mevcut kayıtla birleştirmek sizin işiniz.

include nasıl çalışır

include mekanizması, başka bir alan adının SPF kaydını değerlendirir. RFC Bölüm 5.2'ye göre yalnızca başvurulan kaydın değerlendirme sonucu kullanılır: pass eşleşme sayılır; fail, softfail ve neutral eşleşmeme sayılır; temperror ve permerror hata olarak döner; başvurulan alan adında SPF kaydı yoksa (none) sonuç permerror olur. İçerideki kayıtta "-all" bulunması da genel değerlendirmeyi sonlandırmaz. Bu ayrıntı pratikte şunu söyler: bir servisin kaydındaki "-all", sizin kaydınızdaki diğer mekanizmaların çalışmasını engellemez.

redirect: tüm kaydı başka bir alana devretmek

redirect değiştiricisi, hiçbir mekanizma eşleşmediğinde değerlendirmeyi başka bir alan adının kaydına devreder; hedefte kayıt yoksa ya da hedef bozuksa sonuç none değil permerror olur (Bölüm 6.1). Birçok alan adı için aynı gönderici kümesini tek yerde yönetmek isteyen kurumlar bunu kullanabilir. Tek bir bloğun sahibi için gerekli olmayabilir.

Örnek senaryo: çevrimiçi kurs sitesi

Örnek senaryo: Çevrimiçi bir kurs sitesi dersleri kendi sunucusunda yayımlıyor, duyuruları bir bülten platformundan, öğrenci yardımlarını bir destek sisteminden gönderiyor. Site sahibi önce kendi sunucusunun IP'sini ip4 ile ekliyor. Bülten platformu için servisin önerdiği include terimini aynı kayda ekliyor. Destek sistemi ise yalnızca kendi alan adında gönderim yaptığı için kayda eklemeyi gerektirmeyebilir; bunu karara bağlamak için sistemin dokümanında zarf göndereni olarak hangi alan adını kullandığına bakıyor. Sonunda yalnızca bir SPF kaydı var ve her terimin neden orada olduğunu not almış durumda. Üç ay sonra bir servisi bıraktığında hangi terimi kaldıracağını bilecek.

Kaydı sade tutmak için kural

1. Her terimin yanına bir not yazın: hangi sistem, hangi sahip, ne zaman eklendi.
2. Kullanılmayan servisin terimini silin; eski bir terim, artık sizin olmayan bir gönderim yoluna yetki vermeye devam eder.
3. Bir servisin kaydı ip4 aralıkları sunuyorsa ve aralık sabitse, include yerine ip4 kullanmak sorgu sayısını azaltır; ancak servis aralığı değiştirdiğinde kaydınız eskir. Bu bir takas olduğundan, yalnızca sağlayıcı aralığın sabit olduğunu belgeliyorsa tercih edin.

DNS sorgu sınırı ve sık hatalar

SPF kayıtlarının en sinsi sorunu, kaydın ilk bakışta doğru görünmesine rağmen değerlendirme sırasında sınırı aşmasıdır.

10 terimlik sınır

RFC 7208 Bölüm 4.6.4'e göre include, a, mx, ptr ve exists mekanizmaları ile redirect değiştiricisi DNS sorgusuna yol açar ve uygulamalar bu terimlerin toplamını değerlendirme sırasında 10 ile sınırlamalıdır. Sınır aşılırsa sonuç permerror olur. all, ip4 ve ip6 DNS sorgusu yaptırmadığı için bu sınıra dahil değildir. Terimler iç içe kayıtların içinde de sayıldığı için, kendi kaydınızda 4 include varsa bu include'ların içindeki include'lar da toplama eklenir. Bu yüzden bir bülten servisi, bir pazarlama otomasyonu ve bir destek aracı ekleyen bir site, farkında olmadan sınıra yaklaşabilir.

mx ve void sorgular

Bölüm 5.4'e göre her mx sorgusu 10 terimlik sınıra sayılır ve her MX kaydı en fazla 10 A/AAAA sorgusu tetikleyebilir; bu sınır aşılırsa yine permerror üretilir. Ayrıca Bölüm 4.6.4, sonuç döndürmeyen ("void") sorguların iki ile sınırlanmasını önerir; bu bir SHOULD ifadesidir ve aşılırsa permerror sonucu beklenir. Yazım hatası yapılmış ya da silinmiş bir include hedefi bu sınıra takılabilir.

Sınırı aşmamak için seçenekler

• Kullanılmayan include terimlerini kaldırın.
• Aynı IP aralığına çözülen a ve mx terimlerini tek bir ip4 terimiyle değiştirmeyi düşünün, ancak IP değişirse kaydı güncellemeyi unutmayın.
• Farklı akışları ayrı alt alan adlarına bölün; her alt alan adının kendi SPF kaydı ve kendi 10 terimlik sınırı olur.
• Kayıt çok uzadıysa sağlayıcılarla konuşup aralıkları sabitleyen ya da daha az sorgu gerektiren bir yapı isteyin.

Sık yapılan hatalar

Sıfırdan kayıt oluşturma: altı adım

Bir SPF kaydını ilk kez yazıyorsanız aşağıdaki sıra, eksik ya da fazla terimi en baştan önler.

1. Alan adı adına ileti gönderen her sistemi listeleyin: bülten servisi, site sunucusu, destek sistemi, ödeme veya fatura servisi, ekip üyelerinin posta kutuları.
2. Her sistem için zarf göndereni olarak hangi alan adının kullanıldığını öğrenin. Servis, zarf göndereni olarak kendi alan adını kullanıyorsa o akış için sizin SPF kaydınız değerlendirilmez.
3. Sizin alan adınız zarf göndereni olan sistemler için sağlayıcının verdiği include terimini ya da IP aralığını not edin.
4. Terimleri v=spf1 ile başlayan tek bir satırda birleştirin ve all mekanizmasını en sona koyun.
5. Include, a ve mx terimlerini sayın; iç içe kayıtları da hesaba katın. Toplam 10'u aşmamalıdır.
6. Satırı DNS panelinde ana alan adı için TXT kaydı olarak yayımlayın; mevcut bir SPF satırı varsa onu değiştirin, yanına yenisini eklemeyin.

Sorgu sayımı için çalışma tablosu

Aşağıdaki kayıt örnek bir kayıttır: v=spf1 ip4:192.0.2.10 include:_spf.bulten.example include:_spf.destek.example mx -all. Sayım şöyle yapılır.

Toplam, 3 artı iki include kaydının içindeki include, a, mx, ptr, exists ve redirect terimleridir. İç terimleri öğrenmek için ilgili servisin yayımladığı kaydı sorgulayın. Kayıt değişirse sayı da değişir; sağlayıcılar kendi kayıtlarını sizden habersiz güncelleyebilir. Bu yüzden sayımı yalnızca kayıt yazılırken değil, sağlayıcı değiştirdiğinde ve belirli aralıklarla yeniden yapın.

Servis değiştirirken geçiş

Bülten servisini değiştirirken önce yeni servisin include terimini kayda ekleyin, yeni servisin gönderimi sorunsuz geçtiğini test iletileriyle doğrulayın, eski servisin gönderimini durdurun ve en son eski terimi silin. Sırayı tersine çevirirseniz geçiş döneminde yeni servisin iletileri fail veya softfail üretebilir. İki servis aynı anda bir süre kullanılacaksa ikisinin terimini birlikte tutun; terimlerin toplamını 10 sınırına karşı kontrol etmeyi unutmayın.

Hangi bilgiyi kimden isteyin

Yayından sonra kontrol

SPF kaydını yayımlamak işin yarısıdır. Kaydın DNS'te doğru görünmesi, değerlendirmenin sonuca ulaşması ve gerçek iletilerin geçmesi ayrı kontrollerdir.

Üç kademeli kontrol

1. Kayıt doğru alan adında, TXT türünde ve tek bir kayıt olarak görünüyor mu? DNS sorgu aracıyla alan adının TXT kayıtlarını listeleyin ve "v=spf1" ile başlayan satırları sayın.
2. Kayıt değerlendirilince sonuç veriyor mu? Çevrimiçi bir SPF denetleyicisi sorgu sayısını ve permerror durumunu gösterir. Hangi aracı seçerseniz seçin, 10 terim sınırını ve tek kayıt kuralını RFC'deki sayılara göre okuyun.
3. Gerçek bir ileti geçiyor mu? Her gönderici sistemden kendi gelen kutunuza bir test iletisi gönderin ve ileti başlıklarında SPF sonucunu bulun. Başlık adları ve görünüm posta servisine göre değişir.

Değişiklikten sonra beklenecek şeyler

DNS değişikliklerinin yayılma süresi sağlayıcıya ve TTL değerine bağlıdır. Gmail ve Workspace sayfalarında bu konuda bir süre yoktur; Google Workspace DMARC sayfası SPF veya DKIM kurulumundan sonra DMARC için 48 saat beklenmesini ister, ancak bu SPF kaydının yayılma süresi değildir. Yeni bir kaydı yayımladıktan sonra aynı gün içinde test iletileri gönderirseniz eski sonucu görebilirsiniz; tekrar denemeden önce biraz bekleyin.

Yayın sonrası kontrol listesi

• Alan adında yalnızca bir "v=spf1" kaydı var.
• Kayıt "all" ile bitiyor ve all'dan sonra terim yok.
• include, a ve mx terimlerinin toplamı (iç içe kayıtlar dahil) 10'u aşmıyor.
• Kayıtta ptr yok.
• Bülten, site sunucusu ve destek sisteminden gelen test iletilerinde SPF sonucu pass.
• Her terimin sahibini ve eklenme nedenini gösteren bir not var.

Sonuç değerinden nedene gitmek

Test iletisinde gördüğünüz sonuç, sorunun yerini gösterir. Aşağıdaki tablo, RFC 7208'deki sonuç tanımlarından türetilmiş bir ilk bakış rehberidir.

İleti başlığında SPF sonucunu okurken ileti başlığındaki IP adresinin ve zarf gönderen alan adının sizin beklediğiniz değerler olup olmadığına da bakın. Beklenmedik bir IP ya da alan adı görürseniz sorun kayıtta değil, gönderim yolundadır: ileti sizin bilmediğiniz bir sistemden gelmiştir ve envanterinizde eksik bir gönderici vardır.

Karar kuralı: yeni servisi kayda eklemeden önce

1. Servis, sizin alan adınızı zarf göndereni olarak mı kullanıyor, yoksa kendi alan adını mı? Kendi alan adını kullanıyorsa SPF'nizde ona yer açmanız SPF açısından gerekmeyebilir; yine de DKIM ve hizalama ayrıca kurulmalıdır.
2. Servis include terimi mi, IP aralığı mı veriyor? Include verirse kayıttaki toplam terim sayınızı yeniden sayın.
3. Kayıt yeni terimle birlikte 10 sınırını aşıyorsa servisi ayrı bir alt alan adına taşıyın.

Bu kural Gmail veya RFC'nin yazdığı bir kural değil, onların şartlarından türetilmiş bir uygulama önerisidir.

SPF'nin yanında ne yapmalı

SPF, Gmail sayfasında DKIM ile birlikte anılan iki kimlik doğrulama yönteminden biridir; üst kademede ikisi birden gerekir. Bültenle ilgili diğer iş kalemleri de SPF kadar önemlidir: bültende sponsorlu bölüm varsa sponsorlu içerik etiketleme kurallarına bakın, abone sayısını reklam verenlere sunacaksanız medya kiti hazırlama yazısındaki bilgileri doğru ve güncel tutun, bültendeki bağlantıların tıklamasını ölçmek istiyorsanız UTM ve Search Console raporlaması bir başlangıç sağlar.

Sık Sorulan Sorular

SPF kaydı DNS'te hangi türde yayımlanır?

RFC 7208 Bölüm 3.1'e göre SPF kaydı TXT türünde yayımlanır; ayrı SPF kayıt türünün kullanımı sonlandırılmıştır. Kayıt, gönderen alan adının kendi adı altında bulunur ve v=spf1 ile başlar.

Bir alan adında birden fazla SPF kaydı olabilir mi?

Hayır. RFC 7208 Bölüm 4.5'e göre kayıt kümesi birden fazla SPF kaydı içeriyorsa sonuç permerror olur. Yeni bir servis eklerken önerilen kaydı ayrı satır olarak eklemek yerine terimini mevcut kayda ekleyin.

SPF'de 10 DNS sorgusu sınırı nedir?

RFC 7208 Bölüm 4.6.4'e göre include, a, mx, ptr ve exists mekanizmaları ile redirect değiştiricisi sorgu yaptırır ve uygulamalar bu terimleri değerlendirme sırasında 10 ile sınırlamalıdır. Aşılırsa sonuç permerror olur. all, ip4 ve ip6 sınıra dahil değildir.

~all ile -all arasındaki fark nedir?

Niteleyiciler RFC 7208 Bölüm 4.6.2'de tanımlıdır: "-" fail, "~" softfail üretir. Alıcının bu sonuçlarla ne yapacağı RFC'nin dışında alıcı politikasına bağlıdır. Uygulama önerisi: envanterden emin olunca -all'a geçmek mümkündür, ama bu bir resmi kural değildir.

SPF kaydım doğru ama ileti spama düşüyor, neden?

SPF yalnızca zarf gönderen alan adı için yetkilendirmeyi denetler. Gmail sayfasına göre spam oranı, DKIM, DMARC ve hizalama gibi ayrı etkenler de vardır. SPF geçmesi, iletinin gelen kutusuna düşeceğini garanti etmez.

SPF kaydını yayımladıktan sonra nasıl kontrol ederim?

Alan adının TXT kayıtlarında yalnızca bir v=spf1 satırı olduğunu doğrulayın, çevrimiçi bir SPF denetleyicisiyle sorgu sayısına ve permerror durumuna bakın, ardından her gönderici sistemden test iletisi gönderip başlıklarda SPF sonucunu okuyun.

Sonuç

SPF kaydı tek satırlık bir TXT kaydıdır: "v=spf1" ile başlar, yetkili göndericileri ip4, include, mx gibi mekanizmalarla sıralar ve "all" ile biter. Bir alan adı için yalnızca bir kayıt olabilir, değerlendirme sırasında en fazla 10 sorgu yaptıran terim kullanılabilir ve ptr kullanılmamalıdır. Yayımladıktan sonra tek kayıt, terim sayısı ve gerçek iletilerdeki sonuç ayrı ayrı kontrol edilir. SPF zarf göndereni denetler; görünen From alan adıyla ilişki DMARC hizalamasında kurulur ve SPF tek başına teslimat garantisi vermez.

Bültenle ulaştığınız kitleyi reklam verenlere 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.