Defaults.Exposed › Remedieri › Guides
Gmail 550 5.7.26 „Expeditorul este neautentificat": Remedierea, în ordinea cerințelor (2026)
Publicat 2026-07-08
Date din 2026-06-29 · metodologie v7. Date agregate din recensământul a 261 milioane de domenii clasificate. Consultați cum clasificăm.
Gmail returnează 550 5.7.26 când mesajul dvs. eșuează verificările de autentificare SPF și DKIM. Reparați-l făcând cel puțin SPF sau DKIM să treacă pentru domeniul dvs. de trimitere — cei mai mulți expeditori lipsesc asta: din cele 12,145,313 domenii care autorizează serverele Google prin _spf.google.com, doar 18.5% aplică DMARC, conform recensământului Defaults.Exposed al 261,086,232 de domenii.
Remedierea este muncă DNS, nu un tichet de suport: confirmați că IP-ul dvs. de trimitere are DNS invers, faceți SPF sau DKIM să treacă pentru domeniul pe care Gmail îl verifică de fapt, apoi faceți DKIM să se alinieze cu adresa dvs. From și publicați o înregistrare DMARC. Mai jos este ordinea completă a cerințelor, plus un tabel decodificator pentru familia 550 5.7.26 și codurile sale surori.
Ce înseamnă eroarea Gmail 550 5.7.26?
De la cerințele expeditorului Google din 2024, fiecare expeditor la Gmail — nu doar expeditorii de masă — trebuie să treacă cel puțin SPF sau DKIM pentru domeniul de trimitere. Eșuați amândouă și Gmail respinge la momentul SMTP cu 550 5.7.26 în loc să livreze în spam.
Versiunea curentă cu text complet citește: “This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. Authentication results: DKIM = did not pass, SPF [domain] with ip: [ip] = did not pass.” Bounce-urile mai vechi în circulație pot purta în continuare formularea anterioară a Google (“This mail is unauthenticated, which poses a security risk…”), iar există și o soră cu limită de rată — 421 4.7.26 This email has been rate limited because it is unauthenticated — cu aceeași cauză.
550 5.7.26 nu este un singur mesaj ci face parte dintr-o familie de coduri, iar formularea vă spune care picior a eșuat: referința curentă Google păstrează trei șiruri 5.7.26 (neautentificat, eșec hard SPF, politică DMARC) și mută eșecurile SPF-only și DKIM-only ale expeditorului de masă la propriile coduri, 5.7.27 și 5.7.30. Citiți textul exact înainte de a atinge DNS-ul — este primul dvs. diagnostic.
Scala decalajului este de ce acest bounce este atât de comun: 12,145,313 domenii autorizează serverele de e-mail Google în înregistrarea SPF (din 138,927,207 domenii la nivel mondial care publică SPF), dar doar 18.5% au o politică DMARC aplicată și doar 8.0% folosesc SPF strict (-all). Cei mai mulți expeditori găzduiți Google nu îndeplinesc regulile proprii de expeditor de masă ale Google — iar Gmail aplică acum bazele tuturor.
Ce variantă de 550 5.7.26 — sau cod soră — aveți?
Potriviți textul bounce-ului primit cu acest tabel. Fragmentele citate urmează referința curentă de eroare SMTP Google — verificați-le întotdeauna față de NDR-ul dvs. actual, deoarece Google revizuiește periodic formularea.
| Cod | Textul bounce-ului spune (fragment) | Ce a eșuat | Unde se află remedierea |
|---|---|---|---|
| 550 5.7.26 (neautentificat) | “This email has been blocked because the sender is unauthenticated … authenticate with either SPF or DKIM” | Nici SPF nici DKIM nu au trecut | Acest ghid, pașii 2–4 |
| 550 5.7.26 (eșec hard SPF) | “has an SPF record with a hard fail policy (-all) but it fails to pass SPF checks” | Înregistrarea dvs. SPF strictă nu autorizează IP-ul de trimitere | Pasul 3 de mai jos + reparați SPF |
| 550 5.7.26 (politică DMARC) | “Unauthenticated email from [domain] is not accepted due to domain’s DMARC policy” | Propria dvs. politică DMARC a respins e-mailul nealiniat | Pasul 4 de mai jos |
| 550 5.7.27 (masă, SPF) | “didn’t pass SPF authentication … Gmail requires bulk email senders to authenticate their email with SPF” | SPF a eșuat și vă aflați în nivelul expeditorului de masă | Pasul 3 de mai jos + reparați SPF |
| 550 5.7.30 (masă, DKIM) | “didn’t pass DKIM authentication … Gmail requires bulk email senders to authenticate their email with DKIM” | Nicio semnătură DKIM validă și vă aflați în nivelul expeditorului de masă | Pasul 3 de mai jos + reparați DKIM |
| 550 5.7.29 (masă, TLS) | “wasn’t sent over a TLS connection” | E-mail de masă trimis fără TLS | Pasul 6 de mai jos |
| 550 5.7.25 | ”doesn’t have a PTR record” | Niciun DNS invers (PTR) pe IP-ul de trimitere | Pasul 2 de mai jos |
| 421-4.7.0 | ”try again later” / trafic neobișnuit | Amânare temporară — reputație sau rată, nu permanentă | Reîncercați; verificați pașii 2–3 și pasul 8 |
| 550 5.7.28 | ”unusual rate of unsolicited email” | Limită de rată de trimitere/spam | Pasul 8 de mai jos |
| 550-5.7.1 | ”message blocked” / text politică | Respingere de politică, spam sau IPv6-fără-PTR | Consultați ghidul Gmail 550-5.7.1 |
Cum remediați 550 5.7.26, în ordinea cerințelor?
Google nu publică nicio „ordine de verificare” literală — dar cerințele se stivuiesc logic, deci parcurgeți-le în această ordine a cerințelor. Cei mai mulți expeditori sunt deblocați după pasul 3; terminați lista oricum, deoarece pașii ulteriori sunt cei care vă țin în afara spam-ului odată ce ieșiți din bounce.
- Rulați scanarea gratuită mai întâi. Citește configurația live SPF, DKIM, DMARC și DNS și arată exact care picior eșuează — diagnosticați înainte de a atinge DNS-ul.
- Dați IP-ului dvs. de trimitere DNS invers (PTR). IP-ul de conectare trebuie să aibă o înregistrare PTR al cărei hostname rezolvă înapoi la același IP. Furnizorii principali gestionează asta pentru dvs.; apare la persoanele care trimit de pe propriile servere (și este întreaga poveste din spatele codului soră 550 5.7.25).
- Faceți SPF sau DKIM să treacă. O gardă mai întâi: receptorii evaluează SPF față de domeniul Return-Path (RFC5321.MailFrom), nu antetul From — verificați la ce domeniu revine de fapt e-mailul dvs. înainte de a decide că SPF „ar trebui” să treacă. Adăugați serviciile dvs. reale de trimitere la înregistrarea SPF a acelui domeniu (ghid complet SPF) sau activați semnarea DKIM la furnizorul dvs. (ghid complet DKIM). Oricare trece elimină blocajul de bază 550 5.7.26.
- Faceți DKIM să se alinieze cu domeniul dvs. From. Pentru trimiterea de masă — și pentru DMARC — Gmail vrea autentificarea pentru domeniul din adresa dvs. From, nu un implicit al vendorului. Utilizatorii Google Workspace: publicați propria cheie DKIM (configurare DKIM Workspace); o semnătură implicită
gappssmtp.comtrece DKIM dar nu se aliniază — o capcană cu propriul ghid. DKIM aliniat supraviețuiește și redirecționării, ceea ce SPF nu face niciodată. - Publicați o înregistrare DMARC. Cerințele expeditorului Google cer cel puțin
p=nonecu o adresă de raportare. Este o editare DNS de cinci minute — consultați „DMARC policy not enabled” pentru primul pas onest și ce protejează și ce nup=none. - Trimiteți peste TLS. Orice server de e-mail sau furnizor modern face asta implicit; dacă rulați propriul MTA, confirmați că TLS de ieșire este activ — e-mailul de masă fără el se respinge acum cu propriul cod, 550 5.7.29.
- Adăugați dezabonarea cu un clic RFC 8058 (antetele
List-Unsubscribe+List-Unsubscribe-Post) pentru e-mailul de marketing și prin abonament. - Păstrați rata de spam sub 0,10% în Google Postmaster Tools — și nu o lăsați să ajungă la 0,30%. Pragul maxim al cerințelor Google este 0,3%; recomandarea este să rămâneți sub 0,10%. Înregistrați domeniul acolo; este propriul raport al Google despre dvs., iar pragul ratei de spam este cerința pe care nicio înregistrare DNS nu o poate remedia.
Un lucru pe care această listă nu îl va face: să vă scoată de pe o listă de blocare terță. Autentificarea oprește respingerile neautentificate ale Gmail; un IP cu un istoric de spam este o problemă de reputație cu propria cale de curățare — repararea auth previne recăderile, nu vă scoate de pe listele de blocare.
Se aplică regulile expeditorului de masă dacă trimiteți mai puțin de 5.000 de e-mailuri pe zi?
Lista de verificare completă — autentificare aliniată, DMARC publicat, dezabonare cu un clic, rata de spam — se aplică formal la 5.000+ mesaje pe zi la Gmail, iar codurile doar-masă (5.7.27, 5.7.29, 5.7.30) vin din acel nivel. Dar bazele autentificării (SPF sau DKIM trecând, PTR valid) sunt aplicate pentru toată lumea, de aceea expeditorii mici primesc și ei 550 5.7.26. Tratați pașii 1–5 ca obligatorii la orice volum, pașii 7–8 ca obligatorii în momentul în care trimiteți în masă. Setul complet de cerințe pentru ambii furnizori se află în articolul nostru de date despre cerințele expeditorului Google și Yahoo.
Întrebări frecvente
550 5.7.26 înseamnă că domeniul sau IP-ul meu este pe lista neagră? Nu. Este un eșec de autentificare, nu o judecată de reputație — Gmail spune „dovedește cine ești”, nu „știm că ești un spammer”. Aceasta este veste bună: este pe deplin remediabil în DNS. Vestea proastă este cât de normal este — în întregul recensământ al 261,086,232 de domenii (din 2026-06-29), doar 10.59% au o politică DMARC aplicată.
Va repara SPF singur bounce-urile? De obicei da, pentru varianta de bază — Gmail cere cel puțin unul dintre SPF sau DKIM. Dar SPF este evaluat față de domeniul Return-Path și se strică la redirecționare, deci DKIM aliniat (pasul 4) este remedierea durabilă. Doar 8.0% din cele 12,145,313 domenii de expeditor găzduite Google folosesc SPF strict (date din 2026-06-29), deci în orice caz veți fi în față față de restul.
Folosesc Google Workspace — de ce Gmail respinge propriul meu e-mail? Deoarece Gmail autentifică domeniul, nu furnizorul de căsuțe poștale. Un domeniu Workspace fără înregistrare SPF și fără cheie DKIM personalizată trimite e-mail pe care Google însuși nu îl poate verifica — din 12,145,313 domenii care autorizează serverele Google, doar 18.5% au DMARC aplicat (date din 2026-06-29). A fi client Google și a îndeplini regulile Google sunt lucruri diferite.
Cât timp după remedierea DNS va accepta Gmail e-mailul meu? De îndată ce noile înregistrări sunt vizibile — de obicei minute până la câteva ore, până la 48 de ore pentru TTL-uri lente. Remedierile auth acționează imediat pe verificarea 550 5.7.26; recuperarea ratei de spam și a reputației (421-4.7.0, 5.7.28) durează zile până la săptămâni de trimitere curată.
Trimiteți proprietarului raportul
Dacă reparați asta pentru un client, nu închideți tichetul cu „bounce-uri rezolvate”. Re-rulați scanarea gratuită după modificările DNS și trimiteți raportul clasificat proprietarului afacerii. Arată, în limbaj simplu, că domeniul lor autentifică acum e-mailul și unde mai cade scurt — dovada de care au nevoie pentru reînnoirile asigurărilor cibernetice și chestionarele de securitate ale furnizorilor. Ați remediat bounce-ul; raportul o dovedește.
Verificați gratuit domeniul
Vedeți pe care picior din SPF, DKIM și DMARC vă eșuează Gmail — privat și numai pentru proprietar.
Verificați domeniul → · Corectați SPF → · Gmail „550-5.7.1 message blocked” → · Cum clasificăm → · Doar date agregate. Date stocate și procesate în UE.