Rifiuti Gmail 550‑5.7.26 e UsernameCaseMapped: cause, diagnosi e soluzioni
Di CaptainDNS
Pubblicato il 26 febbraio 2026
- Gmail restituisce 550 5.7.26 quando SPF, DKIM o l'allineamento DMARC falliscono: è un rifiuto permanente, il server non ritenterà
- L'errore UsernameCaseMapped deriva dalla normalizzazione PRECIS (RFC 8265): la local-part dell'indirizzo From deve essere in minuscolo
- Da febbraio 2024, Google richiede SPF + DKIM + DMARC per i mittenti di massa (>5 000 email/giorno) e SPF o DKIM per tutti gli altri
- Correggi normalizzando i tuoi indirizzi in lowercase, verificando SPF/DKIM/DMARC e controllando l'allineamento del dominio From:
Le tue email verso Gmail tornano indietro con un codice 550. Nessuna cartella spam, nessun ritardo: un rifiuto netto e definitivo. Il server chiude la connessione e non ritenterà. È quello che riscontrano sempre più team di deliverability dall'inizio del 2026, con due motivi di rifiuto in aumento: 550 5.7.26 (mittente non autenticato) e UsernameCaseMapped (capitalizzazione dell'indirizzo non valida).
Questi due errori hanno un punto in comune: derivano dal rafforzamento continuo delle policy anti-spoofing di Google. Ciò che funzionava un anno fa ora viene bloccato. Questa guida copre le cause tecniche di ogni errore, la diagnosi precisa tramite i log SMTP e le correzioni da applicare alla tua infrastruttura di invio.
Comprendere l'errore 550 5.7.26 di Gmail
Il codice 550 5.7.26 è un rifiuto permanente (classe 5xx) che significa che Gmail non ha potuto validare l'autenticità del tuo messaggio. A differenza di un codice 4xx (temporaneo), il server mittente non deve ritentare: l'email è definitivamente rifiutata.
Le tre varianti del codice 550 5.7.26
Google restituisce tre messaggi diversi sotto lo stesso codice, ciascuno corrispondente a una causa distinta:
Variante 1, mittente non autenticato:
550-5.7.26 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 [captaindns.com] with ip: [203.0.113.42] = did not pass.
Né SPF né DKIM hanno superato la verifica. È la variante più frequente.
Variante 2, SPF hard fail:
550-5.7.26 The MAIL FROM domain [captaindns.com] has an SPF record
with a hard fail policy (-all) but it fails to pass SPF checks
with the ip: [203.0.113.42].
Il tuo record SPF termina con -all (rifiuto rigido), ma l'IP che invia non è autorizzato. Gmail applica la tua stessa policy alla lettera.
Variante 3, policy DMARC:
550-5.7.26 Unauthenticated email from captaindns.com is not accepted
due to domain's DMARC policy. Contact the administrator of
captaindns.com domain if this was legitimate email.
SPF o DKIM può aver superato la verifica, ma l'allineamento DMARC fallisce: il dominio From: non corrisponde al dominio autenticato da SPF o DKIM.
Differenza tra 550 5.7.26 e 421 4.7.26
| Codice | Classe | Comportamento | Azione richiesta |
|---|---|---|---|
| 421 4.7.26 | Temporaneo | Il server mittente ritenta più tardi | Verificare, ma l'email potrebbe passare |
| 550 5.7.26 | Permanente | L'email è definitivamente rifiutata | Correggere la configurazione prima di reinviare |
Un 421 è un avvertimento con rate limiting. Un 550 è un muro. Se vedi dei 550, il problema è strutturale e non si risolverà ritentando.
Perché questi rifiuti aumentano adesso?
Dal 1° febbraio 2024, Google ha inasprito le sue linee guida per i mittenti:
| Requisito | Tutti i mittenti | Bulk sender (>5 000/giorno) |
|---|---|---|
| SPF o DKIM | Obbligatorio | Obbligatorio |
| SPF e DKIM | Consigliato | Obbligatorio |
| DMARC | Consigliato | Obbligatorio (p=none minimo) |
| Allineamento From: | Consigliato | Obbligatorio |
| TLS (STARTTLS) | Obbligatorio | Obbligatorio |
| Tasso di spam <0,3 % | Obbligatorio | Obbligatorio |
Cosa è cambiato concretamente: prima, un'email senza autenticazione finiva nello spam. Oggi, Gmail la rifiuta con un 550. È una differenza sostanziale.
Comprendere l'errore UsernameCaseMapped
L'errore UsernameCaseMapped è meno documentato ma altrettanto bloccante. Provoca un rifiuto permanente 550 legato alla capitalizzazione dell'indirizzo mittente.
Cos'è il profilo UsernameCaseMapped?
Il termine viene dalla RFC 8265 (PRECIS, Preparation, Enforcement, and Comparison of Internationalized Strings). Questa RFC definisce come i server devono normalizzare gli identificativi utente prima di confrontarli.
Il profilo UsernameCaseMapped impone due operazioni:
- Normalizzazione Unicode (NFKC): i caratteri vengono ridotti alla loro forma canonica
- Case folding: le maiuscole vengono convertite in minuscole
Concretamente, quando Gmail riceve un'email, normalizza la local-part (la parte prima della @) dell'indirizzo From: applicando questo profilo. Se il risultato non corrisponde all'indirizzo atteso, il messaggio viene rifiutato.
Come si verifica questo errore?
Lo scenario tipico:
- Il tuo CRM o script invia un'email con
From: Marketing@captaindns.com - Gmail normalizza la local-part:
marketing@captaindns.com - Il confronto fallisce se il server si aspetta esattamente
Marketing@captaindns.como se l'autenticazione (SPF/DKIM) è stata effettuata con una capitalizzazione diversa - Risultato: rifiuto 550 UsernameCaseMapped
I sistemi che attivano più spesso questo errore:
- CRM e piattaforme marketing che memorizzano l'indirizzo con la capitalizzazione inserita dall'utente
- Alias email e redirect che preservano la capitalizzazione originale
- Script legacy che costruiscono l'indirizzo From senza normalizzazione
- Form web che riprendono l'input dell'utente così com'è nel MAIL FROM
RFC 5321 e la capitalizzazione degli indirizzi email
La RFC 5321 (SMTP) stabilisce che la local-part di un indirizzo email è teoricamente case-sensitive: è il server di ricezione che decide se User e user sono la stessa casella. In pratica, la quasi totalità dei server tratta la local-part in minuscolo. Gmail va oltre applicando la normalizzazione PRECIS e rifiutando i messaggi la cui capitalizzazione non corrisponde.
La trappola: la RFC consente la distinzione maiuscole/minuscole, ma le implementazioni moderne la vietano di fatto. Se la tua infrastruttura di invio preserva maiuscole nell'indirizzo From o nel MAIL FROM, rischi un rifiuto.
Diagnosticare questi errori
Leggere i log SMTP
La diagnosi inizia dai log del tuo server di posta o del tuo provider di invio. Cerca le risposte 550:
Feb 12 14:23:01 mail postfix/smtp[12345]: to=<contact@gmail.com>,
relay=gmail-smtp-in.l.google.com[142.250.115.27]:25,
status=bounced (host gmail-smtp-in.l.google.com said:
550-5.7.26 This email has been blocked because the sender is
unauthenticated.)
Punti da verificare nei log:
- Il codice esatto (550 vs 421)
- L'IP di invio menzionato nel messaggio
- I risultati SPF e DKIM citati da Gmail
- Il dominio From: e il dominio MAIL FROM (envelope sender)
Verificare l'autenticazione con gli header
Se hai accesso a un'email che è passata (o a un report DMARC), esamina gli header Authentication-Results:
Authentication-Results: mx.google.com;
dkim=pass header.d=captaindns.com header.s=selector1;
spf=pass (google.com: domain of bounce@captaindns.com
designates 203.0.113.42 as permitted sender)
smtp.mailfrom=bounce@captaindns.com;
dmarc=pass (p=REJECT sp=REJECT) header.from=captaindns.com
Se uno di questi tre risultati è fail, hai trovato l'origine del problema. Usa il verificatore DMARC CaptainDNS per controllare la tua configurazione in pochi secondi.
Utilizzare Google Postmaster Tools
Google Postmaster Tools fornisce metriche sui tuoi invii verso Gmail:
- Tasso di spam segnalato dai destinatari
- Reputazione del tuo dominio e dei tuoi IP di invio
- Volume di rifiuti per codice di errore
Se il tuo tasso di spam supera lo 0,3 %, Gmail inizia ad applicare rate limiting (421) e poi a rifiutare (550).
Correggere l'errore 550 5.7.26
Step 1: configurare SPF correttamente
Il tuo record SPF deve autorizzare tutti gli IP e i servizi che inviano per conto del tuo dominio:
captaindns.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0/24 -all"
Errori frequenti:
- Un provider di invio assente dal SPF (CRM, strumento marketing, servizio transazionale)
- Un
-all(hard fail) quando non tutti i mittenti sono elencati: usa~all(soft fail) nel frattempo per completare la lista - Più di 10 lookup DNS nel record SPF, il che invalida l'intera policy
Verifica con il verificatore SPF CaptainDNS.
Step 2: attivare DKIM su tutti i flussi di invio
Ogni servizio che invia email per il tuo dominio deve firmare con DKIM:
selector1._domainkey.captaindns.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."
Punti critici:
- La chiave deve essere di 1 024 bit minimo (2 048 consigliato da Google)
- Il dominio di firma DKIM (
d=) deve corrispondere al dominio From: per l'allineamento DMARC - Verifica che la chiave pubblica sia accessibile nel DNS:
dig TXT selector1._domainkey.captaindns.com
Step 3: pubblicare una policy DMARC
Se non hai ancora un DMARC, inizia con una policy di monitoraggio:
_dmarc.captaindns.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@captaindns.com; adkim=r; aspf=r"
Progressione consigliata:
| Step | Policy | Durata | Obiettivo |
|---|---|---|---|
| 1 | p=none | 2-4 settimane | Raccogliere i report, identificare i flussi |
| 2 | p=quarantine; pct=25 | 2 settimane | Testare sul 25 % del traffico |
| 3 | p=quarantine; pct=100 | 2 settimane | Quarantena completa |
| 4 | p=reject | Permanente | Rifiuto delle email non autenticate |
Step 4: verificare l'allineamento DMARC
L'allineamento è il pezzo mancante più frequente. Richiede che il dominio From: (header RFC 5322) corrisponda al dominio autenticato da SPF o DKIM:
| Verifica | Dominio confrontato | Allineamento |
|---|---|---|
| SPF | Dominio del MAIL FROM (envelope) | Deve corrispondere al dominio From: |
| DKIM | Dominio d= della firma | Deve corrispondere al dominio From: |
Esempio di fallimento dell'allineamento:
- From:
contact@captaindns.com - MAIL FROM:
bounce@promo.captaindns.com - SPF passa per
promo.captaindns.com, ma DMARC fallisce perché il From: ècaptaindns.com
In modalità relaxed (adkim=r; aspf=r), i sottodomini sono accettati. In modalità strict (adkim=s; aspf=s), il dominio deve essere identico.
Step 5: garantire la crittografia TLS
Gmail richiede una connessione TLS (STARTTLS) per accettare le email. Verifica che il tuo server supporti STARTTLS:
openssl s_client -starttls smtp -connect mail.captaindns.com:25
Se la connessione TLS fallisce, Gmail restituirà un rifiuto. Attiva TLS-RPT per ricevere report giornalieri sui fallimenti di negoziazione TLS.
Correggere l'errore UsernameCaseMapped
Step 1: normalizzare tutti gli indirizzi in minuscolo
La correzione è semplice ma deve essere applicata ovunque. Ogni indirizzo nei tuoi invii deve essere in minuscolo:
| Campo | Prima (rischio di rifiuto) | Dopo (corretto) |
|---|---|---|
| From: (RFC 5322) | Marketing@captaindns.com | marketing@captaindns.com |
| MAIL FROM (envelope) | Bounce@captaindns.com | bounce@captaindns.com |
| Return-Path | Return@captaindns.com | return@captaindns.com |
| Reply-To | Support@captaindns.com | support@captaindns.com |
Step 2: verificare i sistemi di invio
Elenca tutti i sistemi che inviano email per conto del tuo dominio e verifica come costruiscono l'indirizzo From:
| Sistema | Rischio | Verifica |
|---|---|---|
| CRM (HubSpot, Salesforce, Brevo) | Medio: spesso riprende l'input dell'utente | Verificare i parametri dell'indirizzo mittente |
| Strumento marketing (Mailchimp, SendGrid) | Basso: generalmente normalizza | Confermare nei log |
| Applicazione interna / script | Elevato: nessuna normalizzazione di default | Audit del codice sorgente |
| Alias e redirect | Elevato: preserva la capitalizzazione originale | Testare un invio e verificare gli header |
| Form web (contatto, registrazione) | Elevato: riprende l'input così com'è | Aggiungere una normalizzazione a monte |
Step 3: automatizzare la normalizzazione
Aggiungi uno step di normalizzazione sistematica nei tuoi flussi di invio:
Python:
def normalize_email(address: str) -> str:
local, domain = address.rsplit("@", 1)
return f"{local.lower()}@{domain.lower()}"
# Utilizzo
from_address = normalize_email("Marketing@CaptainDNS.com")
# Risultato: marketing@captaindns.com
Node.js:
function normalizeEmail(address) {
const [local, domain] = address.split('@');
return `${local.toLowerCase()}@${domain.toLowerCase()}`;
}
// Utilizzo
const fromAddress = normalizeEmail('Marketing@CaptainDNS.com');
// Risultato: marketing@captaindns.com
Postfix (main.cf):
# Forzare la local-part in minuscolo per il MAIL FROM
lmtp_lowercase_quote_localpart = yes
Piano d'azione consigliato
- Verifica i tuoi flussi di invio: elenca tutti i sistemi che inviano per conto del tuo dominio (CRM, marketing, transazionale, script, form)
- Normalizza in minuscolo: forza tutti gli indirizzi From, MAIL FROM e Return-Path in lowercase in ogni sistema
- Verifica SPF: tutti i mittenti sono autorizzati? Il numero di lookup DNS è <10?
- Verifica DKIM: chiave ≥1 024 bit pubblicata nel DNS, dominio
d=allineato con il From:? - Pubblica una policy DMARC:
p=noneminimo con report RUA attivi per iniziare - Controlla l'allineamento: il dominio From: corrisponde al dominio SPF o DKIM?
- Attiva TLS-RPT: per monitorare i fallimenti di crittografia sulle tue email in entrata
- Monitora Postmaster Tools: verificare quotidianamente il tasso di spam e la reputazione dominio/IP
FAQ
Qual è la differenza tra 550 5.7.26 e 421 4.7.26?
Il codice 421 4.7.26 è un rifiuto temporaneo con rate limiting: Gmail rallenta i tuoi invii ma il server mittente può ritentare più tardi. Il codice 550 5.7.26 è un rifiuto permanente: l'email è definitivamente rifiutata e il server non deve ritentare. Un 421 segnala un problema occasionale o un volume insolito. Un 550 segnala un difetto strutturale di autenticazione che richiede una correzione della configurazione.
Come capire se il mio errore è UsernameCaseMapped o 550 5.7.26?
Il testo del messaggio di errore SMTP fa la distinzione. Un rifiuto 550 5.7.26 menziona esplicitamente "unauthenticated", "SPF" o "DMARC policy". L'errore UsernameCaseMapped appare nel testo della risposta SMTP con il termine "UsernameCaseMapped" e riguarda la capitalizzazione dell'indirizzo, non l'autenticazione del dominio. Consulta i log SMTP del tuo server o del tuo provider per leggere il messaggio completo.
Il mio SPF è configurato, perché ricevo comunque 550 5.7.26?
Tre cause frequenti: (1) l'IP di invio non è elencato nel SPF, verifica che tutti i tuoi provider siano inclusi; (2) il SPF supera i 10 lookup DNS, il che invalida l'intera policy; (3) SPF passa ma l'allineamento DMARC fallisce perché il dominio MAIL FROM non corrisponde al dominio From:. Verifica l'allineamento oltre al SPF.
Serve una policy DMARC p=reject per evitare il rifiuto?
No. Gmail richiede un record DMARC pubblicato per i bulk sender, ma p=none è sufficiente come policy minima. Il rifiuto 550 5.7.26 si verifica quando l'autenticazione fallisce (SPF e DKIM non passano), indipendentemente dalla tua policy DMARC. Tuttavia, la variante "not accepted due to domain's DMARC policy" può attivarsi se la tua stessa policy è p=reject e l'allineamento fallisce.
L'errore UsernameCaseMapped riguarda anche Google Workspace?
Sì. Google Workspace applica le stesse regole di normalizzazione PRECIS di Gmail personale. Se invii email verso indirizzi @latuaazienda.com ospitati su Google Workspace con una capitalizzazione errata nell'indirizzo From, il rifiuto UsernameCaseMapped può verificarsi. La normalizzazione in minuscolo si applica a tutti gli account Google.
Come testare l'allineamento DMARC prima di inviare in produzione?
Pubblica una policy p=none con report RUA attivati (rua=mailto:dmarc@captaindns.com). Invia un'email di test verso un account Gmail ed esamina gli header Authentication-Results. Verifica che compaia dmarc=pass. Se appare dmarc=fail, confronta il dominio From: con i domini SPF e DKIM nei risultati per identificare il difetto di allineamento.
Cosa significa 'Unauthenticated email not accepted due to domain's DMARC policy'?
Questo messaggio indica che il tuo dominio ha pubblicato una policy DMARC restrittiva (p=quarantine o p=reject) e che l'email non ha superato né la verifica SPF allineata né la verifica DKIM allineata. Gmail applica la tua stessa policy: dato che hai richiesto il rifiuto delle email non autenticate, Gmail rifiuta. Verifica l'allineamento SPF e DKIM con il dominio From:.
I rifiuti 550 5.7.26 influenzano la mia reputazione di mittente?
Sì, indirettamente. Rifiuti permanenti ripetuti segnalano a Gmail che la tua infrastruttura di invio non è configurata correttamente. Questo può degradare la reputazione dei tuoi IP e del tuo dominio in Google Postmaster Tools, il che comporta poi rate limiting (421) sui tuoi invii che passano l'autenticazione. Correggi rapidamente per evitare l'effetto valanga.
Glossario
- 550: codice SMTP di rifiuto permanente. Il server mittente non deve ritentare l'invio.
- 5.7.26: enhanced status code (RFC 3463) che indica un fallimento di autenticazione del mittente.
- UsernameCaseMapped: profilo di normalizzazione definito nella RFC 8265 (PRECIS) che impone la conversione in minuscolo della local-part degli identificativi.
- Allineamento DMARC: corrispondenza tra il dominio dell'header From: (RFC 5322) e il dominio autenticato da SPF o DKIM. Richiesto per superare la verifica DMARC.
- Envelope sender: indirizzo MAIL FROM utilizzato nella transazione SMTP (RFC 5321), distinto dall'header From: visibile dal destinatario.
- Bulk sender: mittente che invia più di 5 000 email al giorno verso account Gmail. Soggetto a requisiti rafforzati da febbraio 2024.
