SPF и DKIM за Google Workspace: еден пропуштен испраќач ја расипува проверката

За да поставите SPF и DKIM во Google Workspace без да ја загрозите деловната пошта, прво попишете ги сите системи што испраќаат од вашиот домен. Потоа составете еден SPF TXT-запис што ги опфаќа, објавете го јавниот DKIM-клуч во DNS и дури тогаш вклучете го потпишувањето во Admin console. Испратете пробна порака од секој систем и прочитајте ги резултатите во Authentication-Results пред да поставите DMARC.

Ако, на пример, веб-формуларот испраќа преку сопствен сервер што не е наведен во SPF, неговите пораки нема да добијат SPF pass само затоа што пораките од Google Workspace поминуваат. DKIM поставен во Google Workspace се однесува на поштата што ја потпишува Google; посебен испраќач може да бара сопствено поставување за вашиот домен. Затоа успешна проба од корисничко сандаче не ја проверува и поштата од CRM или билтен.

Пописот почнува од пораките што навистина излегуваат

Запишете ги корисничките сандачиња, CRM, платформата за билтени, веб-формуларите, фактурирањето и автоматските известувања. За секој канал утврдете кој сервис ја предава пораката, која адреса стои во From и дали пораката минува низ дополнителен излезен сервер. Веб-формуларот, на пример, може да користи Google SMTP, сервер на хостинг-компанијата или посебна услуга; името на формуларот само по себе не го открива испраќачот.

Од секој давател побарајте ја тековната SPF-инструкција: домен за include или конкретна IP-адреса, според начинот на кој навистина испраќа. Забележете и дали нуди DKIM-потпишување со вашиот домен и кои DNS-записи ги бара. Тоа е важна разлика: додавањето сервис во SPF не му го вклучува автоматски DKIM, а Google не потпишува порака што не ја испраќа преку неговиот систем.

Пред да измените нешто, прочитајте ги постојните TXT-записи кај давателот што управува со DNS. Ако веќе има SPF-запис, зачувајте ја неговата содржина и проверете кои испраќачи сè уште се користат. Стариот запис може да содржи легитимен систем што не се гледа во секојдневната кореспонденција, на пример автоматско известување што се испраќа ретко.

Еден SPF-запис ги собира сите овластени испраќачи

Насоките на Google за SPF бараат еден запис за доменот, со сите активни испраќачи во него; кога испраќа само Google Workspace, примерот е v=spf1 include:_spf.google.com ~all. Ако користите и друга услуга, тој пример е нецелосен: нејзиниот механизам треба да стои во истиот запис пред ~all. Два одделни SPF-записи не се начин да се поделат услугите и можат да предизвикаат проблеми со доставувањето.

Изменете го постојниот TXT-запис или создајте го ако нема таков, според правилата на вашиот DNS-давател. За основниот домен полето за име често е @; интерфејсот на давателот одредува како точно се внесува. SPF се поставува во DNS, не во Admin console. Пред зачувување проверете дали не сте избришале активен испраќач и дали механизмите се напишани точно како што ги бараат нивните даватели.

Завршното ~all означува soft fail за сервер што не е опфатен; примачот може да ја прифати пораката и да ја смета за сомнителна. Построгото -all може да доведе до одбивање легитимна порака ако пописот е нецелосен. Кај повеќе надворешни услуги проверете го и бројот на DNS-пребарувања: SPF има граница од 10, а вгнездените include-механизми исто така влегуваат во пресметката. Додавањето секоја стара интеграција „за секој случај“ може да го расипе записот.

DKIM бара јавен клуч во DNS пред активирање

Во Admin console отворете Apps → Google Workspace → Gmail → Authenticate email, изберете го доменот и генерирајте нов запис. Упатството на Google за DKIM препорачува 2048-битен клуч кога DNS-давателот го поддржува и дозволува 1024-битен ако не го поддржува; по првичното вклучување на Gmail може да поминат 24–72 часа пред конзолата да дозволи генерирање клуч.

Конзолата прикажува име за TXT-записот и вредност што го содржи јавниот клуч. Пренесете ги во DNS точно, со селекторот што сте го избрале. Стандардниот селектор е google; ако таму веќе има клуч за истиот домен, употребете друг селектор наместо да го замените постојниот запис. Ако DNS-давателот има ограничување за долги TXT-вредности, следете го неговиот начин на внесување без да ги менувате знаците на клучот.

Проверете дали новиот DNS-запис е видлив, па вратете се во Authenticate email и изберете Start authentication. Самото генерирање клуч не ги потпишува пораките; потпишувањето почнува по активирањето и може да потрае додека DNS-промената се прошири. Ако поштата од Google минува низ излезен посредник што додава подножје или менува содржина, проверете ја и таа патека, бидејќи промена по потпишувањето може да го наруши DKIM-резултатот.

Пробајте го секој канал и прочитајте го резултатот

Испратете одделни пораки од корисничко сандаче, CRM, билтен и веб-формулар до надворешно сандаче. За пробата на Google DKIM користете друг примач, наместо да си испратите порака самите на себе. Во Gmail на страната на примачот отворете Show original и побарајте Authentication-Results во целосното заглавие. Запишете ги резултатите за секој канал одделно.

Гледајте ги вредностите по spf= и dkim=, но и домените на кои се однесуваат. spf=pass покажува дека испраќачкиот сервер е овластен за проверениот SPF-домен; dkim=pass покажува дека потписот за наведениот домен е валиден. Ако веб-формуларот добие spf=softfail или spf=fail, проверете кој сервер навистина ја испратил пораката и споредете го со единствениот SPF-запис. Ако DKIM не поминува, проверете го објавениот клуч и дали посредник ја менува пораката.

За DMARC е важен и доменот во видливото поле From. Според насоките на Google за DMARC, барем SPF или DKIM мора да помине со домен усогласен со From, а SPF и DKIM треба да бидат вклучени најмалку 48 часа пред DMARC. Затоа spf=pass од доменот на CRM не е доволен ако тој домен не е усогласен со вашиот From; усогласен DKIM-потпис на вашиот домен може да ја обезбеди потребната проверка.

Кога некој канал не поминува, поправката е специфична за него: кај SPF утврдете го вистинскиот сервер и ажурирајте го постојниот запис, а кај DKIM побарајте го поставувањето на давателот што ја потпишува таа пошта. Потоа испратете нова порака токму преку поправениот канал.

Прочитајте и:

• AI-агент пред испраќање е-пошта: паузата мора да ја зачува состојбата
• Разговорот со AI-лик не е дневник: што да проверите пред да се доверите
• AI создава „невидлива работа“: човечката проверка станува нов товар