SPF, DKIM y DMARC para Mailtrap.
Mailtrap autentica tu dominio mediante verificación de dominio basada en CNAME, no haciéndote pegar una línea SPF compartida. En su producto Email Sending añades un dominio de envío y Mailtrap te entrega cinco registros DNS en la página Domain Verification: un CNAME de Domain Verification (que también cubre SPF/return-path), dos CNAMEs de DKIM en los selectores rwmt1._domainkey y rwmt2._domainkey, un CNAME opcional de Custom Tracking Domain para el seguimiento de aperturas/clics con tu marca, y un registro DMARC TXT. Una vez que estos resuelven, Mailtrap firma y envía como tu propio dominio, DMARC pasa gracias al DKIM alineado (y al SPF a través de tu propio return-path), y nunca tienes que publicar ni mantener un include SPF en bruto. Una cosa que despista a la gente al principio: esto solo se aplica a Mailtrap Email Sending — el sandbox aparte de Email Testing captura los mensajes en una bandeja de entrada ficticia y no necesita ningún DNS.
¿Por qué autenticar Mailtrap?
Verificar tu dominio de envío en Mailtrap es la puerta entre la bandeja de entrada y la carpeta de spam — y Mailtrap lo exige antes de enviar correo de producción siquiera. Hasta que un dominio esté verificado, Mailtrap restringe un flujo de Email Sending a mensajes de prueba dirigidos al correo de tu propia cuenta; los destinatarios reales quedan bloqueados. Más allá de eso, el momento importa: desde febrero de 2024 Gmail y Yahoo exigen que todo remitente masivo (aproximadamente 5.000+ mensajes al día) pase SPF, DKIM y DMARC con alineación, y en 2025 Microsoft empezó a aplicar el mismo listón para Outlook/Hotmail/Live — primero derivando el correo masivo no conforme a la carpeta de correo no deseado, y luego avanzando hacia el rechazo directo. Como Mailtrap es un remitente transaccional/API, un flujo sin verificar significa que tu correo o bien no sale o bien sale débilmente atribuible a tu dominio — sin DKIM alineado, sin paso de DMARC, y con la reputación agrupada con la infraestructura compartida de Mailtrap en lugar de la tuya propia. Completar la verificación de dominio lo arregla todo de golpe: los dos selectores DKIM rwmt firman como d=yourdomain.com para que el DKIM se alinee, el CNAME de Domain Verification pone el return-path de Mailtrap en tu propio dominio para que el SPF pase y también se alinee, DMARC pasa con ambos mecanismos, y la reputación de envío que construyes se acumula en tu dominio.
La realidad del SPF con Mailtrap
Mailtrap es un proveedor de verificación de dominio basada en CNAME, así que para tu dominio raíz NO hay ningún include SPF que añadir — y la propia documentación de Mailtrap lo dice sin rodeos: "The SPF check for your mail is covered by the domain verification record. There is no need to add a separate SPF record on your sending domain." Este es el mecanismo. Cuando verificas un dominio de envío, uno de los CNAMEs que Mailtrap te da es el registro Domain Verification, que también hace de host de return-path/rebotes en tu propio dominio y delega la búsqueda SPF en la infraestructura de envío de Mailtrap. El registro SPF real y activo de Mailtrap vive en _spf.smtp.mailtrap.live (v=spf1 ip4:45.158.83.0/24 ip4:5.181.200.0/24 … ~all) — pero tú nunca lo publicas; el CNAME de Domain Verification resuelve hacia él por ti. Como ese host de return-path se sitúa bajo tu propio dominio verificado, el SPF pasa y se alinea con tu dominio organizativo bajo alineación relajada, lo cual es una ventaja genuina frente a los remitentes CNAME solo de DKIM (Mailchimp, Klaviyo) donde el SPF nunca puede alinearse. Dos cosas que conviene saber. Primero, ignora cualquier consejo antiguo de añadir include:_spf.mailtrap.io — ese hostname no resuelve como registro SPF en absoluto, e incluso el host de infraestructura correcto (_spf.smtp.mailtrap.live) no es algo que pegues en tu raíz; añadirlo manualmente solo quemaría una de tus 10 búsquedas DNS de SPF para nada. Segundo, si tu DNS está en Google Cloud DNS, su consola todavía ofrece un tipo de registro "SPF" heredado — Mailtrap te dice explícitamente que lo ignores (está obsoleto) y añadas los cuatro CNAMEs más el DMARC TXT como de costumbre. Efecto neto sobre tu SPF raíz: Mailtrap añade cero búsquedas DNS, así que encaja limpiamente con Google Workspace, Microsoft 365 o cualquier otro remitente que ya tengas en la lista.
Dos formas de configurarlo
Verifica un subdominio de envío dedicado (p. ej. mail.yourdomain.com)
- Aísla la reputación transaccional/de Mailtrap del correo humano de tu dominio raíz, de modo que un error de envío no pueda arrastrar a tu dominio principal.
- El DKIM firma como d=mail.yourdomain.com y, bajo la alineación relajada de DMARC, sigue alineándose con tu dominio organizativo — así que DMARC pasa.
- El CNAME de Domain Verification pone el return-path en el subdominio, así que el SPF pasa y también se alinea allí.
- Aun así añades los cuatro CNAMEs más un DMARC TXT; tu SPF raíz queda intacto, sin añadir ninguna búsqueda DNS.
Verifica el dominio raíz/organizativo (yourdomain.com)
- Lo más sencillo si Mailtrap es tu único remitente o el principal y quieres que el correo salga visiblemente desde el dominio a secas.
- El DKIM y el return-path se sitúan directamente en el dominio organizativo, así que la alineación es exacta en lugar de depender del modo relajado.
- La reputación se comparte con todo lo demás que envías desde la raíz — tenlo en cuenta si el correo humano de Google Workspace o Microsoft 365 también vive ahí.
- Aun así, cero búsquedas añadidas a tu SPF raíz, ya que Mailtrap usa el CNAME de Domain Verification, no un include en la raíz.
Paso a paso
- 1
Abre Email Sending, no Email Testing
Inicia sesión en mailtrap.io y asegúrate de estar en el producto Email Sending (la sección de la barra lateral para el correo saliente real), no en Email Testing (el sandbox que captura mensajes para QA y no necesita DNS). La verificación de dominio solo existe para Email Sending.
- 2
Añade tu dominio de envío
En la navegación de la izquierda, ve a Sending Domains y haz clic en Add Domain. Introduce el dominio desde el que enviarás (p. ej. yourdomain.com, o un subdominio como mail.yourdomain.com si quieres aislar el correo transaccional). Mailtrap genera los registros DNS para ese nombre exacto.
- 3
Abre la página Domain Verification
Selecciona el nuevo dominio para abrir su página Domain Verification. Verás los registros a publicar, cada uno etiquetado por propósito: Domain Verification (CNAME), DKIM (dos CNAMEs), Custom Tracking / Domain Tracking (CNAME) y DMARC (TXT). Fíjate en las columnas Type, Name y Value — el Name y el Value se generan para tu cuenta.
- 4
Añade el CNAME de Domain Verification
Crea el registro Domain Verification como CNAME usando exactamente el Name y el Value que muestra Mailtrap. Este único registro demuestra la propiedad y a la vez cubre SPF/return-path — es la razón por la que no publicas un registro SPF aparte. Mantén el tipo como CNAME; no lo conviertas en TXT ni A.
- 5
Añade los dos CNAMEs de DKIM
Crea dos registros CNAME: Name rwmt1._domainkey → Value rwmt1.dkim.mailtrap.io, y Name rwmt2._domainkey → Value rwmt2.dkim.mailtrap.io (usa los valores exactos de tu panel). Dos selectores permiten a Mailtrap rotar las claves DKIM sin que tú vuelvas a tocar el DNS. Estos CNAMEs son los que firman tu correo como d=yourdomain.com y aportan el paso de DMARC.
- 6
Añade el CNAME de Custom Tracking Domain
Crea el CNAME de tracking (Mailtrap suele mostrar un Name como mt-link) apuntando al Value que proporciona. Sirve el seguimiento de aperturas/clics y los enlaces de baja desde tu propio dominio en lugar de desde un host de Mailtrap. Es el único registro que puedes omitir si no usas seguimiento de enlaces, pero añadirlo mantiene los enlaces rastreados con tu marca y evita la reputación de dominio compartido de un host de tracking genérico de Mailtrap.
- 7
Añade el registro DMARC TXT
Crea un único registro TXT en Name _dmarc con el valor que muestra Mailtrap (una política v=DMARC1; p=none; … ). Si tu dominio ya tiene un registro _dmarc, NO añadas un segundo — un dominio debe tener exactamente un registro DMARC; quédate con el que ya tienes.
- 8
Corrige la duplicación del host y desactiva el proxy de Cloudflare
Muchos registradores añaden tu dominio automáticamente, así que introduce solo la etiqueta (rwmt1._domainkey, no rwmt1._domainkey.yourdomain.com) para evitar la duplicación — aunque unos pocos paneles quieren la forma con el sufijo completo, así que ajústate a lo que espere tu host. En Cloudflare, pon cada CNAME en DNS only (nube gris); Cloudflare activa el proxy por defecto, y un CNAME con proxy de nube naranja no resolverá a Mailtrap, por lo que la verificación falla.
- 9
Vuelve a comprobar el DNS en Mailtrap
De vuelta en la página Domain Verification, haz clic en Re-check DNS Records. Mailtrap también comprueba automáticamente de forma periódica, así que los registros pasan de Missing (rojo) a Verified (verde) a medida que se propagan — normalmente minutos, pero deja un margen de 15 minutos a 24–48 horas. Algunos registros se verifican antes que otros; espera hasta que todos estén en verde.
- 10
Envía una prueba y lee las cabeceras
Envía un mensaje desde una dirección del dominio verificado, ábrelo en Gmail y elige ⋮ → Show original. Confirma DKIM: PASS firmado por yourdomain.com (selector rwmt1 o rwmt2), SPF: PASS y DMARC: PASS — todos alineados con tu dominio, no con un host mailtrap.io.
Registros que añadir
Mailtrap genera los valores exactos en su asistente de configuración; estos muestran la forma de lo que añadirás en tu proveedor de DNS.
| Tipo | Host | Valor |
|---|---|---|
| CNAME | (Mailtrap-generated verification host) | (per-account target, e.g. under smtp.mailtrap.live)Registro Domain Verification — ilustrativo. Mailtrap muestra el Name y el Value exactos por cuenta en la página Domain Verification. Este CNAME también cubre SPF/return-path, por lo que no hace falta un registro SPF aparte. |
| CNAME | rwmt1._domainkey | rwmt1.dkim.mailtrap.ioClave DKIM 1 (rotada automáticamente). Copia el valor exacto de tu panel; algunos hosts DNS necesitan la forma con sufijo rwmt1._domainkey.yourdomain.com. |
| CNAME | rwmt2._domainkey | rwmt2.dkim.mailtrap.ioClave DKIM 2 — el segundo selector permite a Mailtrap rotar las claves. Usa el destino exacto que se muestra en tu panel. |
| CNAME | mt-link | (per-account tracking target)Custom Tracking Domain — host/destino ilustrativo. Habilita el seguimiento de aperturas/clics con tu marca y los enlaces de baja en tu dominio. Opcional pero recomendado; el Name/Value exacto se muestra por cuenta. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comPolítica DMARC — una por dominio. Mailtrap prerrellena un valor p=none; mantén un solo registro _dmarc y endurece a quarantine/reject más adelante. |
Mantén exactamente un registro TXT de SPF (v=spf1) en tu dominio raíz: fusiona en él todos los remitentes. Tener dos registros SPF es en sí mismo un error.
El presupuesto de 10 consultas
El SPF tiene un límite estricto de 10 consultas DNS: si lo superas, devuelve un permerror y deja de validar en todas partes. Esto es lo que la configuración de Mailtrap consume de ese presupuesto.
La configuración recomendada de Mailtrap añade 0 consultas: las 10 quedan libres para los remitentes que sí necesitan un include.
DKIM
El DKIM se gestiona con dos registros CNAME — rwmt1._domainkey y rwmt2._domainkey — que Mailtrap genera para tu dominio, apuntando a rwmt1.dkim.mailtrap.io y rwmt2.dkim.mailtrap.io respectivamente (copia los valores exactos de la página Domain Verification). Como son CNAMEs delegados a Mailtrap — no registros TXT que pegas — Mailtrap conserva las claves privadas y usa los dos selectores para rotar las claves publicadas detrás de ellos sin que tú tengas que volver a editar el DNS. No hay ninguna clave pública DKIM que copiar ni ningún selector que inventar. El DKIM es el mecanismo que hace el trabajo pesado para DMARC aquí: una vez que los CNAMEs resuelven, Mailtrap firma el correo saliente como d=yourdomain.com, de modo que la firma se alinea con tu dominio organizativo y satisface DMARC por sí sola — independientemente del reenvío, que puede romper el SPF. Unas cuantas cuestiones prácticas: mantén el tipo de registro como CNAME (un TXT donde se espera un CNAME rompe la validación); introduce solo la etiqueta (rwmt1._domainkey) si tu panel añade el dominio automáticamente, o el rwmt1._domainkey.yourdomain.com completo si no lo hace; y en Cloudflare pon ambos en DNS only (nube gris) para que resuelvan a los destinos mailtrap.io. Añades los dos CNAMEs, haces clic en Re-check DNS Records y las filas de DKIM se ponen en verde.
DMARC
DMARC es un registro de política aparte en tu dominio, y Mailtrap lo incluye en el conjunto de registros de la página Domain Verification — normalmente prerrellenado como v=DMARC1; p=none; … . Publícalo como registro TXT en _dmarc.yourdomain.com. p=none es solo de monitorización: no cambia nada en la entrega mientras confirmas, a partir de los informes agregados (rua), que el correo de Mailtrap está pasando DKIM (y SPF) alineado con tu dominio. Como Mailtrap te da tanto un DKIM alineado (los selectores rwmt) como un return-path alineado (el CNAME de Domain Verification), un dominio correctamente verificado pasa DMARC con ambos mecanismos — la configuración resistente que sobrevive al reenvío. Vigila los informes durante una o dos semanas, asegúrate de que todos los remitentes legítimos se autentican, y luego endurece a p=quarantine y finalmente a p=reject. Dos reglas: mantén exactamente un registro _dmarc para todo el dominio sin importar cuántos remitentes uses — si ya tienes uno, no añadas la segunda copia de Mailtrap, quédate simplemente con el tuyo — y apunta rua a un buzón (o a un servicio de informes DMARC) que realmente vigiles, o p=none no te sirve de nada.
Comprueba que de verdad funcionó
No te fíes solo de la insignia verde "Verified" de la página Domain Verification — eso solo confirma que los registros resuelven, no que un mensaje real se autentique. Envíate una prueba desde una dirección del dominio verificado, ábrela en Gmail y elige ⋮ → Show original: quieres ver DKIM: PASS firmado por yourdomain.com con el selector rwmt1 o rwmt2, SPF: PASS y DMARC: PASS, todos mostrando tu dominio en lugar de un host mailtrap.io. En Mailtrap, usa el botón Re-check DNS Records para forzar una comprobación en vez de esperar al sondeo periódico. Puedes comprobar puntualmente los registros en bruto con dig CNAME rwmt1._domainkey.yourdomain.com y dig TXT _dmarc.yourdomain.com. Después pasa tu dominio por el {healthCheck} de Qualisend para confirmar que el CNAME de Domain Verification, ambos selectores DKIM, el CNAME de tracking y el registro DMARC resuelven todos limpiamente y que tu SPF raíz se mantiene por debajo del límite de 10 búsquedas — y cuando empiecen a llegar los informes agregados de DMARC, mete uno en el {dmarcAnalyzer}, donde Mailtrap debería aparecer como una fuente alineada y que pasa.
Errores habituales
- Cobertura
Email Testing vs Email Sending: la verificación de dominio solo existe para el producto Email Sending. El sandbox de Email Testing captura mensajes en una bandeja de entrada ficticia para QA y no necesita ningún registro DNS — si buscas una configuración DNS bajo Email Testing, estás en el sitio equivocado.
- Configuración de DNS
No hay ningún registro SPF que añadir. El CNAME de Domain Verification de Mailtrap ya cubre SPF/return-path, así que no pegues include:_spf.mailtrap.io (no resuelve) ni include:_spf.smtp.mailtrap.live (el host de infraestructura interna de Mailtrap) en tu raíz — hacerlo desperdicia una búsqueda SPF y la documentación de Mailtrap dice explícitamente que no hace falta un registro SPF aparte.
- Configuración de DNS
El proxy de Cloudflare rompe la verificación: pon cada CNAME de Mailtrap en DNS only (nube gris). Cloudflare activa el proxy de nube naranja por defecto, y un CNAME con proxy no resolverá a los destinos mailtrap.io / mailtrap.live, así que los registros nunca se verifican.
- Configuración de DNS
Duplicación del campo host: muchos registradores añaden tu dominio automáticamente, de modo que rwmt1._domainkey puede convertirse en rwmt1._domainkey.yourdomain.com.yourdomain.com. Introduce solo la etiqueta si el panel añade el dominio; a la inversa, unos pocos hosts (algunos paneles al estilo Squarespace) quieren la forma con el sufijo completo — ajústate a lo que espere tu proveedor.
- Configuración de DNS
Todos los registros son CNAME salvo DMARC (TXT) — no cambies los tipos. En Google Cloud DNS en concreto, ignora el tipo de registro 'SPF' heredado de la consola; Mailtrap indica que está obsoleto. Añade los cuatro CNAMEs y el único DMARC TXT.
- Cobertura
Hasta que el dominio esté Verified, Mailtrap solo permite que un flujo de Email Sending entregue mensajes de prueba a la dirección de correo de tu propia cuenta. Los envíos de producción a destinatarios reales siguen bloqueados, así que termina la verificación antes de conectar Mailtrap con el tráfico en vivo de tu aplicación.
- Configuración de DNS
Mantén un solo DMARC y un solo SPF. Si también envías vía Google Workspace, Microsoft 365, SendGrid, etc., no añadas un segundo _dmarc ni un segundo SPF TXT — Mailtrap añade cero a tu SPF raíz, así que simplemente conserva tus registros únicos existentes.
- Cobertura
La verificación no es instantánea: la propagación puede tardar de 15 minutos a 24–48 horas, y Mailtrap vuelve a comprobar según su propio calendario. Usa Re-check DNS Records para forzar una comprobación, y cuenta con que algunos registros se pondrán en verde antes que otros.
Crea tu registro SPF
Mailtrap no necesita un include: de SPF en tu dominio raíz: usa el generador para ensamblar un único registro limpio para tus otros remitentes y mantenlo en una sola línea.
Sending sources
Search for each platform you send email through and tick it.
Search for your email platform above, or .
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listSPF de Mailtrap — Preguntas frecuentes
Lecturas relacionadas
Una vez publicado, confirma que todo se resuelve con el chequeo de salud del dominio y luego averigua quién envía en tu nombre con el analizador de informes DMARC. Explora todas las fuentes de envío en el generador. Eso sí, la autenticación es solo la mitad de la entregabilidad: una IP o un dominio de envío incluidos en una lista negra te llevan igualmente a spam por muy limpio que esté tu SPF, así que conviene vigilar las listas negras con monitorización de listas negras.
Autenticado: ahora mantén la lista limpia
Pasar SPF, DKIM y DMARC te lleva a la bandeja de entrada; una lista limpia te mantiene ahí. Verifica la tuya: empieza gratis con 100 créditos, sin tarjeta.