Mi DTE ya tiene el sello de recepción de Hacienda. ¿Eso significa que el cliente lo recibió?

No. El sello de recepción confirma que el Ministerio de Hacienda validó y aceptó el documento. La entrega al cliente es un paso aparte y en la mayoría de configuraciones ocurre por correo enviado desde tu proveedor de facturación. Un documento puede tener validez fiscal y estar en la carpeta de spam.

¿Tengo que publicar DKIM si mi proveedor de facturación ya firma sus mensajes?

Sí, si las facturas salen con tu dominio en el encabezado From. DMARC solo acepta una firma cuyo dominio coincida con el del From, así que una firma hecha con el dominio del proveedor no te sirve para la alineación. Pídele al proveedor los registros DKIM para publicarlos en tu propio dominio.

¿Puedo agregar un segundo registro SPF para el proveedor de facturación?

No. Un dominio solo puede publicar un registro que empiece con v=spf1. Un segundo registro genera un PermError según el RFC 7208, que reprueba SPF para todos los remitentes del dominio, incluidos los que ya funcionaban. Fusiona el include del proveedor dentro del registro que ya existe.

Facturas DTE en spam: cómo autorizar a tu proveedor

Digamos que una distribuidora de 14 personas en Santa Tecla emite unas doscientas facturas electrónicas al día. Cada DTE sube a Hacienda, regresa el sello de recepción, el sistema de facturación se ve verde de principio a fin. Y aun así tres clientes llaman la misma semana preguntando dónde está su factura. Nada rebotó. El correo cayó en spam, o en una cuarentena que el área de sistemas del cliente revisa una vez por trimestre, y contabilidad se enteró por teléfono.

Nos llaman por esto varias veces al año en El Salvador, y casi nunca es el sistema de facturación. Es un problema de autenticación de correo disfrazado de problema de facturación. Este es el orden en que lo trabajamos, que además es el orden que evita que rompas otra cosa en el camino.

Cómo llega de verdad un DTE a tu cliente

La mitad fiscal del proceso es la que todo el mundo conoce. Tu sistema arma el DTE en JSON, lo firma electrónicamente, lo transmite al Ministerio de Hacienda y recibe el sello de recepción que le da validez fiscal al documento. Después, la normativa de facturación electrónica deja la entrega en manos del emisor: el cliente tiene que recibir el archivo del DTE y su versión legible, el PDF con el código QR que permite verificar el documento en el portal de Hacienda.

Ese último paso es correo electrónico común y corriente. Y en la mayoría de implementaciones que abrimos, no lo manda tu servidor de correo. Lo manda tu proveedor de facturación, desde su propia infraestructura, con el nombre de tu empresa en el remitente. Para Gmail, para Outlook, para donde sea que tu cliente lea su correo, eso es un tercero mandando mensajes que dicen ser tuyos. Tiene exactamente la forma de un intento de phishing. Lo único que separa tus facturas de ese veredicto es la autenticación que tú tienes que publicar en tu propio DNS.

Por qué el correo de facturación falla más que el resto

El correo del personal sale por Google Workspace o Microsoft 365, que lo firman bien en cuanto el dominio queda configurado, así que se porta bien. El correo de facturación va por otro camino, y ahí se rompen cuatro cosas.

Nadie autorizó nunca al proveedor. El dominio tiene un SPF que nombra a Workspace y nada más, así que todo lo que manda el proveedor falla SPF desde el primer día que lo encendieron.
El proveedor firma con su propio dominio. A DMARC no le importa que el mensaje traiga una firma válida. Le importa si el dominio que firma, el de la etiqueta d=, o el dominio que SPF revisó en el Return-Path, coincide con el dominio del encabezado From. RFC 7489 llama a eso alineación de identificadores, y hasta el modo relajado por defecto exige el mismo dominio organizacional de los dos lados. Un mensaje firmado impecablemente por tu proveedor es correo no alineado para tu política.
Hay dos registros SPF. Alguien publicó un segundo TXT que empieza con v=spf1 en vez de fusionarlo con el primero. RFC 7208 convierte eso en un PermError, y un PermError reprueba a todos los remitentes del dominio, incluidos los que ayer funcionaban.
El registro pasó de diez consultas. La evaluación de SPF está limitada a diez mecanismos que consultan DNS, más dos consultas vacías, en la sección 4.6.4 del RFC 7208. Workspace, un proveedor de facturación, un CRM y una herramienta de correo masivo llegan a ese techo más rápido de lo que uno cree, y el resultado es el mismo PermError.

Del lado que recibe también apretaron. Las directrices de remitentes de Google piden que todo remitente se autentique con SPF o DKIM, use TLS y mantenga las quejas de spam de los usuarios por debajo del 0.3 por ciento, y a quien manda más de unos 5,000 mensajes diarios a cuentas de Gmail le piden SPF, DKIM y un registro DMARC publicado. Una corrida de facturas de fin de mes cruza esa línea sin que nadie en la empresa la considere correo masivo.

Primero averigua cómo manda realmente tu proveedor

Antes de tocar DNS le pedimos a un cliente que nos reenvíe un correo de factura real con los encabezados completos, y lo leemos. Hay tres arquitecturas y cada una necesita una solución distinta.

El proveedor manda como tú. El From es tu dominio. Es el caso común, y el que necesita tanto la autorización en SPF como una llave DKIM publicada en tu dominio.
El proveedor manda como él mismo. El From es el dominio del proveedor y el nombre de tu empresa va en el nombre visible. Tu política DMARC no entra en juego. La entrega depende de la reputación del proveedor, y tu trabajo se reduce a asegurarte de que la dirección de respuesta llegue a alguien que sí trabaja contigo.
El proveedor pasa por tu buzón. Entra a tu cuenta de Workspace o Microsoft 365 por SMTP y manda desde ahí. La autenticación ya está correcta porque tu propia plataforma firma el mensaje. Aquí las fallas son límites de envío, una contraseña de aplicación vencida o una configuración de retransmisión, nunca DNS.

Los encabezados resuelven esto en unos diez segundos. Mira el Return-Path, el valor d= dentro del DKIM-Signature y lo que dice Authentication-Results para spf, dkim y dmarc. Si prefieres no leerlos a mano, pega el mensaje en nuestro analizador de cabeceras.

Autorizar al proveedor en SPF y DKIM

Todo lo de esta sección aplica al caso uno. Pídele dos cosas concretas a tu proveedor y no adivines ninguna: el include exacto de SPF que publica y los registros DKIM que quiere en tu dominio. Cualquier proveedor que valga lo que cobra documenta los dos. Si el tuyo no te sabe responder, eso también es información sobre el proveedor.

SPF sigue siendo un solo registro fusionado en la raíz del dominio, con todos los remitentes adentro:

Tipo:  TXT
Host:  @
Valor: v=spf1 include:_spf.google.com include:spf.proveedor.example ~all

Dos reglas que conviene tener en la cabeza mientras editas. Solo existe un registro que empiece con v=spf1 por nombre, y el techo de diez consultas cuenta lo que incluyen tus includes, no solo lo que escribiste tú.

DKIM es la mitad que sobrevive al reenvío, así que aquí pesa más que SPF. En Google Workspace generas la llave en la consola de administración, en Apps, Google Workspace, Gmail, Autenticar correo electrónico, dejando los valores por defecto de llave de 2048 bits y selector google, y publicas lo que te muestre:

Tipo:  TXT
Host:  google._domainkey
Valor: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

Una llave de 2048 bits no cabe en una sola cadena DNS de 255 caracteres. La indicación de Google es partirla en varias cadenas entre comillas, una tras otra dentro del mismo registro, cosa que la mayoría de editores de DNS ya hace por ti. Cuando el registro resuelva, regresa a la consola y da clic en Iniciar autenticación, porque publicar la llave no enciende la firma.

Después haz lo mismo con el proveedor de facturación, con el host y el valor que él te dé. Si tu presupuesto de SPF ya viene ajustado, lo más limpio es darle al proveedor un subdominio propio y que él cargue con el peso:

Host:  facturacion
Valor: v=spf1 include:spf.proveedor.example -all

Las facturas salen entonces como facturacion@tudominio.example, el registro de la raíz se queda corto y un problema del remitente de facturación nunca puede tumbar el correo de tu gente. Recurrimos a esto cada vez que un cliente tiene más de tres remitentes externos. La versión larga de esa aritmética está en nuestra guía sobre cómo bajar del límite de diez consultas de SPF.

DMARC, y el reporte que te dice la verdad

Con SPF y DKIM en su lugar todavía no ves qué están haciendo los receptores con tus facturas. DMARC es lo que convierte eso en datos. Empieza en p=none, que no cambia nada de la entrega y solo pide reportes:

Tipo:  TXT
Host:  _dmarc
Valor: v=DMARC1; p=none; rua=mailto:dmarc@tudominio.example; fo=1

Dale dos semanas. Los reportes agregados te van a mostrar todas las fuentes que mandan bajo tu dominio, que suele ser donde la empresa descubre la herramienta de marketing que nadie mencionó, o un servidor viejo que todavía retransmite confirmaciones de pedido. Tira uno en nuestro analizador de reportes DMARC si el XML no es tu idea de una buena tarde, y lee cómo leer un reporte agregado para entender qué significa cada fila.

Solo cuando todos los remitentes legítimos aparezcan alineados pasas a cuarentena y después a rechazo. Irse directo a p=reject en un dominio que factura es la forma de que un lunes por la mañana la empresa deje de entregar sus propias facturas, y nos ha tocado deshacer justamente eso. La versión por etapas está en nuestra guía de despliegue.

Cuando la autenticación ya está bien y las facturas siguen cayendo en spam

Pasa, y esta es la lista que revisamos.

Los adjuntos. Un correo de DTE lleva un archivo JSON, que es raro en el correo de negocios normal. Si el destinatario usa Workspace o Microsoft 365, una regla de adjuntos de su lado puede poner el mensaje en cuarentena sin generar ningún rebote. Vale la pena preguntarlo de frente, porque en los encabezados no se parece en nada a una falla de autenticación.
El remitente es un no-reply en el que nadie confía. Que los clientes marquen como spam el correo de facturas es una señal real en tu contra, y un remitente al que no se le puede contestar se gana ese trato.
El pico mensual. Un dominio que manda cuarenta mensajes al día y de repente ocho mil el último día del mes se ve, desde afuera, como una cuenta comprometida.
Direcciones de clientes malas o muertas. Los rebotes de direcciones viejas en el maestro de clientes dañan la reputación de un dominio que por lo demás se está portando bien.
Hosting compartido en el camino. Si alguna parte de la cadena todavía pasa por el correo de un hosting compartido, heredas la reputación de todos los demás que están en esa máquina.

Una lista corta para quien lleva la facturación

Un solo registro SPF, con todos los remitentes fusionados adentro, por debajo de diez consultas.
DKIM publicado y encendido para tu plataforma de correo, y aparte para el proveedor de facturación.
Un registro DMARC en p=none con un rua que funcione, leído a las dos semanas antes de endurecer nada.
Una factura de prueba al mes a una dirección de un proveedor distinto al tuyo, abierta y revisada.
La lista de remitentes externos escrita en algún lado, y revisada cuando cambies de proveedor.

Cómo ayuda Guanacos Tech

Somos una consultoría independiente con ingenieros certificados por Google, y la entregabilidad de correo es lo que más hacemos. Para una empresa que ya factura con DTE, el primer paso útil es un diagnóstico y no una reescritura: qué hay publicado hoy, qué remitentes están realmente alineados y en qué orden cambiar las cosas para que nada se detenga en día hábil. Nuestro diagnóstico de correo y el analizador DMARC son gratis y cubren casi todo eso en un minuto. Si prefieres delegarlo, mira cómo trabajamos o agenda una llamada corta y trae un correo de factura con sus encabezados.

Facturación electrónica (DTE) en El Salvador: por qué tus facturas llegan a spam y cómo autorizar a tu proveedor en SPF y DKIM