Cum repari Gmail 550 5.7.26 pe DirectAdmin și VPS: runbook DMARC-safe pentru 2026

Dacă Gmail îți respinge mesajul cu 550 5.7.26, semnificația practică este simplă: Gmail nu a putut autentifica suficient de bine emailul tău pentru modul în care este configurat domeniul. În cazul comun, atât SPF, cât și DKIM au eșuat. În cazul mai strict DMARC, una sau ambele tehnologii pot exista, dar niciuna nu este aliniată cu domeniul din headerul vizibil From:. De aceea cele două texte de bounce cele mai întâlnite sunt fie This email has been blocked because the sender is unauthenticated, fie Unauthenticated email from example.com is not accepted due to domain's DMARC policy. Acestea nu sunt erori Gmail aleatorii. Sunt eșecuri de autentificare cu cauze foarte specifice.

Din experiența noastră administrând stack-uri de mail pe DirectAdmin și sisteme VPS autogestionate care trimit email, administratorii pierd cel mai mult timp cu 5.7.26 atunci când tratează problema ca pe un incident generic de livrare. Nu este. De obicei este una dintre acestea:

• IP-ul de trimitere nu este autorizat în SPF.
• Mesajul nu este semnat DKIM sau cheia publică DKIM din DNS lipsește ori este greșită.
• Mesajul trece SPF sau DKIM pentru un domeniu, dar headerul tău vizibil From: folosește alt domeniu, astfel încât alinierea DMARC eșuează.
• Un formular web, un script PHP, un cron job sau o aplicație trimite ca și cum ar fi alt domeniu.
• Pe DirectAdmin, DNS-ul extern sau rutarea IP-ului outbound nu se potrivesc cu ce face Exim în realitate.

Acest runbook este exact pentru asta. Nu este un eseu larg despre deliverability. Nu este o prezentare teoretică a DNS-ului. Este o cale practică de remediere pentru hosting DirectAdmin și trimitere de email de pe VPS, cu verificări DNS, verificări Exim și greșelile frecvente din WordPress și aplicații explicate pas cu pas.

Ce înseamnă de fapt Gmail 550 5.7.26

Documentația actuală Google despre trimitere se reduce la asta: toți expeditorii către Gmail ar trebui să se autentifice cu SPF sau DKIM, iar DMARC trece doar dacă domeniul care autentifică se potrivește cu domeniul din headerul vizibil From:. Apoi referința Google pentru erori SMTP mapează codurile reale de bounce la tipul de eșec. 550 5.7.26 este codul pe care îl vezi când expeditorul este neautentificat, când SPF dă hard fail sau când mesajul este respins din cauza politicii DMARC a domeniului expeditor. Distincția aceasta contează, pentru că „am SPF” și „trec DMARC” nu sunt același lucru.

Cea mai scurtă explicație corectă este aceasta:

• SPF întreabă dacă acest IP de server are voie să trimită pentru acest domeniu.
• DKIM întreabă dacă mesajul a fost semnat și dacă semnătura se validează față de DNS.
• DMARC întreabă dacă SPF sau DKIM a trecut pentru același domeniu pe care utilizatorul îl vede în headerul From:.

Ultimul punct este cel care rupe setup-urile făcute de neexperți. Un mesaj poate părea „destul de autentificat” într-un test superficial și totuși să fie respins de Gmail pentru că domeniul aliniat este greșit.

Citește bounce-ul înainte să atingi DNS-ul

Nu începe prin a schimba înregistrări la întâmplare. Începe prin a citi exact respingerea pe care a returnat-o Gmail. Pe DirectAdmin și pe majoritatea stack-urilor de mail de pe VPS care folosesc Exim, dovada este de obicei în /var/log/exim/mainlog.

grep -i "5.7.26" /var/log/exim/mainlog
grep -i "sender is unauthenticated" /var/log/exim/mainlog
grep -i "DMARC policy" /var/log/exim/mainlog

Cauți linii de genul:

550-5.7.26 This email has been blocked because the sender is unauthenticated.
550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.
550-5.7.26 Authentication results:
550-5.7.26 DKIM = did not pass
550-5.7.26 SPF example.com with ip: 203.0.113.10 = did not pass

550-5.7.26 Unauthenticated email from example.com is not accepted due to domain's DMARC policy.

Dacă bounce-ul arată că atât SPF, cât și DKIM au eșuat, începe cu DNS-ul și semnarea. Dacă spune explicit că emailul este respins din cauza politicii DMARC a domeniului, concentrează-te mai întâi pe aliniere. Asta înseamnă frecvent că mesajul este trimis cu domeniul greșit în headerul vizibil From: sau cu un envelope sender greșit.

Pasul 1: identifică traseul real de trimitere

Acesta este pasul pe care oamenii îl sar, și de aceea continuă să repare lucrul greșit. Întreabă-te ce sistem originază cu adevărat mesajul.

• O căsuță de email DirectAdmin care trimite prin SMTP AUTH
• Un website de pe shared hosting care folosește PHP mail sau sendmail local
• Un plugin WordPress care folosește SMTP
• O aplicație de pe un VPS care trimite direct prin Exim sau alt MTA
• Un cron job, un script de backup sau un sistem de monitorizare care trimite alerte
• Un expeditor third-party care folosește domeniul tău în From:

Documentația Google pentru SPF spune explicit că înregistrarea SPF trebuie să includă toate sistemele care trimit email pentru domeniul tău, inclusiv servere web, servere on-prem, gateway-uri outbound, formulare de contact și servicii third-party. Dacă nu identifici mai întâi expeditorul real, vei continua să editezi înregistrări care nu se potrivesc cu realitatea.

Pasul 2: verifică SPF față de IP-ul real de trimitere

SPF nu înseamnă „domeniul are un TXT record”. SPF înseamnă „domeniul autorizează exact acest traseu de trimitere”.

dig +short TXT example.com
dig +short MX example.com
dig +short A mail.example.com

Dacă domeniul trimite direct de pe server, SPF-ul tău trebuie să autorizeze acel IP de server sau un hostname care se rezolvă către el. Pe setup-uri simple DirectAdmin, un record minim poate arăta așa:

v=spf1 a mx ip4:203.0.113.10 -all

Dar nu copia asta orbește. Dacă domeniul mai trimite și din Microsoft 365, Mailgun, Brevo, un CRM sau o platformă de marketing, toți acei expeditori trebuie reprezentați și ei. Așa se bagă echipele singure în probleme SPF. Adaugă un expeditor, uită website-ul sau relay-ul, iar Gmail vede emailul venind de pe un IP pe care domeniul nu l-a autorizat niciodată.

Dacă ai nevoie să cureți și problema cu lookup-urile excesive în același timp, ServerSpan are deja un runbook conex despre limitele SPF lookup, iar pagina de tools ServerSpan este un loc practic în care poți valida și reconstrui textul de bază pentru SPF și DMARC fără să ghicești.

Pasul 3: verifică semnarea DKIM și publicarea în DNS

Documentația DirectAdmin este directă pe punctul acesta: fiecare domeniu ar trebui să aibă SPF, DKIM și DMARC, iar dacă folosești DNS extern, recordul DKIM TXT trebuie copiat acolo. În caz contrar, emailul outbound poate fi semnat local, dar verificarea eșuează la destinație pentru că serverele remote nu pot prelua cheia publică corectă. DirectAdmin avertizează explicit că asta este mai rău decât să nu ai DKIM deloc.

Pe DirectAdmin, verificările practice sunt:

• Este DKIM activat pentru domeniu în panou?
• Dacă domeniul folosește DNS extern, a fost copiat recordul DKIM TXT acolo?
• Serverul chiar semnează emailurile outbound pentru acel domeniu?
• Selectorul din mesaj se potrivește cu selectorul publicat în DNS?

Pe server, DirectAdmin documentează atât activarea DKIM din panou, cât și o metodă din consolă:

cd /usr/local/directadmin/scripts
./dkim_create.sh example.com nodns force

Apoi interoghează cheia publicată folosind selectorul real al domeniului:

dig +short TXT selector._domainkey.example.com

Dacă serverul semnează emailul outbound, dar DNS-ul nu are cheia DKIM potrivită, Gmail va raporta DKIM ca failed, iar 5.7.26 devine foarte probabil.

Pasul 4: repară DMARC în siguranță, nu teatral

Documentația Google despre DMARC este clară în privința ordinii de rollout: configurezi mai întâi SPF și DKIM, le lași să autentifice email timp de cel puțin 48 de ore și abia apoi activezi enforcement-ul DMARC. Dacă publici p=reject înainte ca traseele reale de trimitere să fie aliniate, îți creezi singur outage-ul.

Un record DMARC sigur pentru început arată așa:

v=DMARC1; p=none; rua=mailto:dmarc@example.com; pct=100

Asta nu este o politică pentru totdeauna. Este o fază de validare. Odată ce SPF sau DKIM trece și este aliniat, poți merge către quarantine sau reject. Dacă domeniul este deja pe p=reject și emailul legitim ricoșează, mișcarea de urgență DMARC-safe este să relaxezi temporar politica în timp ce repari SPF și DKIM. Apoi o întărești din nou. Nu lăsa un domeniu stricat pe none la nesfârșit și nu te preface că treaba este încheiată.

Mai notează un lucru despre regula de aliniere Google. DMARC trece atunci când SPF sau DKIM trece pentru același domeniu care apare în headerul vizibil From:. Asta este partea pe care mulți administratori o ratează. „Există o semnătură DKIM” nu este suficient. Trebuie să fie și aliniată.

Pasul 5: nu mai trimite formularele de contact ca și cum ar veni de la vizitator

Aceasta este una dintre cele mai frecvente cauze 5.7.26 pe shared hosting, DirectAdmin și website-uri mici de pe VPS.

Un plugin de contact preia ce a scris vizitatorul în câmpul de email și îl folosește ca adresă vizibilă From:. Pare intuitiv. Este și greșit. Dacă un vizitator introduce someone@gmail.com iar website-ul tău trimite mesajul de pe propriul server ca și cum ar veni de la someone@gmail.com, Gmail îl va respinge pentru că serverul tău nu este autorizat să trimită pentru gmail.com. DMARC face exact ce trebuie să facă.

Modelul corect este:

• From: o căsuță de email de pe propriul tău domeniu, de exemplu forms@example.com
• Reply-To: adresa reală de email a vizitatorului

Schimbarea aceasta singură rezolvă un procent uriaș din tichetele de tipul „website-ul meu nu mai poate trimite către Gmail”.

Pasul 6: repară problemele de aliniere dintre DirectAdmin și Exim

DirectAdmin a introdus validare mai strictă pentru expeditor în Exim în versiunile recente. Din 1.680, Exim poate bloca încercările utilizatorilor de a face spoofing la adresa expeditorului prin compararea utilizatorului autentificat SMTP cu adresa envelope sender din MAIL FROM. Este o schimbare bună, pentru că previne una dintre cauzele clasice de confuzie DMARC și DKIM: utilizatori autentificați care trimit ca și cum ar aparține unor domenii sau adrese pe care nu ar trebui să le folosească.

Operațional, asta înseamnă că nu ar trebui să construiești fluxuri de email care se autentifică drept o căsuță poștală, dar trimit cu alt domeniu expeditor fără legătură, doar pentru că „mergea înainte”. Chiar și când Gmail nu îl respinge direct, tu creezi datorie de aliniere.

Dacă rescrii intenționat expeditori sau gestionezi mail originat din aplicații în moduri personalizate, revizuiește comportamentul Exim și configurația aplicației împreună. Articolul conex ServerSpan despre rescrierea adreselor în Exim și problemele TLS de client este relevant aici, pentru că rescrierea expeditorului poate fie să repare, fie să distrugă alinierea, în funcție de cum este făcută.

Pasul 7: dacă domeniul trimite de pe un IP dedicat, fă Exim și DNS-ul să fie de acord

DirectAdmin documentează și un mod foarte specific de eșec pentru sisteme multi-domeniu care folosesc IP-uri dedicate: Exim poate avea nevoie să trimită folosind IP-ul dedicat al domeniului și datele HELO aferente, nu IP-ul implicit al serverului. Dacă SPF-ul tău autorizează IP-ul dedicat, dar Exim trimite în continuare de pe IP-ul principal al serverului, Gmail vede o nepotrivire și SPF eșuează.

da config-get add_domain_to_domainips

da config-set add_domain_to_domainips 1
systemctl restart directadmin

da taskq --run="action=rewrite&value=domainips"
da taskq --run="action=rewrite&value=helo_data"

Documentația DirectAdmin arată fișierele relevante ca fiind:

/etc/virtual/domainips
/etc/virtual/helo_data

Și reverse DNS-ul forward-confirmed trebuie să fie aliniat și el. Dacă domeniul de mail trimite de pe mail.example.com, recordul A, PTR-ul și identitatea HELO a Exim nu ar trebui să indice în direcții complet diferite. Asta nu este doar o problemă de reputație. Devine foarte des următorul blocaj imediat după ce repari 5.7.26.

Pasul 8: pe un VPS, repară traseul aplicației, nu doar DNS-ul

Pe sisteme VPS autogestionate, 5.7.26 nu este adesea deloc o problemă DirectAdmin. Este o problemă a aplicației.

• Aplicația trimite ca notifications@example.com, dar IP-ul serverului nu este în SPF.
• Aplicația trimite local, dar nu este configurat niciun semnatar DKIM.
• Aplicația folosește un header vizibil From: pe un domeniu și un envelope sender pe altul.
• Aplicația folosește PHP mail() sau o cale locală sendmail fără disciplină reală de SMTP autentificat.

Dacă acesta este un VPS și volumul de email contează, cea mai curată remediere este adesea să faci aplicația să trimită prin SMTP autentificat folosind căsuța reală a domeniului sau traseul de relay care are deja acoperire corectă SPF și DKIM. Asta este mult mai sigur decât să lași fiecare aplicație să improvizeze comportamentul expeditorului.

Fii sincer aici. Dacă VPS-ul tău joacă rol de web server, app server, cron sender și mail sender fără o responsabilitate clară pentru DNS, politică de MTA și setările de sender ale aplicației, nu ai un setup de mail. Ai o grămadă de valori implicite care au mers din întâmplare până când Gmail a început să le aplice mai strict.

Secvența scurtă de validare care chiar funcționează

1. Citește bounce-ul real Gmail din /var/log/exim/mainlog.
2. Identifică traseul real de trimitere: căsuță poștală, website, aplicație, cron, relay sau expeditor third-party.
3. Verifică SPF față de IP-ul exact de trimitere.
4. Verifică faptul că DKIM este activ și cheia publică există în DNS-ul live.
5. Verifică DMARC și confirmă că SPF sau DKIM se aliniază cu domeniul vizibil din From:.
6. Dacă este un formular de website, nu mai folosi adresa vizitatorului în From:. Folosește Reply-To în schimb.
7. Dacă este DirectAdmin pe IP-uri dedicate, verifică domainips, helo_data și alinierea PTR.
8. Testează din nou cu o căsuță reală Gmail și inspectează header-ele mesajului primit sau rezultatul bounce-ului.

Dacă vrei o verificare rapidă a realității înainte să retestezi emailul de producție, toolbox-ul ServerSpan este locul potrivit pentru un sanity check al recordurilor de autentificare, iar DirectAdmin însuși recomandă testarea calității emailului outbound după publicarea SPF, DKIM și DMARC.

Ce merge de obicei prost în timpul remedierii

• Repari SPF, dar ignori DKIM. Gmail poate înceta să afișeze o variantă a erorii 5.7.26 și să o expună imediat pe următoarea.
• Publici DKIM local, dar uiți DNS-ul extern. DirectAdmin avertizează explicit despre asta.
• Ai un record DMARC pe reject înainte ca SPF și DKIM să fie stabile.
• Te autentifici ca o căsuță poștală și trimiți ca alt domeniu.
• Website-ul tău trimite formulare de contact ca și cum ar veni de la adresa vizitatorului.
• SPF-ul domeniului autorizează un IP, dar Exim trimite de pe altul.

Un insight de producție aici: cele mai lungi tichete 5.7.26 nu sunt cele cu cea mai mare adâncime tehnică. Sunt cele în care există mai multe trasee de trimitere și nimeni nu le-a documentat. O aplicație web folosește Exim local. O căsuță poștală folosește SMTP AUTH. Un CRM folosește un relay third-party. Un sistem de backup trimite direct de pe VPS. Apoi toată lumea se ceartă despre „recordul SPF” ca și cum ar exista un singur expeditor.

Când trebuie să te oprești din patchuit și să repari corect stratul de mail

Dacă este vorba de un singur site găzduit cu o singură căsuță de email, de obicei îl poți curăța singur. Dacă este un portofoliu de shared hosting, un mediu reseller sau un stack VPS cu mai multe aplicații, trasee de trimitere și domenii de clienți, problema reală nu mai este doar un singur bounce Gmail. Problema reală este că politica outbound de email este administrată ad hoc.

Pentru echipele aflate pe hosting administrat din panou, web hostingul ServerSpan îți oferă o cale bazată pe DirectAdmin cu un strat de mail mai controlat decât trimiterea improvizată de pe website. Pentru stack-uri și aplicații personalizate care au nevoie de ownership real asupra expeditorului, control pe IP și disciplină de MTA, un server virtual este locul potrivit pentru a face treaba corect în loc să te lupți cu presupuneri de shared hosting.

Iar dacă problema ta reală nu este doar Gmail, ci curățarea repetată a întregului stack de mail, este aproape întotdeauna mai ieftin să repari politica o singură dată decât să continui să pierzi timp stingând bounce după bounce.