Rejeições Gmail 550‑5.7.26 e UsernameCaseMapped: causas, diagnóstico e soluções
Por CaptainDNS
Publicado em 26 de fevereiro de 2026
- O Gmail retorna 550 5.7.26 quando SPF, DKIM ou o alinhamento DMARC falham: é uma rejeição permanente, o servidor não vai tentar novamente
- O erro UsernameCaseMapped vem da normalização PRECIS (RFC 8265): a local-part do endereço From deve estar em minúsculas
- Desde fevereiro de 2024, o Google exige SPF + DKIM + DMARC para remetentes em massa (>5.000 emails/dia) e SPF ou DKIM para todos os outros
- Corrija normalizando seus endereços em lowercase, verificando SPF/DKIM/DMARC e controlando o alinhamento do domínio From:
Seus emails para o Gmail voltam com um código 550. Sem spam, sem atraso: uma rejeição limpa e definitiva. O servidor encerra a conexão e não vai tentar novamente. É isso que cada vez mais equipes de entregabilidade constatam desde o início de 2026, com dois motivos de rejeição em alta: 550 5.7.26 (remetente não autenticado) e UsernameCaseMapped (caixa do endereço inválida).
Esses dois erros compartilham um ponto em comum: resultam do endurecimento contínuo das políticas anti-spoofing do Google. O que passava há um ano agora é bloqueado. Este guia cobre as causas técnicas de cada erro, o diagnóstico preciso via logs SMTP e as correções a aplicar na sua infraestrutura de envio.
Entendendo o erro 550 5.7.26 do Gmail
O código 550 5.7.26 é uma rejeição permanente (classe 5xx) que significa que o Gmail não conseguiu validar a autenticidade da sua mensagem. Diferente de um código 4xx (temporário), o servidor emissor não deve tentar novamente: o email é definitivamente recusado.
As três variantes do código 550 5.7.26
O Google retorna três mensagens diferentes sob o mesmo código, cada uma correspondendo a uma causa distinta:
Variante 1, remetente não autenticado:
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.
Nem SPF nem DKIM passaram na verificação. É a variante mais 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].
Seu registro SPF termina com -all (rejeição estrita), mas o IP que envia não está autorizado. O Gmail aplica sua própria política ao pé da letra.
Variante 3, política 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 ou DKIM pode ter passado, mas o alinhamento DMARC falha: o domínio From: não corresponde ao domínio autenticado por SPF ou DKIM.
Diferença entre 550 5.7.26 e 421 4.7.26
| Código | Classe | Comportamento | Ação necessária |
|---|---|---|---|
| 421 4.7.26 | Temporário | O servidor emissor tenta novamente depois | Verificar, mas o email pode acabar passando |
| 550 5.7.26 | Permanente | O email é definitivamente rejeitado | Corrigir a configuração antes de reenviar |
Um 421 é um aviso com rate limiting. Um 550 é um muro. Se você está vendo 550, o problema é estrutural e não vai se resolver tentando novamente.
Por que essas rejeições estão aumentando agora?
Desde 1º de fevereiro de 2024, o Google endureceu suas exigências para remetentes:
| Exigência | Todos os remetentes | Remetentes em massa (>5.000/dia) |
|---|---|---|
| SPF ou DKIM | Obrigatório | Obrigatório |
| SPF e DKIM | Recomendado | Obrigatório |
| DMARC | Recomendado | Obrigatório (p=none mínimo) |
| Alinhamento From: | Recomendado | Obrigatório |
| TLS (STARTTLS) | Obrigatório | Obrigatório |
| Taxa de spam <0,3% | Obrigatório | Obrigatório |
O que mudou na prática: antes, um email sem autenticação ia para o spam. Hoje, o Gmail o rejeita com um 550. É uma diferença significativa.
Entendendo o erro UsernameCaseMapped
O erro UsernameCaseMapped é menos documentado, mas igualmente bloqueante. Ele provoca uma rejeição permanente 550 ligada à caixa (maiúsculas/minúsculas) do endereço do remetente.
O que é o perfil UsernameCaseMapped?
O termo vem da RFC 8265 (PRECIS, Preparation, Enforcement, and Comparison of Internationalized Strings). Essa RFC define como os servidores devem normalizar os identificadores de usuário antes de compará-los.
O perfil UsernameCaseMapped impõe duas operações:
- Normalização Unicode (NFKC): os caracteres são reduzidos à sua forma canônica
- Case folding: as maiúsculas são convertidas em minúsculas
Na prática, quando o Gmail recebe um email, ele normaliza a local-part (a parte antes do @) do endereço From: aplicando esse perfil. Se o resultado não corresponder ao endereço esperado, a mensagem é rejeitada.
Como esse erro acontece?
O cenário típico:
- Seu CRM ou script envia um email com
From: Marketing@captaindns.com - O Gmail normaliza a local-part:
marketing@captaindns.com - A comparação falha se o servidor espera exatamente
Marketing@captaindns.comou se a autenticação (SPF/DKIM) foi realizada com uma caixa diferente - Resultado: rejeição 550 UsernameCaseMapped
Os sistemas que mais frequentemente disparam esse erro:
- CRM e plataformas de marketing que armazenam o endereço com a caixa digitada pelo usuário
- Alias de email e redirecionamentos que preservam a caixa original
- Scripts legados que constroem o endereço From sem normalização
- Formulários web que usam a entrada do usuário tal qual no MAIL FROM
RFC 5321 e a caixa dos endereços de email
A RFC 5321 (SMTP) estipula que a local-part de um endereço de email é teoricamente case-sensitive: é o servidor de recepção que decide se User e user são a mesma caixa de correio. Na prática, a quase totalidade dos servidores trata a local-part em minúsculas. O Gmail vai além, aplicando a normalização PRECIS e rejeitando as mensagens cuja caixa não corresponde.
A armadilha: a RFC autoriza a caixa diferenciada, mas as implementações modernas a proíbem na prática. Se sua infraestrutura de envio preserva maiúsculas no endereço From ou no MAIL FROM, você corre risco de rejeição.
Diagnosticando esses erros
Ler os logs SMTP
O diagnóstico começa pelos logs do seu servidor de email ou do seu provedor de envio. Procure as respostas 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.)
Pontos a verificar nos logs:
- O código exato (550 vs 421)
- O IP de envio mencionado na mensagem
- Os resultados SPF e DKIM citados pelo Gmail
- O domínio From: e o domínio MAIL FROM (envelope sender)
Verificar a autenticação com os cabeçalhos
Se você tem acesso a um email que passou (ou a um relatório DMARC), examine os cabeçalhos 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 um desses três resultados for fail, você encontrou a origem do problema. Use o verificador DMARC CaptainDNS para conferir sua configuração em poucos segundos.
Usar o Google Postmaster Tools
O Google Postmaster Tools fornece métricas sobre seus envios para o Gmail:
- Taxa de spam reportada pelos destinatários
- Reputação do seu domínio e dos seus IPs de envio
- Volume de rejeições por código de erro
Se sua taxa de spam ultrapassar 0,3%, o Gmail começa a limitar seus envios (421) e depois a rejeitá-los (550).
Corrigir o erro 550 5.7.26
Etapa 1: configurar o SPF corretamente
Seu registro SPF deve autorizar todos os IPs e serviços que enviam em nome do seu domínio:
captaindns.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0/24 -all"
Erros frequentes:
- Um provedor de envio ausente do SPF (CRM, ferramenta de marketing, serviço transacional)
- Um
-all(hard fail) quando nem todos os remetentes estão listados: use~all(soft fail) enquanto completa a lista - Mais de 10 lookups DNS no registro SPF, o que invalida toda a política
Verifique com o verificador SPF CaptainDNS.
Etapa 2: ativar DKIM em todos os fluxos de envio
Cada serviço que envia emails pelo seu domínio deve assinar com DKIM:
selector1._domainkey.captaindns.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."
Pontos críticos:
- A chave deve ter no mínimo 1.024 bits (2.048 recomendado pelo Google)
- O domínio de assinatura DKIM (
d=) deve corresponder ao domínio From: para o alinhamento DMARC - Verifique se a chave pública está acessível no DNS:
dig TXT selector1._domainkey.captaindns.com
Etapa 3: implantar uma política DMARC
Se você ainda não tem DMARC, comece com uma política de monitoramento:
_dmarc.captaindns.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@captaindns.com; adkim=r; aspf=r"
Progressão recomendada:
| Etapa | Política | Duração | Objetivo |
|---|---|---|---|
| 1 | p=none | 2-4 semanas | Coletar relatórios, identificar os fluxos |
| 2 | p=quarantine; pct=25 | 2 semanas | Testar em 25% do tráfego |
| 3 | p=quarantine; pct=100 | 2 semanas | Quarentena completa |
| 4 | p=reject | Permanente | Rejeição de emails não autenticados |
Etapa 4: verificar o alinhamento DMARC
O alinhamento é a peça que mais frequentemente falta. Ele exige que o domínio From: (cabeçalho RFC 5322) corresponda ao domínio autenticado por SPF ou DKIM:
| Verificação | Domínio comparado | Alinhamento |
|---|---|---|
| SPF | Domínio do MAIL FROM (envelope) | Deve corresponder ao domínio From: |
| DKIM | Domínio d= da assinatura | Deve corresponder ao domínio From: |
Exemplo de falha de alinhamento:
- From:
contact@captaindns.com - MAIL FROM:
bounce@promo.captaindns.com - SPF passa para
promo.captaindns.com, mas DMARC falha porque o From: écaptaindns.com
Em modo relaxed (adkim=r; aspf=r), os subdomínios são aceitos. Em modo strict (adkim=s; aspf=s), o domínio deve ser idêntico.
Etapa 5: garantir a criptografia TLS
O Gmail exige uma conexão TLS (STARTTLS) para aceitar emails. Verifique se seu servidor suporta STARTTLS:
openssl s_client -starttls smtp -connect mail.captaindns.com:25
Se a conexão TLS falhar, o Gmail retornará uma rejeição. Ative o TLS-RPT para receber relatórios diários sobre falhas de negociação TLS.
Corrigir o erro UsernameCaseMapped
Etapa 1: normalizar todos os endereços em minúsculas
A correção é simples, mas deve ser aplicada em todos os lugares. Cada endereço nos seus envios deve estar em minúsculas:
| Campo | Antes (risco de rejeição) | Depois (correto) |
|---|---|---|
| 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 |
Etapa 2: auditar os sistemas de envio
Liste todos os sistemas que enviam emails em nome do seu domínio e verifique como eles constroem o endereço From:
| Sistema | Risco | Verificação |
|---|---|---|
| CRM (HubSpot, Salesforce, Brevo) | Médio: frequentemente usa a entrada do usuário | Verificar as configurações do endereço remetente |
| Ferramenta de marketing (Mailchimp, SendGrid) | Baixo: geralmente normaliza | Confirmar nos logs |
| Aplicação interna / script | Elevado: nenhuma normalização por padrão | Auditar o código-fonte |
| Alias e redirecionamentos | Elevado: preserva a caixa original | Testar um envio e verificar os cabeçalhos |
| Formulário web (contato, cadastro) | Elevado: usa a entrada tal qual | Adicionar normalização antes do envio |
Etapa 3: automatizar a normalização
Adicione uma etapa de normalização sistemática nos seus fluxos de envio:
Python:
def normalize_email(address: str) -> str:
local, domain = address.rsplit("@", 1)
return f"{local.lower()}@{domain.lower()}"
# Uso
from_address = normalize_email("Marketing@CaptainDNS.com")
# Resultado: marketing@captaindns.com
Node.js:
function normalizeEmail(address) {
const [local, domain] = address.split('@');
return `${local.toLowerCase()}@${domain.toLowerCase()}`;
}
// Uso
const fromAddress = normalizeEmail('Marketing@CaptainDNS.com');
// Resultado: marketing@captaindns.com
Postfix (main.cf):
# Forçar a local-part em minúsculas para o MAIL FROM
lmtp_lowercase_quote_localpart = yes
Plano de ação recomendado
- Auditar seus fluxos de envio: liste todos os sistemas que enviam em nome do seu domínio (CRM, marketing, transacional, scripts, formulários)
- Normalizar em minúsculas: force todos os endereços From, MAIL FROM e Return-Path em lowercase em cada sistema
- Verificar SPF: todos os remetentes estão autorizados? O número de lookups DNS é <10?
- Verificar DKIM: chave de no mínimo 1.024 bits publicada no DNS, domínio
d=alinhado com o From:? - Publicar uma política DMARC:
p=nonemínimo com relatórios RUA ativos para começar - Controlar o alinhamento: o domínio From: corresponde ao domínio SPF ou DKIM?
- Ativar TLS-RPT: para monitorar falhas de criptografia nos seus emails recebidos
- Monitorar o Postmaster Tools: verificar diariamente a taxa de spam e a reputação do domínio/IP
FAQ
Qual é a diferença entre 550 5.7.26 e 421 4.7.26?
O código 421 4.7.26 é uma rejeição temporária com rate limiting: o Gmail desacelera seus envios, mas o servidor emissor pode tentar novamente depois. O código 550 5.7.26 é uma rejeição permanente: o email é definitivamente recusado e o servidor não deve tentar novamente. Um 421 sinaliza um problema pontual ou um volume incomum. Um 550 sinaliza um defeito estrutural de autenticação que exige correção na configuração.
Como saber se meu erro é UsernameCaseMapped ou 550 5.7.26?
O texto da mensagem de erro SMTP faz a distinção. Uma rejeição 550 5.7.26 menciona explicitamente "unauthenticated", "SPF" ou "DMARC policy". O erro UsernameCaseMapped aparece no texto da resposta SMTP com o termo "UsernameCaseMapped" e se refere à caixa do endereço, não à autenticação do domínio. Consulte os logs SMTP do seu servidor ou do seu provedor para ler a mensagem completa.
Meu SPF está configurado, por que continuo recebendo 550 5.7.26?
Três causas frequentes: (1) o IP de envio não está listado no SPF, verifique se todos os seus provedores estão incluídos; (2) o SPF ultrapassa 10 lookups DNS, o que invalida toda a política; (3) o SPF passa, mas o alinhamento DMARC falha porque o domínio MAIL FROM não corresponde ao domínio From:. Verifique o alinhamento além do SPF.
É necessário uma política DMARC p=reject para evitar a rejeição?
Não. O Gmail exige um registro DMARC publicado para remetentes em massa, mas p=none é suficiente como política mínima. A rejeição 550 5.7.26 acontece quando a autenticação falha (SPF e DKIM não passam), independentemente da sua política DMARC. No entanto, a variante "not accepted due to domain's DMARC policy" pode ser acionada se sua própria política for p=reject e o alinhamento falhar.
O erro UsernameCaseMapped afeta também o Google Workspace?
Sim. O Google Workspace aplica as mesmas regras de normalização PRECIS que o Gmail pessoal. Se você envia emails para endereços @suaempresa.com hospedados no Google Workspace com caixa incorreta no endereço From, a rejeição UsernameCaseMapped pode acontecer. A normalização em minúsculas se aplica a todas as contas Google.
Como testar o alinhamento DMARC antes de enviar em produção?
Publique uma política p=none com relatórios RUA ativados (rua=mailto:dmarc@captaindns.com). Envie um email de teste para uma conta Gmail e examine os cabeçalhos Authentication-Results. Verifique se dmarc=pass aparece. Se dmarc=fail, compare o domínio From: com os domínios SPF e DKIM nos resultados para identificar a falha de alinhamento.
O que significa 'Unauthenticated email not accepted due to domain's DMARC policy'?
Essa mensagem indica que seu domínio publicou uma política DMARC restritiva (p=quarantine ou p=reject) e que o email não passou nem na verificação SPF alinhada nem na verificação DKIM alinhada. O Gmail aplica sua própria política: como você pediu a rejeição de emails não autenticados, o Gmail rejeita. Verifique o alinhamento SPF e DKIM com o domínio From:.
As rejeições 550 5.7.26 afetam minha reputação de remetente?
Sim, indiretamente. Rejeições permanentes repetidas sinalizam ao Gmail que sua infraestrutura de envio não está corretamente configurada. Isso pode degradar a reputação dos seus IPs e do seu domínio no Google Postmaster Tools, o que então causa rate limiting (421) nos seus envios que passam a autenticação. Corrija rapidamente para evitar o efeito bola de neve.
Glossário
- 550: código SMTP de rejeição permanente. O servidor emissor não deve tentar o envio novamente.
- 5.7.26: enhanced status code (RFC 3463) indicando uma falha de autenticação do remetente.
- UsernameCaseMapped: perfil de normalização definido na RFC 8265 (PRECIS) que impõe a conversão em minúsculas da local-part dos identificadores.
- Alinhamento DMARC: correspondência entre o domínio do cabeçalho From: (RFC 5322) e o domínio autenticado por SPF ou DKIM. Necessário para passar na verificação DMARC.
- Envelope sender: endereço MAIL FROM usado na transação SMTP (RFC 5321), distinto do cabeçalho From: visível pelo destinatário.
- Remetente em massa (bulk sender): remetente que envia mais de 5.000 emails por dia para contas Gmail. Sujeito a exigências reforçadas desde fevereiro de 2024.
