# SPF, DKIM y DMARC explicados: configuración y alineación

> Qué hace SPF, DKIM y DMARC, cómo configurarlos paso a paso en tu DNS y por qué la alineación con el dominio del From decide si tu correo pasa o no.

Source: https://pidgely.com/es/blog/spf-dkim-dmarc-explicados/ · Published: 2026-10-12 · Pidgely

SPF, DKIM y DMARC son tres registros DNS que permiten a los proveedores de correo verificar que un mensaje realmente viene de tu dominio. **SPF** autoriza qué servidores pueden enviar en nombre del dominio del sobre, **DKIM** firma criptográficamente el mensaje y **DMARC** exige que al menos uno de los dos pase *alineado* con el dominio visible en el From, y le dice al receptor qué hacer si no ocurre. Sin los tres bien configurados, Gmail, Yahoo y Outlook tratarán tu correo con desconfianza o directamente lo rechazarán.

## Por qué hacen falta los tres

El protocolo SMTP no verifica quién envía. Cualquiera puede conectarse a un servidor y escribir `From: facturacion@example.com`. Cada mecanismo cubre una parte del problema:

| Mecanismo | Qué verifica | Dónde vive | Especificación |
|---|---|---|---|
| SPF | La IP de envío está autorizada para el dominio del MAIL FROM (Return-Path) | TXT en el dominio del sobre | RFC 7208 |
| DKIM | El contenido y ciertos headers no se alteraron y fueron firmados por el dominio `d=` | TXT en `selector._domainkey.dominio` | RFC 6376 |
| DMARC | SPF o DKIM pasan **y** están alineados con el From visible | TXT en `_dmarc.dominio` | RFC 7489 |

El punto clave: SPF y DKIM por sí solos no protegen el From que ve el usuario. Un atacante puede pasar SPF con su propio dominio en el sobre y poner tu dominio en el From. DMARC cierra esa brecha con la alineación.

## Paso 1: configurar SPF

SPF se evalúa contra el dominio del comando `MAIL FROM` (el que acaba en el header `Return-Path`), no contra el From visible. Un registro típico:

```dns
bounces.example.com.  IN TXT  "v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 -all"
```

O, si usas además un proveedor externo:

```dns
example.com.  IN TXT  "v=spf1 include:_spf.proveedor.example ip4:203.0.113.10 ~all"
```

Reglas que conviene respetar:

- **Un solo registro `v=spf1` por nombre.** Dos registros producen `permerror`.
- **Máximo 10 consultas DNS** (mecanismos `include`, `a`, `mx`, `ptr`, `exists` y el modificador `redirect`). Superarlo también da `permerror`. Cada `include` anidado cuenta.
- **`-all` vs `~all`:** `-all` (fail) es más estricto; `~all` (softfail) es común mientras auditas tus fuentes. Con DMARC en vigor, la diferencia práctica es menor porque DMARC decide la política.
- **Evita `ptr`**: RFC 7208 lo desaconseja por lento y poco fiable.

### El subdominio de return-path

Una práctica muy recomendable es usar un subdominio dedicado para el sobre, por ejemplo `bounces.example.com`. Así el registro SPF de ese subdominio solo lista tus servidores de envío, los rebotes llegan a una infraestructura que los procesa y, con alineación relajada, `bounces.example.com` sigue alineado con `example.com` en el From.

## Paso 2: configurar DKIM

DKIM añade un header `DKIM-Signature` con una firma calculada sobre el cuerpo y una lista de headers. El receptor obtiene la clave pública del DNS usando el selector (`s=`) y el dominio (`d=`):

```text
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
 s=pg2026; t=1791763200; h=from:to:subject:date:message-id:list-unsubscribe:list-unsubscribe-post;
 bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
 b=Kx7r...truncado...
```

Y el registro DNS correspondiente:

```dns
pg2026._domainkey.example.com.  IN TXT  ( "v=DKIM1; k=rsa; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv1..."
  "...resto-de-la-clave...IDAQAB" )
```

Recomendaciones prácticas:

- **Claves RSA de 2048 bits.** Las de 1024 bits ya se consideran débiles. Como un string TXT tiene un límite de 255 caracteres, la clave se divide en varios strings dentro del mismo registro; el resolvedor los concatena.
- **Canonicalización `relaxed/relaxed`**, que tolera cambios menores de espacios en blanco introducidos por servidores intermedios.
- **Firma los headers que importan:** `From` (obligatorio según RFC 6376), `Subject`, `Date`, `Message-ID`, `To` y, si envías marketing, `List-Unsubscribe` y `List-Unsubscribe-Post`.
- **Rota las claves** periódicamente publicando un selector nuevo, firmando con él y retirando el antiguo pasados unos días, cuando ya no queden mensajes en tránsito.
- **Firma con tu dominio, no con el del proveedor.** Si `d=` es el dominio de tu proveedor, DKIM pasa, pero no alinea con tu From.

## Paso 3: publicar DMARC

DMARC se publica en `_dmarc` del dominio del From:

```dns
_dmarc.example.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com; adkim=r; aspf=r; fo=1"
```

| Etiqueta | Significado |
|---|---|
| `p` | Política: `none` (solo monitorizar), `quarantine` (a spam), `reject` (rechazar) |
| `rua` | Dirección que recibe reportes agregados en XML |
| `adkim` / `aspf` | Modo de alineación: `r` relajado (por defecto) o `s` estricto |
| `pct` | Porcentaje de mensajes al que se aplica la política |
| `sp` | Política para subdominios |
| `fo` | Cuándo generar reportes forenses, si el receptor los envía |

### Cómo funciona la alineación

DMARC pasa si **cualquiera** de estas condiciones se cumple:

1. SPF pasa **y** el dominio del MAIL FROM está alineado con el From.
2. DKIM pasa **y** el dominio `d=` de una firma válida está alineado con el From.

Con alineación **relajada**, basta con que coincida el dominio organizacional: `bounces.example.com` y `mail.example.com` se alinean con `example.com`. Con alineación **estricta**, los dominios deben ser idénticos.

Ejemplo de un mensaje bien autenticado, tal como lo registra el receptor:

```text
Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=bounces.example.com;
  dkim=pass header.d=example.com header.s=pg2026;
  dmarc=pass (p=NONE) header.from=example.com
```

DKIM es el pilar más robusto de la alineación porque sobrevive al reenvío. SPF se rompe cuando un mensaje se reenvía, porque la IP del reenviador no está en tu registro. Por eso conviene que **DKIM siempre alinee**, aunque SPF también lo haga.

## Paso 4: endurecer la política de forma gradual

1. **Semanas iniciales con `p=none`** y `rua` activo. Analiza los reportes: verás todas las IPs que envían en tu nombre, incluidas herramientas olvidadas (CRM, facturación, soporte).
2. **Corrige cada fuente legítima** para que firme DKIM con tu dominio o use un MAIL FROM alineado.
3. **Pasa a `p=quarantine`**, opcionalmente con `pct` reducido al principio.
4. **Llega a `p=reject`** cuando los reportes muestren que solo falla el tráfico no autorizado.

Recuerda que, según las directrices de Google para remitentes masivos, el mínimo exigido es `p=none`, pero una política de cumplimiento protege tu marca frente a la suplantación.

## Errores comunes

- **Dos registros SPF** porque cada herramienta pidió "agregar su registro". Hay que fusionarlos en uno.
- **Superar las 10 consultas** al acumular `include`. Revisa con una herramienta de análisis SPF y elimina proveedores que ya no usas.
- **DKIM firmado con el dominio del proveedor**, lo que deja DMARC dependiendo solo de SPF.
- **Registro DKIM mal partido**, con comillas o espacios extra que corrompen la clave.
- **DMARC publicado en el host equivocado** (`dmarc.example.com` en vez de `_dmarc.example.com`).
- **Saltar directamente a `p=reject`** sin revisar los reportes, bloqueando correos legítimos de otros sistemas.
- **Olvidar los subdominios**: si envías desde `news.example.com`, también necesita SPF y DKIM alineados, y la política `sp` del dominio padre se le aplica si no tiene su propio registro DMARC.

## Checklist rápido

- [ ] Un único registro SPF por dominio de envío, con menos de 10 consultas.
- [ ] Return-path en un subdominio propio (`bounces.example.com`) con su SPF.
- [ ] DKIM con clave de 2048 bits, `d=` igual a tu dominio y firma de `From`.
- [ ] Plan de rotación de selectores DKIM.
- [ ] `_dmarc` publicado con `rua` y, como mínimo, `p=none`.
- [ ] Reportes agregados revisados antes de endurecer la política.
- [ ] Verificación de `Authentication-Results` en un mensaje real enviado a Gmail y Outlook.

## Cómo encaja Pidgely

En Pidgely cada dominio que verificas recibe su propia clave DKIM y un subdominio de return-path con SPF alineado, de modo que DMARC pasa por ambas vías sin depender de un proveedor de envío externo. Tú publicas los registros DNS una vez y la plataforma comprueba que sigan correctos.

## Preguntas frecuentes

### ¿Necesito SPF, DKIM y DMARC a la vez?

Sí, si envías volumen. Según las directrices de Google y Yahoo vigentes desde febrero de 2024, los remitentes masivos deben tener SPF y DKIM, además de un registro DMARC con al menos p=none.

### ¿Qué significa que DMARC esté alineado?

Que el dominio del header From coincide con el dominio autenticado por SPF (el del MAIL FROM) o por DKIM (el valor d=). Con alineación relajada basta con que compartan el dominio organizacional.

### ¿Puedo tener dos registros SPF en el mismo dominio?

No. RFC 7208 exige un único registro v=spf1 por nombre; si hay dos, el resultado es permerror y SPF falla para todos tus envíos.

### ¿Cuándo paso DMARC de p=none a p=reject?

Cuando los reportes agregados (rua) muestren durante varias semanas que todas tus fuentes legítimas pasan con alineación. Lo habitual es pasar primero por p=quarantine.