Podešavanje DKIM-a, SPF-a i DMARC-a za hladne email kampanje većeg obima

01 / Potpisivanje poruka

Podesite DKIM kod servisa koji zaista šalje poruke.

Počnite u servisu koji šalje vaše poruke, a ne samo u alatu koji ih zakazuje. DomainKeys Identified Mail (DKIM) koristi privatni ključ za potpisivanje poruka i javni DNS ključ za njihovu proveru. Privatni ključ treba da ostane kod provajdera koji šalje poruke.

1. Popišite sve pošiljaoce. Uključite provajdera email naloga, CRM i svaki zaseban servis za isporuku. Sačuvajte postojeće DNS zapise pre izmene.
2. Generišite DKIM zapise kod provajdera. Koristite njegova podešavanja za autentifikaciju domena. Pratite smernice za dužinu ključa; Google Workspace preporučuje ključeve od 2048 bita gde su podržani.
3. Objavite tačno dobijene zapise. Provajder može da vam dostavi javni ključ u TXT zapisu ili CNAME odredišta. Koristite dostavljeni selektor, tip zapisa i vrednost; oni nisu međusobno zamenljivi.
4. Proverite zapise, pa uključite potpisivanje. Neki provajderi zahtevaju poseban korak aktivacije. Sam DNS zapis ne potvrđuje da su odlazne poruke potpisane.

outreach1._domainkey.example.com
│                     │
DKIM selektor         Domen potpisa

Javni upit: selector._domainkey.signing-domain

Ovde je outreach1 samo primer selektora. Svoj kopirajte od provajdera. DNS paneli često automatski dodaju domen: unos punog naziva u polje za relativni naziv može slučajno da udvostruči domen. Proverite konačni naziv hosta.

Primer kod provajdera: Podešavanje DKIM-a u Google Workspace-u.

02 / Ovlašćivanje pošiljaoca

Održavajte SPF zapis tačnim.

Sender Policy Framework (SPF) proverava IP adresu pošiljaoca prema domenu pošiljaoca iz omotnice, koji se naziva i MAIL FROM. On se može razlikovati od vidljive From adrese. Ako povratnom putanjom upravlja provajder, proverite kom domenu je vaš SPF zapis zaista potreban.

1. Pronađite postojeći zapis. Potražite TXT vrednost koja počinje sa v=spf1 na odgovarajućem domenu.
2. Objedinite ovlašćene izvore. Održavajte jedan SPF zapis po nazivu hosta. Nemojte dodavati drugi SPF zapis kada povezujete novog pošiljaoca.
3. Proverite broj DNS upita. SPF tokom provere ograničava broj elemenata koji pokreću DNS upite na deset, uključujući ugnježdene include elemente. Nije dovoljno brojati samo vidljive include elemente.

example.com.  TXT  "v=spf1 ip4:192.0.2.10 -all"

Ovaj primer ovlašćuje jedan izmišljeni server; -alloznačava da ostali pošiljaoci ne prolaze SPF proveru. Ovaj zapis nije namenjen kopiranju u produkciju. Email provajderi obično daju sopstvene vrednosti. Sačuvajte legitimne izvore i potvrdite konačnu politiku sa provajderom.

Izvori: Microsoft uputstvo za SPF podešavanje i Ograničenja broja SPF upita.

03 / Usklađenost domena

Jasno proverite DMARC usklađenost.

DMARC prolazi kada najmanje jedna metoda autentifikacije prođe i bude usklađena sa vidljivim From domenom: SPF-ov MAIL FROM domen ili DKIM-ov d= domen potpisa. Uspešan SPF ili DKIM za nepovezan domen provajdera nije dovoljan.

Opuštena usklađenost, koja je podrazumevana, upoređuje organizacione domene; stroga usklađenost zahteva potpuno isti domen. Potvrdite da provajder podržava usklađeni DKIM ili odgovarajuću prilagođenu povratnu putanju.

Prvo pratite, zatim uvedite strože mere.

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

Pri novom uvođenju, p=none traži da se ne primenjuju posebne DMARC mere dok pregledate izveštaje. To ne isključuje filtriranje neželjene pošte. Koristite email nalog ili servis za izveštaje koji kontrolišete; spoljna odredišta za izveštaje mogu zahtevati DNS ovlašćenje. Nemojte ublažavati postojeću politiku samo da biste pratili ovaj primer.

Prepoznajte legitimne pošiljaoce u izveštajima i ispravite greške pre prelaska na p=quarantine ili p=reject. Te politike traže strože postupanje sa porukama koje ne prođu proveru; primaoci zadržavaju pravo na sopstvene odluke. U pregled uključite transakcione poruke i poruke podrške, a ne samo kampanje kontaktiranja.

Izvori: Usklađenost DMARC identifikatora i Microsoft smernice za uvođenje DMARC-a.

04 / Dokazi pre povećanja obima

Proverite ceo put slanja poruke.

Proverite javni DNS nakon isteka odgovarajućih TTL perioda keširanja, pa pošaljite test preko stvarnog naloga za kampanju na naloge koje kontrolišete. Ove Windows PowerShell komande samo čitaju DNS. Zamenite primer domena i selektora svojim vrednostima.

Resolve-DnsName -Name example.com -Type TXT
Resolve-DnsName -Name outreach1._domainkey.example.com -Type TXT
Resolve-DnsName -Name outreach1._domainkey.example.com -Type CNAME
Resolve-DnsName -Name _dmarc.example.com -Type TXT

Za DKIM koristite TXT ili CNAME upit koji odgovara tipu zapisa vašeg provajdera; nije potrebno da postoje oba tipa. DNS odgovor potvrđuje objavljivanje, a ne uspešnu autentifikaciju. Zatim pregledajte izvorna zaglavlja poruke u prijemnom nalogu.

Authentication-Results: receiver.example.net;
  spf=pass smtp.mailfrom=mail.example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

Pre povećanja obima proverite dozvoljene načine korišćenja kod provajdera, uslove za kontaktiranje primalaca, postupanje sa odjavama i važeće zahteve. Gmail pravila za pošiljaoce koji šalju oko 5.000 ili više poruka dnevno na lične Gmail naloge uključuju SPF, DKIM i DMARC; marketinške poruke i poruke na osnovu pretplate zahtevaju i odjavu jednim klikom. Taj prag nije preporučeni obim slanja.

Povećavajte obim postepeno samo dok rezultati isporuke to opravdavaju. Pratite odbijene poruke, prijave neželjene pošte, odgovore i izveštaje o autentifikaciji, i pauzirajte ako se stanje pogorša. Ponovite proveru nakon promene provajdera, domena ili ključa za potpisivanje. Postepeno uvođenje slanja i uspešna autentifikacija ne garantuju dolazak u prijemno sanduče, odgovore ili prodaju.

Zahtevi prijemnog servisa: Gmail smernice za pošiljaoce emaila. Tehnička uputstva pregledana 29. septembra 2026.