# Ligar uma aplicação ao mxout

Depois que o domínio está ativo, o passo é criar um cliente — a identidade daquela aplicação — e apontar a aplicação para o mxout.

# 1. Criar o cliente

curl -X POST http://<mxout>:8080/clients \
  -H "X-Auth-Token: {TOKEN_ADMIN}" \
  -H 'Content-Type: application/json' \
  -d '{"name": "nfse", "domains": ["minhaempresa.com.br"]}'

{
  "client_id": "cli_a3f9c1d2e4b6",
  "secret": "3f9a1c...",
  "aviso": "guarde a senha: ela não será exibida de novo"
}

Guarde a senha agora, num gerenciador. Ela é armazenada como bcrypt e não há como recuperá-la — só rotacionar, o que invalida a anterior na hora.

Um cliente por aplicação. É o que permite revogar uma sem derrubar as outras, e saber quem enviou o quê.

# 2a. Configurar por SMTP

Para Mautic, WordPress, mail() do PHP e afins:

Host:     <host do mxout>
Porta:    2525
Usuário:  cli_a3f9c1d2e4b6
Senha:    a senha do passo 1
TLS:      STARTTLS

Se o certificado for o auto-assinado padrão, a aplicação precisa aceitar certificado não confiável (a opção costuma se chamar "permitir auto-assinado" ou verify=False). Para certificado real, ver Submissão SMTP.

# 2b. Ou por HTTP

import base64, json, urllib.request
from email.message import EmailMessage

msg = EmailMessage()
msg["From"] = "NFS-e <no-reply@minhaempresa.com.br>"
msg["To"] = "cliente@exemplo.com"
msg["Subject"] = "Sua nota fiscal"
msg.set_content("Segue em anexo.")
msg.add_attachment(pdf, maintype="application", subtype="pdf", filename="nota.pdf")

cred = base64.b64encode(b"cli_a3f9c1d2e4b6:SENHA").decode()
req = urllib.request.Request(
    "http://<mxout>:8080/send-raw",
    data=json.dumps({
        "from": "no-reply@minhaempresa.com.br",
        "to": ["cliente@exemplo.com"],
        "raw": msg.as_string(),
    }).encode(),
    headers={"Content-Type": "application/json", "Authorization": f"Basic {cred}"},
    method="POST",
)
print(urllib.request.urlopen(req).read().decode())

# 3. Conferir que saiu

curl "http://<mxout>:8080/queue?limite=10" -H "X-Auth-Token: {TOKEN_ADMIN}"

No modo assíncrono a mensagem fica queued até o próximo tick do cron (até 1 minuto). Depois vira sent ou failed, com o erro real do servidor de destino em last_error.

# A regra que mais pega

O header From da mensagem tem que bater com o remetente do envelope. Se a sua aplicação manda MAIL FROM: bounce@a.com mas o header diz From: contato@b.com, a mensagem é recusada.

Não é rigor à toa: o d= da assinatura DKIM sai do header From, e permitir a divergência seria permitir que um cliente enviasse mensagens que aparentam vir de domínio alheio.

Muita biblioteca deixa configurar as duas coisas em separado. Se aparecer 550 5.7.1 header From não confere, é isso.

# Erros comuns