E-mails falsos em nome do seu hotel: SPF, DKIM e DMARC sem jargão

Qualquer servidor de e-mail pode escrever o endereço do seu hotel no campo "De", porque o correio eletrónico, por si só, não confirma quem envia. Três registos no DNS do domínio (as definições públicas do domínio, que se mudam no painel da empresa onde o domínio está registado ou alojado) fecham esta porta: o SPF lista os servidores autorizados, o DKIM assina cada mensagem e o DMARC diz aos servidores dos hóspedes o que fazer com um e-mail que falhe os dois. Enquanto o DMARC não estiver em quarantine ou reject, essa decisão fica com quem recebe.

Porque é que um hotel é um alvo fácil

Os hóspedes esperam receber e-mails do hotel com pedidos de dinheiro: o sinal da reserva, o saldo antes da chegada, um IBAN para transferência. Uma mensagem falsa vinda de "reservas@" com outro IBAN parece normal a quem acabou de reservar. As burlas mais faladas no setor passam pelo chat da Booking, e explicamos como se defender delas no artigo sobre burlas com contas da Booking. O e-mail com o domínio do hotel é outra porta, e esta o próprio hotel pode fechar.

Sem DMARC, o servidor que recebe a mensagem decide com as suas próprias regras. O domínio do hotel não lhe deu instrução nenhuma, e um e-mail falso pode chegar à caixa de entrada com o nome do hotel bem escrito no remetente.

Os três registos, em palavras simples

O SPF é uma lista pública dos servidores autorizados a enviar e-mail com o seu domínio. Funciona como a lista, afixada na receção, das pessoas que podem assinar a entrega de encomendas em nome da casa.

O DKIM é uma assinatura digital que o servidor de envio acrescenta a cada mensagem. A chave para a conferir está publicada no DNS do domínio. Se a mensagem for alterada pelo caminho, ou enviada por quem não tem a chave, a assinatura não confere.

O DMARC junta os dois e acrescenta uma regra. Segundo a especificação atual do DMARC (RFC 9989, de maio de 2026), pelo menos um deles tem de passar com o mesmo domínio que aparece no campo "De" (seuhotel.pt e mail.seuhotel.pt contam como o mesmo). A isto chama-se alinhamento. O registo diz depois o que fazer com o resto:

• p=none: não fazer nada de especial, só enviar relatórios;
• p=quarantine: tratar a mensagem como suspeita, por exemplo pô-la no spam;
• p=reject: recusar a mensagem.

Os servidores que recebem correio enviam ainda relatórios diários para o endereço indicado em rua=, com a lista de quem andou a enviar e-mail em nome do domínio. Esses relatórios são o que permite subir de nível sem surpresas.

O que vimos nos domínios do Sotavento

Em novembro de 2026 verificámos os 109 sites que os empreendimentos turísticos do Sotavento indicam no Registo Nacional de Turismo. Nos 94 que abriram contámos 83 domínios distintos e lemos os registos públicos de DNS de cada um. O método completo está no estudo dos 109 sites.

33 domínios (40%) não têm registo DMARC e 23 (28%) têm DMARC em p=none, só a observar. Juntos, são 56 de 83 (67%) que não dão aos servidores de quem recebe nenhuma instrução para rejeitar ou pôr em quarentena e-mail falsificado com o seu domínio. 15 (18%) estão em quarantine e 12 (14%) em reject. Há 12 (14%) que nem registo SPF têm.

Seis dos 94 sites mostram um endereço gratuito (Gmail, Hotmail e semelhantes) como contacto. Nesses casos o hotel não controla o domínio e não pode publicar DMARC nenhum. O alojamento local ficou fora destas contas, porque o registo do AL não tem campo para o site.

O que a Google, a Yahoo e a Microsoft já exigem

Desde 1 de fevereiro de 2024, a Google exige a quem envia para contas Gmail que tenha SPF ou DKIM. Quem envia mais de 5 000 mensagens por dia tem de ter SPF, DKIM e DMARC (a política pode ficar em none), alinhamento com o domínio do remetente e cancelamento de subscrição com um clique nas mensagens de marketing, segundo as regras para remetentes da Google. A Yahoo aplicou regras equivalentes no mesmo mês.

Em abril de 2025, a Microsoft anunciou regras semelhantes para o Outlook.com, que serve os endereços hotmail.com, live.com e outlook.com, para domínios que enviam mais de 5 000 mensagens por dia. Numa atualização de 29 de abril, a Microsoft decidiu que, desde 5 de maio de 2025, as mensagens desses domínios que não cumpram são rejeitadas, em vez de irem para a pasta de lixo eletrónico como estava previsto.

Um hotel de 20 quartos raramente envia 5 000 e-mails num dia, mas a newsletter de inverno, se a lista for grande, pode lá chegar. Nenhuma destas regras obriga a ter reject. Protegem as caixas de correio dos clientes da Google, da Yahoo e da Microsoft, e a proteção do nome do hotel continua a depender da política que o próprio hotel publica.

Como verificar em dois minutos

• Abra a ferramenta Dig da Google, escolha o tipo TXT e escreva _dmarc.seudominio.pt. Se não aparecer nada, não tem DMARC. Se aparecer p=none, está só a observar. p=quarantine ou p=reject querem dizer que há uma instrução.
• Na mesma ferramenta, escreva só seudominio.pt com o tipo TXT e procure uma linha que comece por v=spf1. Se não existir, falta o SPF.
• Envie um e-mail do endereço do hotel para uma conta Gmail. No computador, abra a mensagem e clique na seta por baixo do nome do remetente, como explica a ajuda do Gmail. A linha "assinado por" deve mostrar o domínio do hotel; a linha "enviado por" pode mostrar o de um fornecedor. Repita com uma confirmação do motor de reservas e com uma fatura enviada pelo programa de faturação.

Se o "assinado por" mostrar o domínio do fornecedor e não o seu, esse serviço ainda não tem DKIM alinhado.

De none a reject, sem partir nada

A Google recomenda começar com p=none durante pelo menos uma semana e ler os relatórios diários. Depois, passar a quarantine numa pequena percentagem das mensagens e subir aos poucos até 100% (a nova versão da norma, de maio de 2026, deixou de prever essa percentagem, por isso alguns servidores podem aplicar logo a política a todas). O reject fica para o fim. A DMARC.org descreve o mesmo percurso: observar, corrigir os fluxos de e-mail, apertar a política à medida que ganha experiência.

Foi o que fizemos a 7 de novembro de 2026 no livinstaysalgarve.com, um site que construímos. O domínio estava em p=none. Antes de mudar, confirmámos que os dois remetentes reais passavam o DKIM alinhado com o domínio: os e-mails da aplicação para os hóspedes, enviados através da Resend, e as caixas de correio da Titan. Nessa noite a política passou para quarantine. O reject vem depois de 2 a 4 semanas de relatórios limpos.

O que costuma partir pelo caminho

Parte tudo o que envia e-mail com o endereço do hotel a partir de servidores de outra empresa e ainda não foi configurado. Num alojamento, a lista costuma incluir:

• a ferramenta de newsletters;
• o motor de reservas e o programa de gestão (PMS), que enviam confirmações com o endereço do hotel no "De";
• o programa de faturação que envia as faturas por e-mail;
• o formulário de contacto do site, que muitas vezes envia a partir do servidor de alojamento web com o endereço do hotel como remetente;
• equipamentos que mandam alertas por e-mail, como alarmes ou impressoras.

Cada um precisa de DKIM com o seu domínio (normalmente um ou dois registos que o fornecedor indica) ou de entrar no SPF. O SPF tem um limite: no máximo 10 consultas de DNS por verificação, e acima disso o resultado é um erro, segundo a RFC 7208. Por isso, para serviços externos, o DKIM é o caminho mais seguro.

Em p=none nada disto se perde: os relatórios mostram os serviços em falta e há tempo para os corrigir. Em quarantine ou reject, o que estiver por corrigir vai para o spam ou é recusado.

O que fazer esta semana

1. Verifique o DMARC e o SPF do domínio, como descrito acima.
2. Faça a lista de tudo o que envia e-mail com o endereço do hotel: caixas de correio, motor de reservas, PMS, faturação, newsletter, formulário do site.
3. Se não tem DMARC, publique v=DMARC1; p=none; rua=mailto: seguido de um endereço que alguém leia, ou de um serviço que resuma os relatórios.
4. Peça a cada fornecedor da lista as instruções de DKIM para o seu domínio e acrescente os registos no DNS.
5. Ao fim de uma a duas semanas, se os relatórios só mostrarem serviços conhecidos e alinhados, passe a p=quarantine.
6. Marque na agenda a passagem a p=reject para 2 a 4 semanas depois, se os relatórios continuarem limpos.
7. Ative a verificação em dois passos na conta onde gere o DNS do domínio. Quem entra nessa conta pode mudar todos estes registos, e o artigo sobre domínios expirados explica o resto dos cuidados com ela.

O Raio-X Digital inclui a leitura destes registos, e o plano de DMARC faz parte do nosso serviço de segurança. Os outros avisos que o site deve mostrar estão no artigo sobre avisos legais obrigatórios.