Kā iestatīt SPF ierakstu: praktisks ceļvedis 2026

SPF ieraksta iestatīšana ir viens no trim obligātajiem autentifikācijas soļiem jebkuram sūtīšanas domēnam 2026 (kopā ar DKIM un DMARC). Tas izskatās maldinoši vienkārši — viens TXT ieraksts DNS — bet kļūdu režīmi ir konkrēti, un lielākā daļa komandu, kas iestata SPF nepareizi, neatklāj problēmu, līdz placement rādītāji jau ir sabrukuši. Šis raksts iet cauri SPF iestatīšanai soli pa solim ar sintaksi, kas svarīga, tipiskām kļūdām un verifikācijas soļiem. Pāris ar e-pasta piegādes ceļvedi un SPF/DKIM/DMARC iestatīšanas pārskatu.

SPF (Sender Policy Framework) ir DNS-bāzēts autentifikācijas mehānisms, kas paziņo saņemošajiem mail serveriem, kuras IP adreses ir autorizētas sūtīt e-pastu jūsu domēna vārdā. Pareizi konfigurēts SPF ieraksts samazina iespēju, ka jūsu e-pasti tiks atzīmēti kā spams vai noraidīti. Nepareizi konfigurēts — pārāk daudz DNS lookups, nepareiza sintakse, trūkstoši sūtītāji — aktīvi bojā piegādi.

Ko SPF ieraksts patiešām dara

Kad e-pasts pienāk saņemošajā mail serverī, serveris pārbauda e-pasta “from” domēnu un meklē šī domēna SPF ierakstu DNS. SPF ieraksts satur autorizēto sūtītāju sarakstu (IP adreses, hostname vai trešo pušu servisi). Ja e-pasta sūtīšanas IP atbilst kādam no autorizētajiem sūtītājiem, SPF iziet. Ja neatbilst, SPF neizdodas — un lielākā daļa saņemošo sistēmu izturas pret SPF neveiksmēm kā spēcīgu spam signālu.

Pats SPF ieraksts ir plain text DNS ieraksts (TXT ieraksts) jūsu sūtīšanas domēna saknē. Piemērs:

v=spf1 include:_spf.google.com include:spf.smartlead.ai ~all

Tas tulkojas kā: “Mail no šī domēna ir autorizēts nākt no Google Workspace sūtīšanas infrastruktūras vai no Smartlead sūtīšanas infrastruktūras. Jebkas cits jāsoft-fail.”

Daļas, kas svarīgas:

• v=spf1 — versijas identifikators; vienmēr sākumā
• include:domain.com — deleģēt autorizāciju citam domēna SPF ierakstam (visizplatītākais mehānisms)
• a / mx — autorizēt paša domēna A ierakstu vai MX ierakstu
• ip4:1.2.3.4 — autorizēt konkrētu IPv4 adresi
• ~all / -all — noklusējuma fall-through: ~all ir soft-fail (rekomendēts lielākajai daļai gadījumu), -all ir hard-fail (stingrs)

Solis-pa-solim iestatīšana

Pamata workflow SPF ieraksta iestatīšanai:

1. solis: Identificējiet visus jūsu sūtīšanas servisus. Pirms ieraksta rakstīšanas uzskaitiet katru servisu, kas sūta e-pastu “no” jūsu domēna. Izplatīti: Google Workspace vai Microsoft 365 (jūsu day-to-day e-pasts), cold email rīks (Smartlead, Lemlist, Instantly, Apollo), jebkurš transakcionāls e-pasta piegādātājs (SendGrid, Mailgun, Postmark), jebkurš CRM, kas sūta e-pastus, jebkurš marketinga e-pasta rīks. Viena izlaišana nozīmē, ka e-pasti no šī servisa neizturēs SPF.

2. solis: Iegūstiet include: vērtību katram servisam. Katrs sūtīšanas serviss publicē savu SPF include vērtību dokumentācijā. Piemēri (verificējiet pret pašreizējo doku):

• Google Workspace: include:_spf.google.com
• Microsoft 365: include:spf.protection.outlook.com
• Smartlead: include:spf.smartlead.ai (vai līdzīgi — check current docs)
• SendGrid: include:sendgrid.net
• Mailgun: include:mailgun.org

3. solis: Uzbūvējiet SPF ieraksta virkni. Apvienojiet include ar versiju un fall-through:

v=spf1 include:_spf.google.com include:spf.smartlead.ai ~all

Kārtība stingri nesvarīga, bet turiet lasāmu.

4. solis: Pievienojiet TXT ierakstu DNS. Ielogojieties DNS piegādātājā (Cloudflare, AWS Route53, GoDaddy, Namecheap — ko izmantojat), naviģējiet uz sūtīšanas domēna DNS ierakstiem, pievienojiet jaunu TXT ierakstu:

• Host/Name: @ (vai atstājiet tukšu, atkarībā no piegādātāja — pārstāv saknes domēnu)
• Type: TXT
• Value: SPF virkne no 3. soļa
• TTL: noklusējums (parasti 3600 sekundes / 1 stunda)

5. solis: Gaidiet DNS izplatīšanos. Parasti 5–60 minūtes atkarībā no DNS piegādātāja un TTL iestatījumiem. Daži piegādātāji izplata sekundēs; citi prasa ilgāk.

6. solis: Verificējiet ierakstu. Eksistē vairāki verifikācijas rīki. Vienkāršākais: dig +short TXT yourdomain.com no termināļa. Jums vajadzētu redzēt savu SPF virkni. Online rīki (MXToolbox, DMARC Analyzer SPF checker) dara to pašu plus sintakses validāciju.

DNS lookup limits

Visizplatītākais SPF neveiksmes režīms 2026: 10 DNS lookup limita pārsniegšana. Katrs include: mehānisms skaita kā viens DNS lookup, un include var būt nested include, kas arī skaita. SPF ieraksti, kas pārsniedz 10 lookups, neizdodas “permerror” — ko lielākā daļa saņemošo sistēmu izturas kā SPF neveiksmi.

Izplatīti scenāriji, kas pārsniedz limitu:

• Vairāki sūtīšanas servisi ar dziļām include ķēdēm (Salesforce SPF nest cauri vairākiem slāņiem; HubSpot tāpat)
• Katra transakcionālā servisa pievienošana “just in case” bez lookup count pārbaudes
• Mantojot vecu SPF ierakstu, kas ietvēra servisus, kas vairs netiek izmantoti

Risinājums: skaitiet savus lookups. Rīki kā Kitterman SPF Test vai MXToolbox SPF Surveyor rāda lookup count. Ja esat virs 10, jums vajag flatten vai konsolidēt.

Flattening nozīmē include: mehānismu aizstāšanu ar apakšā esošajām IP adresēm, ko tie autorizētu. Rīki kā SPFlat vai PowerDMARC flattening serviss var to darīt automātiski. Trade-off: flattened ieraksti neauto-atjauninās, kad upstream serviss maina IP, tāpēc tiem vajag periodisku re-flattening.

Konsolidācija nozīmē tādu servisu noņemšanu, kurus jūs reāli neizmantojat. Auditējiet sūtīšanas stack ceturkšņa un noņemiet SPF includes servisiem, kurus pārstājāt izmantot.

Tipiskas SPF iestatīšanas kļūdas

+all vai ?all pievienošana ~all vai -all vietā. +all nozīmē “jebkurš var sūtīt no šī domēna” — pilnībā uzvar SPF mērķi. ?all nozīmē “mums nav viedokļa” — gandrīz tikpat slikti. Vienmēr izmantojiet ~all (soft-fail) vai -all (hard-fail).

Hard-failing (-all) bez testēšanas. -all saka saņemošajiem serveriem noraidīt e-pastu, kas neatbilst SPF ierakstam. Ja jūsu SPF ieraksts ir nepilnīgs vai nepareizs, -all noved pie leģitīma e-pasta noraidīšanas. Produkcijas komandas izmanto ~all, kamēr SPF nav verificēts kā strādājošs cauri visiem sūtīšanas servisiem, tad pēc izvēles pievelk uz -all.

Vairāki SPF ieraksti vienā domēnā. Dažas komandas pievieno otru SPF ierakstu, pievienojot jaunu servisu, esošā vietā rediģēšanas. SPF specifē tikai vienu ierakstu uz domēnu — vairāki ieraksti rada “permerror”. Vienmēr rediģējiet esošo ierakstu; nekad nepievienojiet otru.

Including servisi, kas iekļauj viens otru. Dažu sūtīšanas servisu SPF jau iekļauj citus izplatītos servisus. Abu pievienošana ražo redundant lookups, kas skaita uz 10-lookup limita, nepievienojot pārklājumu.

SPF iestatīšana nepareizajā domēna līmenī. Ja sūtāt no mail.company.com, SPF ierakstam jābūt uz mail.company.com, ne uz company.com. Subdomain ir savas SPF prasības, kad izmantoti kā sūtīšanas domēni.

Aizmiršana pievienot SPF, sākot cold email. Komandas, kas sāk cold email kampaņu bez SPF iestatīšanas sūtīšanas domēnā, redz tūlītēju placement sabrukumu — lielākā daļa saņemošo sistēmu smagi soda neautentificētu mail 2026.

Netestējot pēc izmaiņām. Katrai SPF izmaiņai jābūt verificētai stundas laikā pēc izplatīšanās. Online testeri kā MXToolbox vai PowerDMARC checker apstiprina, ka ieraksts ir sintaktiski derīgs un lookup limitu robežās.

Ko darīt pēc tam, kad SPF ir iestatīts

SPF viens pats nav pietiekams. Trim lietām vajadzētu sekot:

1. Iestatiet DKIM tam pašam domēnam — apskatīts detalizēti kā iestatīt DKIM. DKIM pievieno kriptogrāfisku parakstu virs SPF IP autorizācijas.
2. Iestatiet DMARC, kad SPF un DKIM abi strādā — apskatīts DMARC policy: quarantine vs reject. DMARC sasaista SPF un DKIM ar alignment pārbaudi un policy paziņojumu.
3. Monitorējiet SPF rezultātus caur DMARC atskaitēm. Tiklīdz DMARC ir iestatīts, saņemošās sistēmas nosūtīs aggregate atskaites, kas rāda, kuri IP sūtīja mail, claiming būt no jūsu domēna, un vai SPF izturēja katram. Šī ir feedback cilpa SPF problēmu ķeršanai.

SPF iestatīšana 2026 ir 30 minūšu uzdevums, kad izdarīts pareizi, un vairāku nedēļu piegādes katastrofa, kad izdarīts nepareizi. Visnoderīgākā disciplīna ir paņemt 30 minūtes, iestatīt rūpīgi, verificēt ar vairākiem rīkiem un re-verificēt, kad mainās sūtīšanas stack. SPF/DKIM/DMARC iestatīšanas pārskats aptver, kā visi trīs gabali strādā kopā.