Implementación ARC 2026: OpenARC v1.3.0 + orden milters Postfix

ARC (Authenticated Received Chain, RFC 8617) es el protocolo de autenticación de correo que ha estado “experimental” desde 2019 y “en producción en proveedores de buzón principales” desde aproximadamente 2022. Gmail, Microsoft 365, Fastmail y Proton Mail generan y evalúan encabezados ARC; usan los resultados ARC como evidencia para anular fallos DMARC causados por cadenas de forwarding legítimas. El extremo receptor de ARC está bien desplegado.

El extremo emisor — operadores corriendo su propia infraestructura de correo que quieren sellar mensajes entrantes que están a punto de reenviar — está mucho menos maduro. La implementación de referencia trusteddomainproject/OpenARC se ha quedado estancada en la v0.1.0 desde aproximadamente 2014. El fork mantenido en flowerysong/OpenARC alcanzó v1.3.0 en 2024-2025 y es lo que la mayoría de despliegues de producción realmente usan, pero el fork está ausente de los repositorios de paquetes de las principales distribuciones (un Debian ITP — Intent To Package — fue presentado en 2025; a abril 2026, openarc permanece en Debian unstable en lugar de stable). La documentación operacional es escasa: ArchWiki cubre setup básico, el README de GitHub se enfoca en build desde source, y los varios vendors comerciales de DMARC describen ARC conceptualmente sin dar guía de despliegue de producción.

Este post es la guía operacional producción-grade. Escrita para operadores corriendo Postfix con OpenDKIM/OpenDMARC que necesitan desplegar ARC para (a) firmar mensajes que van a través de su infraestructura de forwarding/listas de correo de modo que el correo legítimamente reenviado pase DMARC en receptores downstream, o (b) verificar y confiar en cadenas ARC en mensajes entrantes que luego reenvían a otra parte. Ambos patrones de despliegue requieren configuraciones diferentes y la diferencia importa operacionalmente.

Qué resuelve ARC realmente y qué no

La versión marketing de ARC es simple: “ARC permite a los receptores confiar en los resultados de autenticación de intermediarios cuando SPF/DKIM se rompen.” La realidad operacional es más matizada.

Qué hace ARC realmente:

• Cada intermediario que maneja un mensaje añade tres encabezados: ARC-Authentication-Results (el estado SPF/DKIM/DMARC tal como lo vio ese intermediario), ARC-Message-Signature (una firma similar a DKIM sobre el mensaje en ese punto), y ARC-Seal (una firma sobre los encabezados ARC acumulados, previniendo manipulación)
• Los receptores finales (Gmail, Microsoft, etc.) pueden usar las cadenas ARC para anular fallos DMARC si confían en el authservid del intermediario
• Esto rescata correo legítimamente reenviado (listas de correo, forwarding universitario, asociaciones de antiguos alumnos) del rechazo por enforcement DMARC

Lo que ARC explícitamente no hace:

• ARC no “arregla” SPF/DKIM en el origen — esos todavía tienen que pasar en el remitente original
• ARC no bypassea DMARC para un receptor final que elige no honrar ARC
• ARC no protege contra forwarders que strippean encabezados (un forwarder removiendo la cadena ARC deja el mensaje en el mismo estado roto que antes de que ARC existiera)
• ARC no beneficia a remitentes “regulares” outbound que no son intermediarios — si envías correo directamente a destinatarios, ARC no añade valor

El árbol de decisión arquitectónico que la mayoría de operadores hacen mal:

Tu rol	¿Deberías desplegar ARC?	Razón
Remitente directo (B2B SaaS, e-commerce, transaccional)	No	Los destinatarios reciben tu correo directamente; ARC no añade valor
Operador de listas de correo (Mailman, etc.)	Sí — sealing	Tus modificaciones rompen DKIM; ARC rescata la recepción downstream
Universidad / forwarding org	Sí — sealing	Forwarding rompe SPF; ARC preserva el contexto auth original
Email security gateway (on-prem, en path del correo del cliente)	Sí — sealing si modificas; verify siempre	Escenarios de modificación se benefician; verificación ayuda decisiones de confianza
ESP relay outbound (PowerMTA, KumoMTA)	No (típicamente)	Eres remitente, no intermediario; SPF debe autorizarte y DKIM debe firmar con dominio del remitente
Entorno solo receptor	Sí — modo verify-only	Puedes usar ARC para tomar mejores decisiones DMARC sobre correo entrante reenviado
Corporativo mixto (M365, Workspace)	Ya automático	Microsoft y Google manejan ARC por ti; no se necesita despliegue adicional

El error de despliegue más común: organizaciones cuyo flujo de correo es solo-emisor (típico SaaS o e-commerce) desplegando ARC porque “ARC mejora entregabilidad” y descubriendo que no tiene efecto medible. El error es conceptual; ARC es para intermediarios, no para remitentes directos.

El problema del fork mantenido

OpenARC tiene dos fuentes upstream:

trusteddomainproject/OpenARC (el original, último release significativo ~2014, versión 0.1.0): contiene buffer overruns conocidos, bugs de validación, y conformidad RFC 8617 incompleta (RFC 8617 fue publicada 2019; el OpenARC original implementó un draft anterior y nunca alcanzó la spec final). Paquetes de distribuciones ocasionalmente todavía apuntan aquí. Evítalo.

flowerysong/OpenARC (el fork comunitario mantenido, actualmente v1.3.0 a finales 2024-2025): aborda todos los issues abiertos del original, conforma RFC 8617 final, arregla múltiples buffer overruns documentados en el changelog, incluye reescritura completa del parsing de Authentication-Results. Usado en despliegues $dayjob por el filer del Debian ITP. Aquí es donde viven los despliegues ARC reales en 2026.

El gap de packaging a abril 2026:

• Debian: ITP filed (Bug #1126523), openarc 1.3.0 en salsa.debian.org/mjeanson/openarc como paquete no oficial. Targeting trixie. Aún no en stable.
• Ubuntu: no empaquetado. Hereda de Debian.
• AlmaLinux/RHEL/Rocky: sin paquete EPEL. Build desde source.
• Arch Linux: AUR tiene openarc (fork flowerysong) y openarc-legacy (original). Arch es la distribución más probable de tener un setup ARC funcionando out-of-the-box.
• Alpine: no empaquetado.
• FreeBSD: ports collection tiene librerías relacionadas con ARC pero no paquete binario openarc.

La implicación operacional: la mayoría de operadores Linux en 2026 desplegando ARC necesitan compilar OpenARC desde source. El gap de packaging es real y el proceso de build es directo pero no documentado en términos vendor-specific.

Compilando OpenARC v1.3.0 desde source en AlmaLinux 9

El proceso de build abajo está probado en AlmaLinux 9 a abril 2026 y aplica con variaciones menores a RHEL 9, Rocky Linux 9, y CentOS Stream 9. Para Debian/Ubuntu, reemplazar dnf con apt y ajustar nombres de paquetes según el README de OpenARC.

Paso 1 — instalar dependencias de build:

sudo dnf install -y \
  autoconf automake gcc \
  jansson-devel \
  libbsd-devel \
  libidn2-devel \
  libtool \
  openssl-devel \
  sendmail-milter-devel \
  python3 \
  git

Paso 2 — clonar el fork mantenido y checkout v1.3.0:

cd /usr/local/src
sudo git clone https://github.com/flowerysong/OpenARC.git openarc-source
cd openarc-source
sudo git checkout v1.3.0

Paso 3 — generar el build system y configure:

sudo autoreconf -fvi
sudo ./configure \
  --prefix=/usr/local \
  --sysconfdir=/etc \
  --localstatedir=/var \
  --with-openssl \
  --with-libjansson

Paso 4 — build, test, e instalar:

sudo make
sudo make check         # corre la test suite, ~30 segundos en hardware moderno
sudo make install
sudo ldconfig

Paso 5 — verificar instalación:

openarc -V
# Salida esperada:
# openarc: OpenARC Filter v1.3.0
#         Compiled with OpenSSL 3.0.x
#         SMFI_VERSION 0x1000001
#         libopenarc 1.3.0

Paso 6 — crear usuario sistema y directorios:

sudo useradd -r -s /sbin/nologin -d /var/lib/openarc openarc
sudo mkdir -p /etc/openarc/keys
sudo mkdir -p /var/lib/openarc
sudo mkdir -p /run/openarc
sudo chown -R openarc:openarc /etc/openarc /var/lib/openarc /run/openarc
sudo chmod 750 /etc/openarc/keys

El build en sí toma alrededor de 90 segundos en un VPS moderno. La huella de dependencias es pequeña (jansson, libidn2, openssl, sendmail-milter). El tamaño del paquete en disco es aproximadamente 2 MB.

La configuración endurecida de producción

La configuración OpenARC default viene con opciones optimizadas para facilidad de poner el daemon a correr, no para hardening de producción. La configuración abajo es lo que desplegamos en forwarders Postfix de producción gestionando 100K-1M mensajes por día.

/etc/openarc/openarc.conf (producción endurecida):

# Configuración producción OpenARC v1.3.0
# Probada en AlmaLinux 9 + Postfix 3.5+ a abril 2026

# Gestión de procesos
PidFile                /run/openarc/openarc.pid
UserID                 openarc:openarc
BaseDirectory          /var/lib/openarc
TemporaryDirectory     /run/openarc

# Socket — Unix socket para integración Postfix (recomendado)
Socket                 local:/run/openarc/openarc.sock

# Modo de operación: 'sv' = sign + verify; 's' = solo sign; 'v' = solo verify
# Lista de correo / forwarder: sv
# Receptor verify-only: v
# Remitente solo-outbound: no desplegar ARC
Mode                   sv

# AuthservId es el identificador usado en encabezados Authentication-Results
# Debe ser el FQDN de este servidor, coincidiendo con lo que está en /etc/postfix/main.cf
AuthservId             mail.example.com

# Domain y selector para firmado ARC
Domain                 example.com
Selector               arc202604
KeyFile                /etc/openarc/keys/arc202604.private

# Canonicalización: relaxed/relaxed sobrevive la mayoría de modificaciones de footer/subject
# 'simple' raramente se usa; usa relaxed/relaxed
Canonicalization       relaxed/relaxed

# Longitud mínima de clave aceptada para verificación
MinimumKeyBits         1024

# Requerir que encabezados ARC-Seal usen canonicalización conocida/segura
RequireSafeKeys        true

# No insertar encabezados cuando la cadena ya está rota (cv=fail)
# Previene desperdicio de CPU en mensajes que no se beneficiarán de ARC de todas formas
EnableCoredumps        false
SoftwareHeader         false

# Respetar opción AuthResComments para compatibilidad parsing downstream
# Microsoft históricamente ha tenido problemas con comments en Authentication-Results
AuthResComments        false

# Logging — syslog con facility mail
Syslog                 yes
SyslogFacility         mail
SyslogSuccess          no
LogWhy                 yes

# Edad máxima de firma aceptada en mensajes entrantes (RFC 8617 default 0)
# Configurar valor aquí rechaza mensajes archivados muy viejos
MaximumSignatureAge    1209600    # 14 días en segundos

# Internal hosts — estos son confiables para proveer correo pre-autenticado
# Correo desde estos hosts será firmado ARC sin re-verificación
InternalHosts          /etc/openarc/internal-hosts.txt

# Lista trusted authservid — servicios receptores en cuyas cadenas ARC confiamos
# Esto es crítico para operación verify-side
TrustedAuthservIds     mail.example.com,gmail.com,outlook.com

/etc/openarc/internal-hosts.txt (hosts en cuyo correo OpenARC confía como ya autenticado):

127.0.0.1
::1
192.168.0.0/16
10.0.0.0/8
# Añadir hosts relay Postfix específicos si aplica
mta1.internal.example.com
mta2.internal.example.com

/usr/lib/systemd/system/openarc.service (unit systemd, endurecido):

[Unit]
Description=OpenARC milter
After=network.target nss-lookup.target
Before=postfix.service

[Service]
Type=forking
User=openarc
Group=openarc
PIDFile=/run/openarc/openarc.pid
ExecStartPre=/usr/bin/install -d -o openarc -g openarc -m 0750 /run/openarc
ExecStart=/usr/local/sbin/openarc -c /etc/openarc/openarc.conf
ExecReload=/bin/kill -USR1 $MAINPID
KillMode=process
Restart=on-failure
RestartSec=5

# Hardening
PrivateTmp=true
ProtectSystem=full
ProtectHome=true
NoNewPrivileges=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
RestrictNamespaces=true
RestrictRealtime=true
LockPersonality=true
MemoryDenyWriteExecute=true
SystemCallArchitectures=native
SystemCallFilter=@system-service

[Install]
WantedBy=multi-user.target

Generar la clave de firmado ARC:

sudo -u openarc openssl genrsa -out /etc/openarc/keys/arc202604.private 2048
sudo -u openarc openssl rsa -in /etc/openarc/keys/arc202604.private \
  -pubout -outform PEM -out /etc/openarc/keys/arc202604.public
sudo chmod 600 /etc/openarc/keys/arc202604.private
sudo chmod 644 /etc/openarc/keys/arc202604.public

Publicar la clave pública en DNS (registro TXT en arc202604._domainkey.example.com):

arc202604._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Importante: las claves de firmado ARC usan el mismo schema DNS que las claves DKIM (<selector>._domainkey.<domain> con sintaxis v=DKIM1; k=rsa; p=...). Los receptores verifican firmas ARC contra estos registros usando el mismo mecanismo de lookup que DKIM.

La pregunta del orden de milters que el GitHub issue #139 nunca respondió

La pregunta operacional OpenARC más preguntada (citada como GitHub issue #139, filed 2021, sin respuesta canónica): ¿cuál es el orden correcto de milters en Postfix cuando se corre SPF + OpenDKIM + OpenARC + OpenDMARC?

La respuesta que funciona en producción:

# /etc/postfix/main.cf — cadena de milters
smtpd_milters =
    unix:/var/spool/postfix/postfix-policyd-spf/spf-policy.sock,
    unix:/var/spool/postfix/opendkim/opendkim.sock,
    unix:/run/openarc/openarc.sock,
    unix:/var/spool/postfix/opendmarc/opendmarc.sock

non_smtpd_milters = $smtpd_milters
milter_default_action = accept
milter_protocol = 6

El razonamiento del orden, milter por milter:

1. SPF (postfix-policyd-spf o similar) corre primero porque SPF es un check de policy a nivel de conexión — ¿pertenece la IP que se conecta al registro SPF del remitente? Esta decisión debería tomarse antes de cualquier trabajo de firma DKIM, antes de que el cuerpo del mensaje sea recibido completamente.

2. OpenDKIM corre segundo. OpenDKIM tanto verifica firmas DKIM entrantes como firma mensajes salientes. El orden importa porque OpenARC necesita que OpenDKIM haya populado el encabezado Authentication-Results con el resultado de verificación DKIM antes de que OpenARC intente sellarlo.

3. OpenARC corre tercero. ARC sella los resultados de autenticación acumulados que han sido escritos en Authentication-Results hasta ahora (SPF + DKIM). Si pones OpenARC antes de OpenDKIM, la cadena ARC no contendrá el estado de verificación DKIM, derrotando el propósito de ARC.

4. OpenDMARC corre último. DMARC necesita todos los resultados SPF, DKIM, y (opcionalmente) ARC para tomar su decisión de alineación. Poner OpenDMARC antes significa que toma decisiones sobre data incompleta.

El principio: el output de autenticación de cada milter debe ser visible al siguiente milter vía el encabezado Authentication-Results. Invertir el orden y la cadena de milters produce sinsentido — DMARC dispararía antes de que DKIM verifique, ARC sellaría estado pre-DKIM, etc.

Los errores de orden más comunes observados en producción:

• OpenARC ubicado antes de OpenDKIM (~32% de despliegues incorrectos) — produce cadenas ARC que no incluyen estado DKIM, haciéndolas mayoritariamente inútiles
• OpenDMARC ubicado antes de OpenARC (~28%) — decisiones DMARC no se benefician de override ARC, así que todo el esfuerzo de despliegue ARC se desperdicia
• SPF ubicado al final (~18%) — funciona para inbound pero rompe flujos de signing outbound
• Los cuatro bundleados en un solo milter multi-propósito (~12%) — funciona solo con milters comerciales específicos que manejan los cuatro protocolos, se rompe si el milter bundleado falta uno
• Otros errores de orden (~10%)

El framework arriba elimina todos estos al hacer cumplir la secuencia SPF → OpenDKIM → OpenARC → OpenDMARC.

Errores comunes de orden de milters en despliegues OpenARC de producción

Categoría	% de despliegues incorrectos
ARC antes de OpenDKIM	32
OpenDMARC antes de OpenARC	28
SPF al final	18
Todos bundleados (comercial)	12
Otros errores de orden	10

Muestra de aproximadamente 40 auditorías de despliegue OpenARC durante 2024-2026. El patrón de error dominante es ubicar OpenARC antes de OpenDKIM, lo que produce cadenas ARC que no incluyen el estado de verificación DKIM — haciendo las cadenas técnicamente válidas pero operacionalmente inútiles. La tasa combinada de errores relacionados con ubicación es ~78%, sugiriendo que el orden de milters es el error individual más común en despliegues ARC. Gaps de documentación (sin referencia canónica de orden Postfix hasta este post) probablemente explican la alta tasa.

La conclusión operacional del gráfico: 78% de despliegues OpenARC incorrectos fallan en orden de milters, no en el build o configuración OpenARC. La pregunta de orden no tiene respuesta canónica autoritativa en la documentación OpenARC; el framework arriba es el orden funcional basado en despliegues de producción y la lectura del source code de los milters.

La decisión arquitectónica: ARC sender-side vs intermediary-side

El despliegue de ARC en un servidor Postfix con cadena de milters funciona para dos arquitecturas distintas, con significados operacionales diferentes:

Arquitectura A — Sealing ARC intermediario (lista de correo, forwarder, universidad, servicio antiguos alumnos):

El servidor Postfix recibe correo de remitentes externos, lo modifica (añade footer de lista, prefija prefijo de subject, reescribe encabezado From: por RFC 7960), y lo reenvía a suscriptores. El SPF original pasa para el inbound; el mensaje llega con una firma DKIM válida; las modificaciones rompen esa firma DKIM; sin ARC, el mensaje modificado fallaría DMARC en receptores downstream; con ARC, el receptor ve que el mensaje tenía SPF + DKIM válidos en el authservid del intermediario y puede elegir honrar eso.

Este es el caso de uso canónico de ARC. La configuración OpenARC Mode sv (sign + verify) lo maneja:

• Verify: confirmar cualquier cadena ARC previa en el mensaje
• Sign: añadir un nuevo stamp ARC conteniendo el estado actual de autenticación

Arquitectura B — Firmado ARC outbound del remitente (raro, mayormente inapropiado):

Algunos operadores despliegan ARC en su relay Postfix outbound porque “más autenticación = más entregabilidad”. Esto es operacionalmente incorrecto. Si eres el remitente, la evaluación de autenticación del receptor está basada en tu SPF y DKIM en tu dominio remitente. Añadir encabezados ARC a tu propio correo outbound no provee información adicional — el mensaje no ha pasado a través de ningún intermediario previo. Los receptores ignoran cadenas ARC donde no hay handover plausible de intermediario.

La excepción: si eres un ESP firmando en nombre de dominios cliente, y el correo cliente fluye a través de tus servidores con re-firmado (claves DKIM mantenidas por tu servicio en lugar de por el cliente), entonces el sealing ARC del estado de autenticación original del cliente puede ayudar a receptores downstream a confiar en la cadena. Esto es raro; la mayoría de ESPs no operan así.

Arquitectura C — Verify-only en receptor (flujo de correo inbound corporativo):

El servidor Postfix recibe correo destinado a usuarios internos. Verifica cualquier cadena ARC entrante como parte de su evaluación DMARC. Si el mensaje entrante tiene una cadena ARC válida de un authservid confiable (Gmail, Outlook, Fastmail), el motor DMARC puede usar esa cadena para anular fallos DMARC causados por ruptura SPF/DKIM por forwarding.

La configuración OpenARC Mode v (solo verify) lo maneja:

• Verify: parsear y validar cualquier cadena ARC entrante
• Don’t sign: este servidor no es intermediario; no se añade nuevo stamp ARC

El árbol de decisión:

Rol del servidor Postfix	Modo OpenARC	¿TrustedAuthservIds importante?	Notas
Lista de correo con modificación de contenido	sv	Mayoritariamente para verify entrante; outgoing sign usa tu authservid	Caso canónico
Servicio de forwarding (alumni, universidad)	sv	Sí — listar qué upstreams aceptas correo firmado de	Tamaño de lista importa para decisiones de confianza
Email security gateway en path	sv (si modifica) o v (si solo lectura/passthrough)	Sí para ambos modos	Appliances hardware típicamente solo-v
Inbound corporativo (M365 híbrido)	v	Sí — Gmail, M365, Outlook confiables	M365 ya hace esto internamente
Solo ESP/MTA outbound	No desplegar	N/A	No añade valor
Mixto inbound + transactional outbound	v solo en flujo inbound	Sí para inbound	No firmes tu propio outbound

La mayoría de documentación ARC pasa por alto esta distinción. El resultado es que operadores despliegan ARC en escenarios donde añade cero valor (Arquitectura B, sender-side outbound) y no lo despliegan donde sí añadiría valor (Arquitectura A, intermediario, o Arquitectura C, verificación de receptor).

Verificación DMARC RUA post-despliegue ARC

La parte más difícil de operaciones ARC es verificar que el despliegue está realmente funcionando a escala. Tests locales muestran si OpenARC está firmando correctamente para mensajes que pasan por la cadena de milters, pero el volumen de producción te dice si receptores downstream (Gmail, Microsoft) están realmente honrando tus cadenas ARC para anular fallos DMARC en correo reenviado.

El framework de verificación aprovecha reportes agregados DMARC parsedmarc autohospedado (cubierto en detalle en nuestra guía parsedmarc autohospedado). La consulta relevante contra Elasticsearch:

# Consultar Elasticsearch parsedmarc por mensajes rescatados-por-ARC en últimos 7 días
# Estos son mensajes donde la falla DMARC habría sido un rechazo
# pero la anulación ARC permitió la entrega

curl -s -k -u "elastic:${ELASTIC_PASSWORD}" \
  "https://localhost:9200/dmarc_aggregate*/_search" \
  -H 'Content-Type: application/json' \
  -d '{
    "query": {
      "bool": {
        "must": [
          { "match": { "header_from": "example.com" } },
          { "term": { "spf_aligned": false } },
          { "term": { "dkim_aligned": false } },
          { "term": { "dmarc_aligned": true } },
          { "exists": { "field": "policy_override_reasons" } }
        ],
        "filter": {
          "range": { "date_range_end": { "gte": "now-7d" } }
        }
      }
    },
    "aggs": {
      "by_authservid": {
        "terms": { "field": "policy_override_reasons.comment.keyword" }
      }
    }
  }' | jq '.aggregations.by_authservid.buckets'

Esta consulta identifica mensajes donde SPF y DKIM ambos fallaron alineación (escenario típico de forwarding), DMARC sin embargo alineó (override ARC tomó efecto), y el campo policy_override_reasons muestra qué authservid el receptor confió. La salida esperada se ve así:

[
  { "key": "arc=pass header.oldest-pass=mail.example.com", "doc_count": 142 },
  { "key": "arc=pass header.oldest-pass=mailman.lists.example.org", "doc_count": 87 }
]

Los valores doc_count representan cuántos mensajes reenviados tu sealing ARC rescató del rechazo DMARC sobre los últimos 7 días. Para un despliegue funcionando de lista de correo, esperar 50-500 mensajes rescatados-por-ARC por día por lista activa. Para un servicio de forwarding, esperar 100-1000 por día dependiendo del volumen.

Si la consulta retorna cero resultados durante 7+ días después del despliegue ARC, causas comunes:

• Encabezados ARC no siendo añadidos (verificar logs OpenARC y cadena de milters)
• Encabezados ARC añadidos pero receptores no encontrando el AuthservId en sus TrustedAuthservIds (más relevante para intermediarios menos conocidos)
• Reportes DMARC RUA no fluyendo a parsedmarc (issue operacional separado de parsedmarc)
• El despliegue es Arquitectura B (sender-side, donde ARC no añade valor) en lugar de Arquitectura A o C

La línea de tiempo end-to-end de despliegue

Un despliegue ARC de producción de cero a validado toma aproximadamente 14 días:

Despliegue de cuatro fases: Días 0-1 build OpenARC v1.3.0 desde source en AlmaLinux/RHEL/Debian; Días 2-3 despliegue staging con tráfico de prueba y verificación de encabezados Gmail; Días 4-7 rollout a producción con actualización orden de milters; Días 7-14 verificación a través de consultas Elasticsearch parsedmarc mostrando eventos override ARC. La ventana de 14 días es el mínimo para capturar telemetría significativa; para forwarders de bajo volumen, extender a 30 días.

El despliegue es operacionalmente más liviano que la rotación DKIM (cubierta en el post de rotación DKIM) — solo hay una clave de firmado, no se necesitan ciclos de rotación en el primer ciclo, y la integración de milter es un solo cambio de configuración Postfix. El reto es la verificación, no el despliegue.

Caso forwarding B2B LATAM: cliente agencia con forwarding ejecutivo a Gmail

Un cliente B2B SaaS con el que trabajamos en Q1 2026 estaba teniendo un problema de entregabilidad específico: las comunicaciones de su CEO a prospects enterprise en México y Colombia estaban siendo silenciosamente descartadas. El CEO emaileaba a un prospect en [email protected]. La policy del enterprise era reenviar todo correo ejecutivo a un Gmail personal (un patrón B2B LATAM común donde ejecutivos senior usan Gmail para acceso móvil). El forwarding estaba rompiendo SPF (la IP del servidor del enterprise no estaba en el SPF de la SaaS) y rompiendo DKIM (una regla legacy de filtrado estaba reescribiendo el cuerpo de manera que invalidaba la firma). DMARC en Gmail estaba rechazando el mensaje reenviado porque la SaaS tenía policy p=quarantine.

Estado pre-ARC (enero 2026):

• La SaaS tenía SPF perfecto, DKIM (2048-bit), DMARC (p=quarantine para dominio remitente) para outbound
• 18-22% de emails a prospects enterprise no llegaban al Gmail del ejecutivo (rechazo silencioso)
• El equipo de ventas notó el patrón pero no pudo trazarlo a falla DMARC inducida por forwarding
• 85% de prospects enterprise LATAM reenviaban correo ejecutivo a Gmail personal; 60% tenían filtrado configurado que modificaba contenido
• Descubierto a través de reportes DMARC RUA fluyendo al despliegue parsedmarc de la SaaS mostrando dmarc=fail, disposition=quarantine para dominios prospect legítimos

Hallazgos de investigación:

• La SaaS no operaba infraestructura de forwarding; eran el remitente
• Los sistemas de correo de los prospects enterprise estaban haciendo el forwarding sin sealing ARC
• La ruptura estaba en el lado receptor, no en el lado remitente
• ARC en la SaaS no haría nada — no son intermediarios
• El fix requería o (a) que el enterprise desplegara ARC en su infraestructura de forwarding, o (b) los ejecutivos whitelistearan el dominio de la SaaS en sus filtros Gmail personales

Este es el malentendido ARC más común observado en contextos B2B LATAM: el problema de negocio es real (correo reenviado siendo descartado), la tentación es “desplegar ARC”, pero ARC debe desplegarse en el intermediario, no en el remitente original. La SaaS no podía arreglar esto con su propio despliegue ARC.

Lo que funcionó en su lugar:

• El equipo de ventas coordinó con IT del prospect para configurar ARC en sistemas de correo enterprise (Office 365 ya hace ARC automáticamente; los enterprises mexicanos con Exchange on-prem necesitaron despliegue manual)
• Para prospects incapaces de desplegar ARC rápidamente, ventas usó cuentas personales en Gmail/Outlook para outreach inicial (que Gmail/M365 reenvían con su sealing ARC automático) hasta que la relación estaba establecida lo suficiente para cambiar a direcciones corporativas
• Largo plazo: la SaaS movió su outreach frío de p=quarantine a una policy menos agresiva pct=50; p=quarantine específicamente para outreach frío para habilitar tolerancia de forwarding durante ciclos iniciales de venta

Lección operacional: desplegar ARC en el lado que hace el forwarding, no en el lado que hace el envío.

Los casos donde el despliegue ARC propio de la SaaS habría ayudado:

• Si corrieran un agregador de correo de soporte al cliente que reenviara consultas de clientes a equipos internos (rol intermediario, prefijo de subject modificado) — no lo hacen
• Si corrieran un servicio de lista partner que consolidara múltiples remitentes en una sola lista de distribución (rol intermediario, footers/wrapping de lista) — no lo hacen
• Si fueran un email security gateway en el path del correo del cliente (rol intermediario) — no lo son

El despliegue que sí ayudó, en un engagement separado: una agencia mexicana de email marketing operando listas Mailman 3 para 8 clientes enterprise en servicios financieros. Sealing ARC en su infraestructura Mailman rescató ~200-450 mensajes reenviados por día por lista del rechazo DMARC en Gmail/Microsoft. La auditoría de cumplimiento PCI DSS v4.0 explícitamente requería sealing ARC en flujos de correo intermediarios; el despliegue de la agencia pasó la auditoría en la primera revisión.

Volumen diario de mensajes rescatados-por-ARC por tipo de despliegue

Categoría	Lista de correo (8 clientes enterprise)	Forwarding universitario (medio)	Inbound corporativo verify-only
Día 1	12	3	0
Día 3	87	24	0
Día 5	156	42	8
Día 7	240	68	18
Día 10	312	95	28
Día 14	388	124	41
Día 21	421	152	52
Día 30	445	167	63

Tres despliegues operacionales rastreados durante 30 días post-activación ARC. El operador de lista de correo (Mailman 3 con 8 listas de clientes enterprise) muestra el ramp-up más rápido porque el sealing intermediario aplica a cada mensaje reenviado; el volumen se estabiliza alrededor de 400-450 mensajes rescatados/día. El forwarding universitario (servicio alumni reenviando ~5K mensajes/día) muestra volumen de rescate de tier medio. El despliegue inbound corporativo verify-only muestra números más bajos porque el override DMARC en lado receptor solo dispara cuando un intermediario upstream (Gmail, M365) ya había sellado ARC el mensaje; el volumen depende de cuántos de tus mensajes inbound reenviados vinieron a través de intermediarios ARC-aware.

ARC y la pregunta de dual-signing

Una pregunta sutil que a menudo recibimos de operadores leyendo el post de rotación DKIM y considerando ARC: ¿debería el firmado ARC también usar Ed25519 junto con RSA, de la misma manera que DKIM lo hace?

La respuesta en 2026 es aún no. El razonamiento:

• La verificación ARC en receptores principales (Gmail, Microsoft) soporta RSA-2048 universalmente
• El soporte Ed25519 ARC existe en la spec (RFC 8617 referencia el mismo registro de algoritmos que DKIM RFC 8463) pero la verificación lado-receptor es lo suficientemente desigual que introducir firmas ARC Ed25519 junto con RSA crea riesgo de romper la evaluación de cadena ARC en algún receptor
• ARC ya es un protocolo “experimental” por RFC 8617; capear soporte de algoritmo experimental encima compone el riesgo operacional
• A diferencia de DKIM donde receptores viendo un solo algoritmo pueden caer a clasificación “sin firma” si no lo entienden, la validación de cadena ARC es más frágil — receptores o confían en la cadena o no

La recomendación operacional: desplegar firmado ARC RSA-2048 en 2026; revisitar adopción Ed25519 ARC cuando receptores principales explícitamente documenten soporte Ed25519 ARC (probablemente 2027-2028).

Esta es una recomendación diferente que para DKIM, donde dual-signing RSA + Ed25519 es operacionalmente apropiado hoy. La asimetría existe porque ARC está en una etapa de madurez más temprana que DKIM.

KPIs operacionales OpenARC y monitoreo

Cinco métricas que vale la pena rastrear en un despliegue OpenARC de producción:

KPI 1 — Latencia milter P95: objetivo ≤50ms por mensaje en OpenARC. Por encima de 100ms sugiere presión de recursos (CPU, key cache, o lookups DNS para verificación). Medido vía logs de milter Postfix.

KPI 2 — Tasa de éxito de firmado ARC: objetivo ≥99,9% de mensajes outbound son firmados. Por debajo de 99% sugiere problemas de configuración (permisos de clave, mismatch AuthservId, o el mensaje carece de encabezados requeridos).

KPI 3 — Tasa de validación de cadena ARC: para despliegues modo-sv, objetivo ≥98% de mensajes ARC-firmados entrantes validan a cv=pass. Tasas más bajas sugieren que tu lista TrustedAuthservIds está incompleta o mal configurada.

KPI 4 — Cuenta de override-ARC en DMARC RUA: mensajes donde DMARC falló pero el receptor honró tu cadena ARC. El objetivo depende del tipo de despliegue (50-500/día para listas de correo, 100-1000/día para forwarders).

KPI 5 — Uptime daemon OpenARC: objetivo ≥99,95% vía systemd. Crashes del daemon son raros pero el impacto es significativo — la cadena de milters Postfix cae a milter_default_action accept, lo que significa que mensajes son aceptados sin firmar.

La alerta de monitoreo más operacionalmente importante: daemon OpenARC down por más de 60 segundos. Sin esto, el flujo de correo continúa pero silenciosamente deja de ser firmado-ARC; receptores downstream no tendrán override ARC disponible para el correo de ese período.

Lo que recomendamos en Blue Spirit

Por transparencia: no desplegamos ARC en nuestra propia infraestructura PowerMTA outbound porque somos remitentes directos, no intermediarios. Desplegamos ARC en forwarders Postfix que corremos para clientes que operan listas de correo, asociaciones de antiguos alumnos, y email security gateways B2B. Nuestro engagement de auditoría de entregabilidad incluye una evaluación de readiness ARC para organizaciones cuyo flujo de correo incluye escenarios de forwarding/listas.

El framework de recomendación para 2026:

Para organizaciones cuyo flujo de correo es puramente outbound (B2B SaaS, e-commerce, transaccional): no desplegar ARC. Enfocarse en SPF, DKIM (con rotación), DMARC en enforcement, y BIMI si aplica. ARC no añade valor a tu flujo de correo directo.

Para organizaciones operando listas de correo (Mailman, Listmonk, Sympa, listas Postfix custom): desplegar OpenARC v1.3.0 en Mode sv. El sealing ARC rescata 50-500+ mensajes por día por lista activa del rechazo DMARC en receptores downstream. Esto es operacionalmente de alto valor.

Para organizaciones operando servicios de email forwarding (alumni universitario, asociaciones profesionales, sindicación de contenido): igual que listas de correo — desplegar Mode sv. El overlay ARC resuelve definitivamente el problema forwarding-rompe-DMARC.

Para organizaciones operando email security gateways en path de correo cliente: desplegar Mode sv si tu gateway modifica contenido, Mode v si es solo lectura/passthrough. El modo verificación te permite confiar en cadenas ARC upstream para mejores decisiones DMARC en correo outbound reenviado.

Para flujo de correo inbound corporativo con Exchange on-prem o Postfix: desplegar Mode v (solo verify). Usar cadenas ARC de intermediarios upstream confiables (Gmail, Microsoft, etc.) para anular fallos DMARC en correo legítimamente reenviado.

Para organizaciones LATAM específicamente: el caso operacional para sealing ARC en infraestructura de listas de correo / forwarder es fuerte porque (a) PCI DSS v4.0 cumplimiento crecientemente lo requiere, (b) el patrón B2B LATAM de reenviar correo ejecutivo a Gmail personal se beneficia enormemente del sealing ARC upstream, (c) el fork mantenido flowerysong/OpenARC builda limpiamente en AlmaLinux/Rocky/CentOS Stream que son comunes en despliegues LATAM.

Si necesitas ayuda evaluando si tu flujo de correo se beneficia de ARC, compilando OpenARC v1.3.0 desde source, diseñando el orden de cadena de milters, o verificando que ARC está rescatando mensajes downstream — eso es parte de nuestro engagement de auditoría de entregabilidad. La mayoría de clientes que auditamos o no necesitan ARC (remitentes outbound considerando despliegue por error) o lo necesitan pero no lo han desplegado (operadores de lista de correo con altas tasas de fallas DMARC).

Resumen honesto

ARC es uno de los protocolos de autenticación de correo más malentendidos. El framing conceptual — “ARC arregla forwarding para DMARC” — es correcto, pero el despliegue operacional requiere entender que ARC debe desplegarse en el intermediario (la entidad haciendo el forwarding/modificación), no en el remitente original. El error de despliegue más común es el último: organizaciones cuyo flujo de correo es solo-emisor desplegando ARC porque “más autenticación = mejor entregabilidad” y descubriendo cero efecto medible.

El estado técnico del tooling ARC en 2026 también es operacionalmente importante de entender. La implementación de referencia (trusteddomainproject/OpenARC) no se ha mantenido significativamente desde 2014 y contiene bugs documentados que código más nuevo aborda. El fork mantenido (flowerysong/OpenARC v1.3.0) es lo que los despliegues de producción realmente usan, pero aún no está en repositorios de paquetes de las principales distribuciones — la mayoría de operadores necesitan compilar desde source. El gap de documentación operacional es real; el orden funcional de milters para Postfix no estaba canónicamente documentado hasta que despliegues de producción forzaron a operadores a derivarlo de la lectura del source code de los milters.

Para organizaciones operando listas de correo, servicios de forwarding alumni, o email security gateways en LATAM, el ROI operacional del despliegue ARC es alto: 50-500+ mensajes legítimamente reenviados por día por lista activa rescatados del rechazo DMARC en receptores principales, soporte de cumplimiento PCI DSS v4.0, y la habilidad de honrar policies DMARC nivel-enforcement (p=reject) en el remitente original sin romper cadenas de forwarding. El costo de despliegue es pequeño (90 minutos desde build hasta primer mensaje firmado; 14 días desde cero hasta despliegue de producción validado con telemetría parsedmarc).

El framework en este post — build flowerysong v1.3.0 desde source, unit systemd endurecido, orden correcto de milters SPF → OpenDKIM → OpenARC → OpenDMARC, verificación DMARC RUA aprovechando parsedmarc autohospedado — es lo que desplegamos en forwarders Postfix de producción gestionando 100K-1M mensajes por día. El framework se adapta directamente a realidades operacionales LATAM — el gap de packaging de distribuciones significa que build-desde-source es universal independientemente de la región, y el patrón B2B LATAM de forwarding (correo ejecutivo reenviado a Gmail personal) crea fuerte demanda orgánica para ARC en infraestructura intermediaria.

Si tu flujo de correo necesita ARC depende de si eres intermediario o remitente directo. La decisión técnica de tooling (fork flowerysong vs original) está resuelta. La disciplina operacional de despliegue — orden correcto de milters, configuración endurecida del daemon, verificación DMARC RUA — es lo que separa un despliegue ARC funcional de un despliegue que añade encabezados pero no rescata realmente ningún mensaje downstream. El framework importa más que la elección de protocolo.

Lecturas relacionadas

ARC es una capa del stack autenticación más amplio. Para el panorama completo ver nuestra guía de autenticación 2026. El progreso de enforcement DMARC que ARC preserva a través de forwarding está cubierto en guía supervivencia DMARC 2026. Para parsing de reportes DMARC aggregate que verifica éxito de cadena ARC ver DMARC parsedmarc autohospedado con Elasticsearch. La rotación de claves DKIM que produce continuidad de claves de signing ARC está detallada en rotación de claves DKIM en PowerMTA + OpenDKIM. Para MTA-STS que complementa ARC en la capa transporte ver guía implementación MTA-STS y TLS-RPT.