SPF, DKIM y DMARC para Purelymail.
Purelymail es un proveedor de buzones económico y centrado en la privacidad, y autentica tu dominio con un include SPF genuino, DKIM delegado por CNAME y —de forma poco habitual— un registro DMARC gestionado por Purelymail. En el portal Account Admin (purelymail.com/manage) añades tu dominio y te entrega una lista corta y fija de registros: un TXT de prueba de propiedad, un MX, un TXT SPF construido en torno a include:_spf.purelymail.com, tres CNAME de DKIM y un CNAME de DMARC. Publícalos en tu proveedor de DNS, haz clic en "Check DNS records", y Purelymail enviará y recibirá como si fueras tu propio dominio, con SPF y DKIM ambos alineados. La única decisión que hay que tomar de forma deliberada es DMARC: aceptar el CNAME p=reject gestionado de Purelymail, o publicar tu propio registro para que los informes te lleguen a ti.
¿Por qué autenticar Purelymail?
Autenticar un dominio en Purelymail no es un mero trámite de mantenimiento: decide si tu correo llega a la bandeja de entrada y si alguien puede suplantarte. Desde febrero de 2024, Gmail y Yahoo exigen que todo remitente pase SPF o DKIM, y que todo remitente masivo (aproximadamente 5.000 o más mensajes al día) publique además DMARC con alineación; Yahoo adoptó las mismas reglas ese mismo mes y Microsoft empezó a aplicarlas en Outlook.com/Hotmail/Live en 2025. Hasta que los registros estén activos, el correo que envías a través de Purelymail solo es débilmente atribuible a tu dominio, DMARC no puede pasar y un dominio registrado pero sin proteger es trivialmente suplantable. Purelymail parte de una posición inusualmente sólida una vez configurado: como envía usando tu propio dominio como remitente del sobre (Return-Path), SPF se alinea con tu dominio organizativo y DKIM firma como d=yourdomain.com, de modo que ambos mecanismos pasan alineados —no solo DKIM, como ocurre con la mayoría de los ESP—. Y el DMARC gestionado de Purelymail se entrega con p=reject, que bloquea activamente el correo suplantado en cuanto se resuelve. La pega es que una política p=reject también rechaza cualquier remitente legítimo que olvides autenticar, así que esta configuración premia hacer los tres registros de forma deliberada.
La realidad del SPF con Purelymail
Purelymail es un auténtico proveedor de tipo "include" —no un ESP que delega por CNAME (Mailchimp, Klaviyo) ni un relay que se apropia del Return-Path—. Añades un mecanismo compartido, include:_spf.purelymail.com, al único registro TXT SPF de tu dominio raíz; el registro completo es v=spf1 include:_spf.purelymail.com ~all. Dos cosas hacen que este SPF tenga peso real. Primero, el include se resuelve en un registro plano que contiene solo tres direcciones ip4 y su propio ~all (verificado en vivo: v=spf1 ip4:34.202.193.197 ip4:54.89.13.140 ip4:3.231.132.23 ~all) —no hay includes anidados—, por lo que cuesta exactamente UNA de tus 10 búsquedas DNS de SPF, no las dos o tres que suponen algunos verificadores. Segundo, y a diferencia de la mayoría de las plataformas de envío, Purelymail usa tu propio dominio como remitente del sobre SMTP cuando envías como you@yourdomain.com, así que SPF realmente SE ALINEA con tu dominio organizativo y aporta por sí solo un pase de DMARC, junto con DKIM. Purelymail publica ~all (softfail), no -all, que es el valor por defecto sensato mientras confirmas que todos los remitentes están listados. Se aplican las reglas de siempre: mantén exactamente un registro TXT SPF en la raíz —si además envías a través de Google Workspace, Microsoft 365 o un relay transaccional, fusiona todos los include en esa única línea v=spf1 en lugar de publicar un segundo registro SPF (dos registros SPF son un PermError)— y elimina cualquier SPF que haya quedado de un proveedor de correo anterior.
Dos formas de configurarlo
Tu propio registro DMARC (TXT) — control + informes
- Publicas v=DMARC1; p=none; rua=mailto:you@yourdomain.com y recibes tú mismo los informes agregados
- Te permite avanzar por la rampa p=none → quarantine → reject tras confirmar que cada remitente se alinea
- Seguro cuando además envías desde una herramienta de boletines, un CRM o un formulario web —los ves en los informes antes de aplicar la política
- Necesario si usas cualquier remitente además de Purelymail, o quieres visibilidad sobre quién envía como tu dominio
DMARC gestionado por Purelymail (CNAME) — cero mantenimiento
- Un solo CNAME (_dmarc → dmarcroot.purelymail.com) da un p=reject aplicado e instantáneo sin mantenimiento
- Purelymail mantiene la política actualizada por ti; tú nunca editas el registro
- Los informes de fallo van a dmarc@purelymail.com, no a ti —sin visibilidad agregada (rua) de tu propio dominio
- p=reject se aplica de inmediato, así que CUALQUIER remitente que no hayas autenticado es rechazado de plano, no solo Purelymail
Paso a paso
- 1
Abre la página Add Domain
Inicia sesión en el portal Account Admin en purelymail.com/manage, haz clic en Domains en la navegación superior, luego en Add New Domain e introduce tu dominio (p. ej. yourdomain.com).
- 2
Copia la lista de registros que muestra Purelymail
La página de configuración lista todo lo que necesitas para esta cuenta: el valor TXT purelymail_ownership_proof, un MX (mailserver.purelymail.com), el TXT SPF, tres CNAME de DKIM (purelymail1/2/3._domainkey) y el CNAME de DMARC. Copia el valor de propiedad exactamente —es único para tu dominio.
- 3
Añade el TXT de propiedad y limpia los registros antiguos
En tu registrador/proveedor de DNS, añade un registro TXT en la raíz (Host @ o en blanco) con el valor purelymail_ownership_proof=…. Ya que estás ahí, elimina cualquier registro MX y SPF que haya quedado de un proveedor de correo anterior para que no entren en conflicto.
- 4
Añade el registro MX
Crea un registro MX: Host @ (o en blanco), valor mailserver.purelymail.com, prioridad 50. Este es el único MX que Purelymail necesita —elimina cualquier otro para que el correo entrante no se reparta entre proveedores.
- 5
Añade o fusiona el TXT SPF
Añade un registro TXT en la raíz: v=spf1 include:_spf.purelymail.com ~all. Si ya existe un registro v=spf1 para otro remitente, fusiona el include en ese único registro en lugar de crear un segundo TXT SPF.
- 6
Añade los tres CNAME de DKIM
Crea tres registros CNAME: purelymail1._domainkey → key1.dkimroot.purelymail.com, purelymail2._domainkey → key2.dkimroot.purelymail.com, y purelymail3._domainkey → key3.dkimroot.purelymail.com. Mantenlos como CNAME (no cambies a TXT), y en Cloudflare pon cada uno en DNS only (nube gris).
- 7
Añade DMARC — elige gestionado o propio
Para la opción sin intervención, añade un CNAME _dmarc → dmarcroot.purelymail.com (la política p=reject gestionada de Purelymail). Si envías desde cualquier sitio además de Purelymail o quieres tus propios informes, omite el CNAME y en su lugar añade un TXT en _dmarc como v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Puedes tener uno u otro, nunca ambos.
- 8
Haz clic en Check DNS records y luego termina la configuración
De vuelta en la página de configuración de Purelymail, haz clic en Check DNS records. Deja pasar ~15 minutos (hasta 24-48 horas) para la propagación. Una vez que todo valide, pon Deliver Mail To = Purelymail, opcionalmente deja Allow Account Reset habilitado para la recuperación, haz clic en Save y luego crea tus buzones de usuario para el dominio.
- 9
Envía una prueba y lee las cabeceras
Envía un mensaje desde tu nueva dirección de Purelymail a una cuenta de Gmail, ábrelo y elige ⋮ → Mostrar original. Quieres ver SPF: PASS, DKIM: PASS con d=yourdomain.com, y DMARC: PASS —todo alineado con tu dominio.
Registros que añadir
Purelymail 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 |
|---|---|---|
| TXT | @ | purelymail_ownership_proof=xxxxxxxxxxxxxxxxxxxxIlustrativo —copia el valor exacto por dominio desde la página Add Domain. Obligatorio antes de que Purelymail añada el dominio. |
| MX | @ | mailserver.purelymail.comPrioridad 50 —el único MX que usa Purelymail. Elimina primero los registros MX de cualquier proveedor anterior. |
| TXT | @ | v=spf1 include:_spf.purelymail.com ~allSPF raíz —mantén exactamente un registro SPF; fusiona en él los otros remitentes. El include se resuelve en un registro plano de 3 IP = 1 búsqueda DNS, y se alinea porque tu dominio es el remitente del sobre. |
| CNAME | purelymail1._domainkey | key1.dkimroot.purelymail.comClave rotatoria de DKIM 1 (gestionada por Purelymail). Delegación por CNAME —mantén como CNAME, DNS only en Cloudflare. |
| CNAME | purelymail2._domainkey | key2.dkimroot.purelymail.comClave rotatoria de DKIM 2 —las tres son obligatorias porque Purelymail firma con una de tres claves que rota. |
| CNAME | purelymail3._domainkey | key3.dkimroot.purelymail.comClave rotatoria de DKIM 3. |
| CNAME | _dmarc | dmarcroot.purelymail.comDMARC gestionado por Purelymail (actualmente se resuelve en v=DMARC1; p=reject; ruf=mailto:dmarc@purelymail.com). Usa este O tu propio TXT _dmarc —un nombre no puede ser a la vez un CNAME y un TXT. |
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 Purelymail consume de ese presupuesto.
Purelymail añade 1 de tus 10 consultas; los mecanismos ip4: e ip6: no cuentan.
DKIM
El DKIM de Purelymail se delega por CNAME entre tres claves rotatorias, por eso publicas tres registros en lugar de uno. Crea purelymail1._domainkey, purelymail2._domainkey y purelymail3._domainkey como CNAME que apunten a key1.dkimroot.purelymail.com, key2.dkimroot.purelymail.com y key3.dkimroot.purelymail.com respectivamente. Como son CNAME —no registros TXT que pegas—, Purelymail conserva las claves privadas y publica las claves públicas detrás de esos hostnames dkimroot (cada uno se resuelve en un TXT v=DKIM1; k=rsa; p=… del lado de Purelymail), y puede rotar entre las tres claves según su propio calendario sin que vuelvas a editar el DNS. Ese es todo el sentido del enfoque CNAME y la razón por la que las tres son obligatorias: cualquier mensaje se firma con una de las tres claves, así que si publicas solo un CNAME, aproximadamente dos tercios de tu correo fallarán DKIM. Las firmas se hacen como d=yourdomain.com, de modo que DKIM se alinea con tu dominio organizativo y satisface DMARC. Dos notas prácticas: no conviertas estos registros a TXT (eso rompe la rotación de Purelymail) y, si tu DNS está detrás de Cloudflare, pon cada uno de los tres CNAME en "DNS only" (nube gris) o el proxy enmascarará el destino y DKIM no validará.
DMARC
En DMARC es donde Purelymail hace algo que la mayoría de los proveedores no: ofrece una política totalmente gestionada entregada por CNAME. Si añades _dmarc → dmarcroot.purelymail.com, ese CNAME se resuelve actualmente en v=DMARC1; p=reject; ruf=mailto:dmarc@purelymail.com —una política de rechazo aplicada que Purelymail mantiene por ti—. Para un dominio que envía únicamente a través de Purelymail, es una victoria genuinamente cómoda y sin mantenimiento: obtienes protección antisuplantación sólida al instante y nunca tocas el registro. Pero entiende las contrapartidas antes de elegirlo. Primero, los informes de fallo/forenses (ruf) van al buzón propio de Purelymail, y no se te envía a ti ningún informe agregado rua en absoluto —así que no tienes ninguna visibilidad sobre quién envía como tu dominio o si una fuente legítima está fallando—. Segundo, p=reject se aplica en el momento en que se resuelve, así que cualquier otro remitente que uses —una herramienta de boletines, un CRM, un relay del formulario de contacto de una web, una plataforma de marketing— verá su correo rechazado de plano a menos que ya esté autenticado y alineado con tu dominio. Si envías desde cualquier sitio además de Purelymail, o quieres tus propios informes y una rampa segura, publica tu propio registro en su lugar: un TXT en _dmarc como v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com, vigila los informes agregados durante una semana o dos hasta que todos los remitentes legítimos pasen alineados, luego endurece a p=quarantine y finalmente a p=reject. No puedes usar ambos —un hostname puede ser un CNAME o contener registros TXT, nunca ambos (RFC 1034)—, así que es un camino o el otro. Mantén exactamente un registro _dmarc para todo el dominio organizativo en cualquier caso.
Comprueba que de verdad funcionó
No te fíes solo de la marca verde de "Check DNS records" de Purelymail: confírmalo con un mensaje real. Envía una prueba desde tu dirección de Purelymail a una cuenta de Gmail, ábrela y elige ⋮ → Mostrar original: quieres ver SPF: PASS (alineado con yourdomain.com, ya que Purelymail usa tu dominio como remitente del sobre), DKIM: PASS con d=yourdomain.com, y DMARC: PASS. También puedes comprobar los registros en bruto desde un terminal: dig TXT _spf.purelymail.com debería mostrar las tres direcciones ip4, dig CNAME purelymail1._domainkey.yourdomain.com debería apuntar a key1.dkimroot.purelymail.com, y dig TXT _dmarc.yourdomain.com debería devolver tu política DMARC (siguiendo el CNAME si usaste el gestionado). Después pasa tu dominio por el chequeo de salud de dominio de Qualisend para confirmar que el SPF se mantiene en una búsqueda, que los tres CNAME de DKIM se resuelven y que DMARC está presente. Si optaste por el CNAME gestionado, recuerda que sus informes van a Purelymail —en cuanto quieras tu propia visibilidad, cambia a tu propio registro DMARC con un rua que apunte a ti y alimenta los informes agregados en el analizador de informes DMARC.
Errores habituales
- Configuración de DNS
Aquí DMARC es un CNAME, no un TXT —y no puedes tener ambos. Si quieres tus propios informes rua o una rampa de p=none a reject, NO añadas el CNAME _dmarc de Purelymail; publica un TXT _dmarc en su lugar. Un hostname puede ser un CNAME o contener registros TXT, nunca ambos (RFC 1034), así que mezclarlos es un error de configuración que tu proveedor de DNS rechazará.
- Cobertura
El DMARC gestionado es p=reject y se aplica de inmediato. Rechazará correo legítimo de cualquier remitente que no hayas autenticado —una herramienta de boletines, un CRM, un plugin de formularios o un relay transaccional—, no solo de Purelymail. Autentica primero cada remitente, o ejecuta tu propio registro p=none mientras avanzas por la rampa.
- Configuración de DNS
Los informes del DMARC gestionado van a dmarc@purelymail.com, y no se te envía ningún informe agregado (rua). No obtienes ninguna visibilidad sobre quién envía como tu dominio. Publica tu propio DMARC con rua= si quieres los informes.
- Configuración de DNS
Los tres CNAME de DKIM son obligatorios. Purelymail firma cada mensaje con una de tres claves rotatorias, así que publicar solo purelymail1._domainkey significa que los mensajes firmados con las claves 2 y 3 fallan DKIM. Añade purelymail1/2/3._domainkey enteros.
- Rompe la autenticación
Elimina los MX y SPF antiguos de cualquier proveedor previo. Un MX residual reparte tu correo entrante entre proveedores, y un segundo registro TXT SPF es un PermError. Mantén exactamente un MX (mailserver.purelymail.com, prioridad 50) y un TXT SPF.
- Configuración de DNS
El proxy de Cloudflare rompe los CNAME. Pon los tres CNAME de DKIM y (si se usa) el CNAME de DMARC en 'DNS only' (nube gris). Un CNAME con proxy de nube naranja no se resolverá en los hosts dkimroot/dmarcroot de Purelymail y la validación falla.
- Configuración de DNS
Copia la prueba de propiedad exactamente. Purelymail no añadirá el dominio hasta que el TXT purelymail_ownership_proof se resuelva; un valor truncado o editado hace fallar en silencio el paso 'Check DNS records'.
- Configuración de DNS
Duplicación del campo Host: muchos registradores añaden automáticamente tu dominio, así que introducir purelymail1._domainkey.yourdomain.com se convierte en purelymail1._domainkey.yourdomain.com.yourdomain.com. Introduce solo la etiqueta (purelymail1._domainkey, _dmarc, @) cuando el panel añade el dominio por ti.
Crea tu registro SPF
Purelymail ya viene preseleccionado abajo. Añade cualquier otra plataforma desde la que envíes y luego publica el registro fusionado único.
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).
- 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 Purelymail — 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.