DMARC policy: quarantine vs reject — ko izvēlēties 2026

DMARC policy izvēle ir vieta, kur lielākā daļa komandu ievada piegādes bojājumu, ko viņi neparedzēja. Nepareizā izvēle — parasti lēciens uz reject pārāk agri — ražo tūlītēju placement sabrukumu uz leģitīmā mail. Pareizā izvēle — staged migrācija no none uz quarantine uz (pēc izvēles) reject — ražo pakāpenisku pievilkšanu ar feedback katrā solī. Šis raksts — ko DMARC policies operacionāli nozīmē 2026, kad katrs policy ir piemērots, un migrācijas ceļš, kas nesalauž piegādi pa ceļam. Pāris ar SPF iestatīšanas ceļvedi, DKIM iestatīšanas ceļvedi un SPF/DKIM/DMARC pārskatu.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) sasaista SPF un DKIM kopā ar alignment pārbaudi un policy paziņojumu. Policy paziņo saņemošajiem serveriem, ko darīt, kad autentifikācija neizdodas: neko (none), sūtīt uz spamu (quarantine) vai noraidīt pavisam (reject). Izvēlei ir materiālas sekas piegādei un reputācijai, un lielākajai daļai komandu nevajadzētu sākt ar reject.

Ko DMARC patiešām dara

DMARC ieraksts ir TXT ieraksts pie _dmarc.<yourdomain>. Piemērs:

v=DMARC1; p=none; rua=mailto:reports@yourdomain.com; pct=100; adkim=r; aspf=r

Daļas:

• v=DMARC1 — versija
• p=none|quarantine|reject — policy (ko saņemošie serveri dara ar failing mail)
• rua=mailto:... — kur sūtīt aggregate atskaites
• pct=100 — kāds procents failing mail policy attiecas (noderīgs staged rollouts)
• adkim=r|s — DKIM alignment režīms (relaxed vai strict)
• aspf=r|s — SPF alignment režīms (relaxed vai strict)

DMARC pārbauda divas lietas, kad mail pienāk:

1. Autentifikācija: Vai SPF iziet VAI DKIM iziet?
2. Alignment: Vai SPF vai DKIM domēns atbilst From-adreses domēnam?

Ja abi iziet, DMARC iziet. Ja abi neizdodas, DMARC neizdodas — un policy saka saņemošajam serverim, ko darīt.

Trīs policy režīmi

p=none (monitoringa režīms). Saņemošie serveri ziņo par autentifikācijas rezultātiem, bet nemaina mail apstrādi. Šis ir sākuma punkts katrai komandai. Tas ražo aggregate atskaites (nosūtītas uz rua adresi), kas rāda, kuri sūtīšanas avoti iztur vai neiztur autentifikāciju. Atskaites ir feedback mehānisms, kas ļauj labot autentifikācijas problēmas pirms policy pievilkšanas.

Ilgums none: minimums 2–4 nedēļas, garāk, ja sūtīšanas stack ir sarežģīts. Mērķis ir apstiprināt, ka 100% leģitīmā mail iztur SPF vai DKIM ar pareizu alignment pirms tālāk virzīšanās.

p=quarantine. Saņemošie serveri sūta failing mail uz spamu/junk. Saņēmējs joprojām var atrast, bet neredzēs iesūtnē. Tas ir drošā vidējā nostāja — neveiksmes ir redzami pazeminātas, bet nav zaudētas. Izmantojiet, tiklīdz monitoringa dati rāda, ka autentifikācija ir konsekventa.

Izplatīts rollout: sāciet ar p=quarantine; pct=10 (10% failing mail tiek karantinēts), pakāpeniski celiet pct līdz 100 2–4 nedēļās. pct mehānisms ļauj testēt ietekmi uz mazu apakškopu pirms pilnas izvietošanas.

p=reject. Saņemošie serveri noraida failing mail pavisam. Sūtītājs saņem bounce; saņēmējs nekad neredz. Šis ir visstingrākais policy un ražo spēcīgāko anti-spoofing signālu — bet jebkura autentifikācijas problēma noved pie leģitīmā mail zuduma. Izmantojiet tikai tad, kad autentifikācija ir verificēta strādājoša pie 100% katrā sūtīšanas avotā.

Lielākā daļa B2B komandu 2026 darbojas pie p=quarantine nevis pie p=reject. Enterprise drošības komandas un high-target zīmoli (bankas, valdība, lielas platformas) parasti pārvietojas uz p=reject, jo spoofing risks attaisno operacionālo stingrību.

Migrācijas ceļš

Droša DMARC migrācija izskatās šādi:

Posms 1: SPF un DKIM verificēti strādājoši (nedēļa 0). Pirms DMARC pievienošanas apstipriniet, ka SPF un DKIM abi iztur izejošajam mail no katra sūtīšanas servisa. Izmantojiet galvenes apskati uz testa sūtījumiem, lai verificētu dkim=pass un spf=pass rezultātus.

Posms 2: Pievienojiet DMARC pie p=none (nedēļa 1). Publicējiet DMARC ierakstu ar p=none un rua adresi, kas var saņemt XML atskaites. Lielākā daļa komandu izmanto trešās puses servisu (Postmark DMARC monitoring, dmarcian, EasyDMARC, Valimail), lai parsētu atskaites — manuāla XML aggregate atskaišu lasīšana nemērogojas.

Posms 3: Monitorējiet 2–4 nedēļas (nedēļas 2–5). Pārskatiet DMARC atskaites. Atskaites rāda:

• Kuri sūtīšanas avoti ražoja mail, claiming būt no jūsu domēna
• Vai SPF un DKIM izturēja katram avotam
• Vai alignment turējās

Labojiet jebkuras autentifikācijas neveiksmes (parasti: sūtīšanas serviss, kas nebija iekļauts SPF, vai serviss, kas paraksta ar DKIM, bet neizlīdzinās ar jūsu domēnu).

Posms 4: Pārvietojieties uz p=quarantine; pct=10 (nedēļa 6). Tiklīdz atskaites rāda konsekventu autentifikāciju, sāciet pievilkt. pct=10 nozīmē, ka 10% failing mail tiek karantinēts — zems risks, jo lielākā daļa leģitīmā mail tagad iztur autentifikāciju, un 10% paraugošana rāda, vai kaut kas izlaužas.

Posms 5: Celiet pct pakāpeniski (nedēļas 7–9). Pārvietojieties uz pct=25, tad pct=50, tad pct=100 2–3 nedēļās. Katrā solī monitorējiet atskaites jebkuram leģitīmam sūtīšanas avotam, kas neizdodas.

Posms 6 (pēc izvēles): Pārvietojieties uz p=reject; pct=10 un ramp. Ja jūsu drošības stāvoklis to prasa (finanšu pakalpojumi, valdība, zīmola-aizsardzības-kritiski sektori), atkārtojiet pct-ramp p=reject. Lielākajai daļai B2B cold email sūtītāju p=quarantine; pct=100 ir piemērotais apstāšanās punkts.

Visa migrācija aizņem 6–12 nedēļas, pareizi izdarīta. Komandas, kas mēģina saspiest, ražo mail zudumu; komandas, kas izlaiž posmus pavisam, ražo mail zudumu bez diagnostiskā redzamības.

Alignment: smalkā daļa

DMARC prasa, lai vai nu SPF, vai DKIM ne tikai izturētu, bet arī izlīdzinātos ar From-adreses domēnu. Alignment ir divi režīmi:

• Relaxed (adkim=r, aspf=r): autentificētais domēns dalās organizācijas domēnā ar From-adresi. Piemērs: From info@mail.company.com, DKIM paraksta ar company.com — relaxed alignment iztur, jo viņi dalās company.com organizācijas domēnā.

• Strict (adkim=s, aspf=s): autentificētajam domēnam precīzi jāatbilst From-adreses domēnam. Piemērs augstāk: From info@mail.company.com, DKIM ar company.com — strict alignment neizdodas, jo tie precīzi neatbilst.

Relaxed ir noklusējums un strādā lielākajai daļai setup. Strict tiek izmantots augstas drošības konfigurācijās, kur jebkura subdomain variācija jāneiztur autentifikāciju.

Alignment problēma, ar kuru lielākā daļa komandu sastopas: sūtīšanas servisi, kas paraksta DKIM ar savu domēnu (piem., generic SendGrid signing domēns), nevis jūsu. Tas ražo DKIM pass + DKIM nav-izlīdzināts, ko DMARC izturas kā autentifikācijas neveiksmi. Risinājums ir konfigurēt sūtīšanas servisu parakstīt ar jūsu domēnu (dažreiz saukts “custom DKIM” vai “branded sending”).

Tipiskas DMARC policy kļūdas

Sākums pie p=reject bez monitoringa. Visbojātākā DMARC kļūda. Bez monitoringa fāzes jūs nezināt, kuri leģitīmie avoti neiztur autentifikāciju. p=reject noved pie tūlītēja bounce šiem leģitīmiem avotiem. Produkcijas komandas nekad nesāk pie reject.

rua adreses izlaišana. DMARC ieraksts bez rua neražo atskaites. Bez atskaitēm jums nav feedback par autentifikācijas stāvokli. Vienmēr iekļaujiet rua, norādot uz adresi, ko varat monitorēt.

DMARC atskaišu ignorēšana nedēļām. Atskaites pienāk, bet neviens nelasa. Līdz tam laikam, kad kāds saprot, ka ir autentifikācijas problēma, vairākas nedēļas kampaņu ir notikušas ar neveiksmēm. Produkcijas komandas pārskata DMARC atskaites iknedēļas migrācijas laikā, ikmēneša steady-state.

Quarantine bez ramp. Pāreja no p=none uz p=quarantine; pct=100 vienā solī izlaiž ramp, kas noķer edge gadījumus. pct mehānisms eksistē tieši, lai ļautu rampēt droši.

Subdomain aizmiršana. DMARC ieraksts uz company.com neattiecas uz mail.company.com pēc noklusējuma. sp= parametrs iestata policy subdomain. Komandas, kas publicē DMARC apex domēnā, bet neuzstāda sp, beidzas ar subdomain mail apejot policy.

Neizlīdzinot DKIM ar From-domēnu. Kad sūtīšanas servisi paraksta ar savu domēnu, DKIM iztur, bet nav izlīdzināts — un DMARC izturas kā neveiksmi. Vienmēr verificējiet alignment, ne tikai pass statusu, DMARC atskaitēs.

Izturēšanās pret DMARC kā tikai drošības funkciju. DMARC ir drošības priekšrocības (anti-spoofing) un piegādes priekšrocības (saņemošās sistēmas vairāk uzticas mail no DMARC-publicētiem domēniem). Lielākā daļa B2B komandu pieņem to piegādei; drošības priekšrocība ir blakusparādība.

DMARC policy izvēle 2026 ir staging-disciplīnas jautājums, ne stingrākā-izvēles-disciplīnas jautājums. Komandas, kas iegūst labus piegādes iznākumus, izmanto p=quarantine pēc rūpīgas migrācijas. Komandas, kas iegūst piegādes katastrofas, lec tieši uz p=reject bez monitoringa un skatās, kā leģitīms mail bouncē nedēļām, pirms saprot, kāpēc. Pilnīgam piegādes kontekstam skatiet e-pasta piegādes ceļvedi.