SPF, DKIM & DMARC para Front.
O Front (front.com) é uma plataforma de caixa de entrada compartilhada e comunicação com clientes, não um provedor de hospedagem de e-mail — então "enviar em nome do seu domínio" pelo Front tem um significado específico. Quando você conecta um canal SMTP personalizado, o Front retransmite seu e-mail de saída pelo SendGrid, sua infraestrutura de e-mail subjacente (contas mais antigas retransmitiam pelo Mandrill, e é por isso que você talvez tenha visto uma tag legada "via mandrillapp.com"). Até você autenticar esse caminho, os destinatários veem uma nota "via sendgrid.net" no seu endereço De e seu e-mail tem uma probabilidade muito maior de cair no spam. As configurações de Deliverability do Front entregam três registros DNS — um MX, um SPF (como um TXT) e um DKIM (como um TXT) — que você adiciona a um subdomínio de envio dedicado front-mail. Como esses registros ficam no subdomínio em vez do seu domínio raiz, eles autorizam o SendGrid a enviar em seu nome, removem a tag "via" e alinham seu e-mail ao seu domínio para o DMARC, tudo isso sem tocar no seu SPF existente nem mudar para onde o seu e-mail de entrada é entregue.
Por que autenticar o Front?
Autenticar o domínio de envio do seu Front decide se as suas respostas vão chegar à caixa de entrada. Desde fevereiro de 2024, o Gmail e o Yahoo passaram a exigir que todo remetente em massa (mais ou menos 5.000+ mensagens por dia) passe em SPF, DKIM e DMARC com alinhamento, e a Microsoft começou a aplicar a mesma exigência para remetentes de alto volume em 2025 — e as equipes de suporte e sucesso que vivem no Front rotineiramente atingem esses volumes. Até você adicionar os registros, o Front envia seu e-mail pela infraestrutura compartilhada do SendGrid: os destinatários veem a tag "via sendgrid.net", seu endereço De não se alinha ao seu domínio, o DMARC não consegue passar pelo SPF e sua reputação de envio fica misturada com todos os outros inquilinos não autenticados dessa plataforma. Autenticar corrige tudo isso de uma vez — o SendGrid assina com uma chave DKIM publicada no seu subdomínio front-mail (para que a assinatura se alinhe ao seu domínio), o Return-Path do envelope fica nesse mesmo subdomínio (para que o SPF se alinhe no modo relaxado), a tag "via" desaparece, o DMARC passa e a reputação que você constrói fica acumulada no seu próprio domínio em vez do pool compartilhado.
A realidade do SPF para o Front
O Front é uma configuração de delegação de subdomínio, não um provedor de "include" — NÃO existe um include:sendgrid.net para você colar no seu domínio raiz. Em vez disso, todo o caminho autenticado fica em um subdomínio de envio dedicado que o Front rotula como front-mail. Esse subdomínio recebe três registros diretamente do painel Deliverability do Front: um registro MX apontando para o host de e-mail do SendGrid (mx.sendgrid.net) para que o SendGrid possa processar bounces, um registro SPF TXT (v=spf1 include:sendgrid.net ~all) restrito ao subdomínio e uma chave pública DKIM em um seletor sob esse mesmo subdomínio. O registro SPF do seu domínio organizacional é deixado exatamente como está — o include do Front fica em front-mail.yourdomain.com, então ele não custa nada do orçamento de 10 consultas DNS do seu SPF raiz. O DMARC ainda passa, mas observe o detalhe específico do Front: como TANTO o Return-Path do envelope QUANTO a chave DKIM ficam no subdomínio front-mail, tanto o SPF quanto o DKIM se alinham ao seu domínio organizacional no modo relaxado (o subdomínio compartilha o seu domínio registrável) — e nenhum dos dois se alinha no modo estrito. O relaxado é o padrão do DMARC, então o Front passa de imediato; apenas não force o alinhamento estrito (aspf=s ou adkim=s) para este domínio. Por fim, isso só se aplica a canais SMTP do Front; se o seu canal do Front for uma caixa de entrada conectada do Gmail ou do Microsoft 365, o Front envia pelos servidores desse próprio provedor e você autentica no Google/Microsoft — nenhum dos registros front-mail se aplica.
Duas maneiras de configurar
Canal SMTP do Front — adicione os registros do SendGrid (este guia)
- Aplica-se quando o seu canal é um canal SMTP personalizado — o Front retransmite seu e-mail de saída pelo SendGrid e você precisa autenticá-lo.
- Adicione MX + SPF (TXT) + DKIM (TXT) a um subdomínio de envio dedicado front-mail, copiados do painel Deliverability do Front.
- Os três registros ficam no subdomínio, então o SPF do seu domínio raiz permanece intocado — zero das suas 10 consultas SPF consumidas.
- Até o Front mostrar os registros como Verified, o e-mail sai 'via sendgrid.net' no pool compartilhado e corre risco de cair na pasta de spam.
Canal conectado do Gmail / Microsoft 365 — autentique lá em vez disso
- Aplica-se quando você adicionou sua caixa de entrada ao Front pela integração do Google ou do Microsoft 365 — o Front envia por esse provedor, não pelo SendGrid.
- A autenticação é herdada do SPF, DKIM e DMARC do seu Google Workspace ou Microsoft 365 — configure-os nesse provedor.
- Não há subdomínio front-mail, nem MX para mx.sendgrid.net, e nenhum dos registros SPF/DKIM do SendGrid se aplica.
- A tag 'via sendgrid.net' nunca aparece porque o SendGrid não está no caminho de envio.
Passo a passo
- 1
Confirme que o canal é um canal SMTP
Estes registros só se aplicam a canais SMTP do Front (e-mail retransmitido pelo SendGrid). Se o seu canal for uma caixa de entrada conectada do Gmail ou do Microsoft 365, o Front envia por esse provedor — pare aqui e autentique no Google/Microsoft. Verifique o tipo de canal em Settings → Channels.
- 2
Abra as configurações de Deliverability
Para canais de toda a empresa, clique na engrenagem Settings → Company settings → Security na barra lateral → a aba Deliverability. Esta página só aparece para administradores da empresa quando existe pelo menos um canal SMTP compartilhado. Para o canal de um colega de equipe individual, abra Settings → o canal SMTP do colega → aba Settings → a seção 'Improve delivery rates - SPF / DKIM'.
- 3
Selecione o domínio de envio
Em Domains, escolha o domínio de onde você envia. Qualquer domínio sem SPF/DKIM exibe um ícone de aviso amarelo. O Front então mostra o Name e o Value de três registros a adicionar: um MX, um SPF (TXT) e um DKIM (TXT). Mantenha este painel aberto para copiar — o seletor, o host e os valores de chave exatos são únicos para a sua conta.
- 4
Adicione o registro MX no subdomínio front-mail
Crie um registro MX: Host/Name = o rótulo de subdomínio que o Front mostra (por exemplo, front-mail), Value/Target = o host de e-mail do SendGrid (por exemplo, mx.sendgrid.net), Priority = conforme mostrado (o Front comumente usa 10). Este é um NOVO MX no subdomínio para o tratamento de bounces do SendGrid — ele NÃO altera o seu MX principal (host @) nem para onde o seu e-mail de entrada é entregue.
- 5
Adicione o registro SPF (TXT)
Crie um registro TXT: Host/Name = front-mail, Value = exatamente o que o Front mostra (por exemplo, v=spf1 include:sendgrid.net ~all). Este SPF é restrito apenas ao subdomínio de envio — NÃO adicione include:sendgrid.net ao registro SPF do seu domínio raiz.
- 6
Adicione o registro DKIM (TXT)
Crie um registro TXT com o host do seletor que o Front mostra (por exemplo, s1._domainkey.front-mail) e cole o longo valor da chave pública do Front exatamente, sem espaços ou quebras de linha adicionais. O Front usa o whitelabel clássico do SendGrid, então esta é uma única chave TXT estática, não os CNAMEs que rotacionam automaticamente da autenticação de domínio moderna do SendGrid.
- 7
Insira os hosts apenas como rótulos e não toque nos registros existentes
Digite apenas o rótulo (front-mail, s1._domainkey.front-mail) — a maioria dos registradores acrescenta o seu domínio automaticamente, e inserir o front-mail.yourdomain.com completo produz um nome duplicado que não resolve. Adicione apenas estes três NOVOS registros; não edite nem apague nenhum registro DNS existente, o que pode quebrar a entrega.
- 8
Publique sua política DMARC (se você ainda não tiver uma)
No seu domínio raiz, adicione um registro TXT em _dmarc com v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Mantenha exatamente um registro _dmarc para o domínio inteiro. Deixe o alinhamento no seu padrão relaxado — o subdomínio front-mail do Front carrega tanto o SPF quanto o DKIM no modo relaxado, então não configure aspf=s ou adkim=s, pois qualquer um deles quebraria a autenticação do Front.
- 9
Clique em 'Check DNS settings' no Front
Volte ao painel Deliverability do Front e clique em Check DNS settings — isso dispara uma verificação através do SendGrid. Quando os registros resolvem, cada um vira Verified e o ícone de aviso amarelo some do canal. A propagação de DNS geralmente leva minutos, mas pode levar até 24–48 horas.
- 10
Envie um teste real e confirme o alinhamento
Envie uma mensagem para você mesmo pelo canal do Front, abra-a no Gmail e use ⋮ → Show original. Confirme SPF: PASS, DKIM: PASS signed-by front-mail.yourdomain.com, DMARC: PASS, e que a tag 'via sendgrid.net' sumiu da linha De.
Registros a adicionar
O Front gera os valores exatos no seu assistente de configuração — estes mostram o formato do que você vai adicionar no seu provedor de DNS.
| Tipo | Host | Valor |
|---|---|---|
| MX | front-mail | mx.sendgrid.netReturn-Path do subdomínio de envio — o host de bounces do SendGrid, prioridade conforme mostrada pelo Front (comumente 10). O subdomínio e o host exatos vêm do painel Deliverability do Front. Este NÃO é o seu MX principal e não afeta o e-mail de entrada. |
| TXT | front-mail | v=spf1 include:sendgrid.net ~allSPF apenas para o subdomínio de envio — nunca adicionado ao seu domínio raiz, então ele custa 0 das 10 consultas do seu SPF raiz. Copie o valor exato do Front. |
| TXT | s1._domainkey.front-mail | k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC…Chave pública DKIM (única TXT estática). O Front/SendGrid fornece o seletor e a chave exatos — o host e o valor são únicos para a sua conta; este é apenas ilustrativo. Como a chave fica sob front-mail, o d= da assinatura é o subdomínio e se alinha ao seu domínio no modo relaxado. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comSua política DMARC — uma por domínio raiz. O Front autentica inteiramente através do subdomínio front-mail, então mantenha o alinhamento relaxado (o padrão); estrito (aspf=s ou adkim=s) quebra o Front. |
Mantenha exatamente um registro TXT de SPF (v=spf1) no seu domínio raiz — combine todos os remetentes nele. Ter dois registros SPF já é, por si só, um erro.
O limite de 10 consultas de DNS
O SPF tem um limite rígido de 10 consultas de DNS — se passar disso, ele retorna um permerror e para de validar em todo lugar. Veja quanto a configuração do Front consome desse limite.
A configuração recomendada do Front adiciona 0 consultas — todas as 10 ficam livres para os remetentes que realmente precisam de um include.
DKIM
O DKIM do Front é um único registro TXT estático de chave pública que o Front gera através do SendGrid e mostra a você no painel Deliverability. Você o publica no seletor do subdomínio de envio (algo como s1._domainkey.front-mail.yourdomain.com); o SendGrid guarda a chave privada correspondente e assina cada mensagem que o Front retransmite. Como a chave fica sob front-mail, a assinatura DKIM carrega d=front-mail.yourdomain.com, que se alinha ao seu domínio organizacional no modo relaxado — o padrão do DMARC — do mesmo jeito que o Return-Path do SPF. Ela não se alinha no modo estrito, então não configure adkim=s para este domínio. Duas coisas tornam o DKIM do Front diferente da autenticação de domínio moderna do SendGrid. Primeiro, é uma chave TXT estática, não um CNAME que rotaciona automaticamente — o Front usa o whitelabel clássico do SendGrid, então você cola a chave uma vez e ela não rotaciona sozinha (nada é delegado para re-resolver, mas também nada rotaciona as chaves por você). Segundo, como é uma chave pública completa em um valor TXT, ela pode ultrapassar o limite de 255 caracteres de uma única string; a maioria dos painéis DNS a armazena automaticamente como um único registro dividido em partes, mas se depois um verificador reportar a chave como inválida, um valor adulterado ou truncado costuma ser a causa — cole-a de novo exatamente como o Front mostra. O seletor atribuído pelo SendGrid não vai colidir com os seletores DKIM do seu Google (google) ou da Microsoft (selector1/selector2), então o DKIM do Front convive com o do seu provedor de caixa de entrada. O DKIM ainda é o mais resistente a encaminhamento dos seus dois sinais — ele sobrevive ao encaminhamento de mensagens onde o SPF quebra — mas, para o alinhamento DMARC, ele usa o mesmo modo relaxado do SPF, então mantenha o alinhamento da sua política em relaxado.
DMARC
O DMARC é um registro de política separado que você publica no seu domínio raiz — o Front não o cria para você, embora sua documentação de deliverability oriente você pela interação. Adicione um registro TXT em _dmarc.yourdomain.com começando com v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. O p=none é apenas de monitoramento, então ele não vai afetar a entrega enquanto você confirma que o e-mail do Front autentica. O detalhe específico do Front é o alinhamento: como o SendGrid usa o subdomínio front-mail TANTO para o Return-Path do envelope QUANTO para o domínio d= do DKIM, o e-mail do Front se alinha ao seu domínio organizacional no modo RELAXADO tanto no SPF quanto no DKIM — e no modo ESTRITO em nenhum dos dois. O relaxado é o padrão do DMARC, então uma política padrão passa o Front de imediato; você não precisa adicionar nada. O problema só aparece se o seu DMARC existente forçar o alinhamento estrito: aspf=s quebra o alinhamento SPF do Front e adkim=s quebra o alinhamento DKIM, e estrito em ambos reprova o Front por completo. Mantenha o alinhamento relaxado (você pode deixá-lo explícito com aspf=r; adkim=r). Mantenha exatamente um registro _dmarc para o domínio inteiro, não importa quantos remetentes (Front, seu provedor de caixa de entrada, ferramentas de marketing) você use — nunca adicione um segundo registro DMARC para o Front. Assim que os relatórios agregados confirmarem que o Front/SendGrid está autenticando corretamente, aperte de p=none para p=quarantine e, por fim, p=reject.
Confirme que funcionou de verdade
Não confie apenas no selo Verified do Front — confirme em uma mensagem real. Depois que o Check DNS settings mostrar os registros como Verified, envie um e-mail para você mesmo pelo canal do Front, abra-o no Gmail e escolha ⋮ → Show original. Você quer ver SPF: PASS (mailed-by front-mail.yourdomain.com), DKIM: PASS com signed-by: front-mail.yourdomain.com e DMARC: PASS — e a tag 'via sendgrid.net' deve ter sumido da linha De. Você pode verificar os registros brutos com dig MX front-mail.yourdomain.com (espere mx.sendgrid.net), dig TXT front-mail.yourdomain.com (espere a linha v=spf1 include:sendgrid.net), dig TXT s1._domainkey.front-mail.yourdomain.com (espere a chave DKIM) e dig TXT _dmarc.yourdomain.com. Depois, passe seu domínio pela verificação de saúde de domínio da Qualisend para confirmar que cada registro resolve e que o seu SPF raiz continua abaixo do limite de 10 consultas e, assim que os relatórios agregados de DMARC começarem a chegar, jogue um deles no analisador de relatórios DMARC — o Front deve aparecer como uma fonte alinhada e aprovada (a infraestrutura do SendGrid assinando em nome do seu domínio).
Pegadinhas comuns
- Cobertura
O registro MX que o Front pede NÃO é o seu MX principal. Ele fica no subdomínio front-mail e só permite que o SendGrid processe bounces do e-mail de saída do Front — ele não redireciona a sua caixa de entrada nem muda para onde o e-mail de entrada é entregue. O seu MX existente no host @ permanece intocado.
- Cobertura
Insira os hosts apenas como o rótulo — front-mail, s1._domainkey.front-mail — não o front-mail.yourdomain.com completo. A maioria dos registradores acrescenta o seu domínio automaticamente, e o nome duplicado (front-mail.yourdomain.com.yourdomain.com) não resolve, então o Check DNS settings falha.
- Cobertura
Adicione apenas três NOVOS registros. O Front avisa explicitamente para não editar nem apagar registros DNS existentes durante este processo — modificar o seu SPF, MX ou DKIM atual pode quebrar a entrega.
- Configuração de DNS
Não adicione include:sendgrid.net ao seu SPF RAIZ. O Front restringe o SPF ao subdomínio front-mail, então um include na raiz é redundante, consome desnecessariamente uma das suas 10 consultas SPF e não é o que o SendGrid verifica para o Front.
- Cobertura
O alinhamento estrito do DMARC quebra o Front. Tanto o Return-Path do envelope quanto a chave DKIM ficam no subdomínio front-mail, então o SPF e o DKIM se alinham ao seu domínio apenas no modo relaxado. Configurar aspf=s quebra o alinhamento SPF do Front e adkim=s quebra o alinhamento DKIM — estrito em ambos reprova o Front por completo. O relaxado é o padrão, então deixe o alinhamento como está.
- Cobertura
Canais conectados do Gmail / Microsoft 365 não usam estes registros de jeito nenhum. Se o Front envia pela sua caixa de entrada do Google ou da Microsoft em vez de um canal SMTP, não há subdomínio front-mail nem tag via — autentique nesse provedor.
- Configuração de DNS
Registros MX e TXT não podem ser proxied, então no Cloudflare não há etapa de nuvem laranja/nuvem cinza aqui (diferente da autenticação de domínio do SendGrid baseada em CNAME). Apenas garanta que você os criou como MX e TXT, não como algum outro tipo.
- Cobertura
Cada domínio e canal de envio SMTP é autenticado separadamente. Configurar um domínio não cobre os outros — o painel Deliverability sinaliza qualquer domínio que ainda esteja sem registros com um ícone de aviso amarelo.
Monte seu registro SPF
O Front não precisa de um include: de SPF no seu domínio raiz — use o gerador para montar um único registro limpo para os seus outros remetentes, e mantenha tudo em uma só linha.
Sending sources
Search for each platform you send email through and tick it.
Search for your email platform above, or .
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listSPF do Front — Perguntas frequentes
Leituras relacionadas
Depois de publicado, confirme se tudo resolve corretamente com o verificação de saúde do domínio e, em seguida, veja quem está enviando em seu nome com o analisador de relatórios DMARC. Explore todas as fontes de envio no gerador. A autenticação, porém, é só metade da entregabilidade — um IP ou domínio de envio que esteja listado ainda te joga no spam por mais limpo que seu SPF esteja, então vale a pena acompanhar as blacklists com o monitoramento de blacklists.
Autenticado — agora mantenha a lista limpa
Passar em SPF, DKIM e DMARC te leva à caixa de entrada; uma lista limpa te mantém lá. Verifique a sua — comece grátis com 100 créditos, sem precisar de cartão.