SPF, DKIM y DMARC para Apple iCloud+ Custom Email Domain.
El Dominio de correo electrónico personalizado de iCloud+ de Apple te permite enviar y recibir correo en tu propio dominio (tu@tudominio.com) a través de iCloud Mail, y autentica ese correo con un conjunto de registros DNS que Apple genera para ti durante la configuración: dos registros MX que entregan todo tu buzón a iCloud, un TXT apple-domain que demuestra que eres el propietario del dominio, un registro SPF que añade el include:icloud.com compartido de Apple y un único CNAME de DKIM (sig1._domainkey) que delega la firma en Apple. No hay ninguna clave pública DKIM que pegar ni nada que rotar: Apple guarda la clave privada detrás de ese CNAME. El único registro que Apple NO genera es DMARC; esa es la pieza que añades tú mismo para convertir SPF y DKIM en una protección real contra la suplantación.
¿Por qué autenticar Apple iCloud+ Custom Email Domain?
Acertar con estos registros en iCloud tiene más riesgo que en un servicio de envío puro, porque el Dominio de correo electrónico personalizado convierte a iCloud en el anfitrión de tu buzón, no solo en un relé de salida: el mismo cambio de MX que te permite enviar también redirige a Apple cada mensaje entrante del dominio. Si lo configuras mal, no solo acabas en spam, sino que dejas de recibir correo. En el plano de la entregabilidad siguen aplicándose las reglas modernas: desde febrero de 2024, Gmail y Yahoo exigen que cada remitente pase SPF o DKIM (y que los remitentes masivos publiquen además DMARC con alineación), y Microsoft empezó a aplicar comprobaciones similares para remitentes de alto volumen en 2025. iCloud es uno de los casos buenos aquí: como es el anfitrión real de tu buzón, el correo saliente se firma con DKIM como tu dominio y SPF se resuelve a través de las IP autorizadas de Apple, de modo que ambos mecanismos pueden alinearse con tudominio.com y alimentar un DMARC PASS. Pero Apple solo publica SPF y DKIM; hasta que añades tú mismo el registro DMARC, los receptores no tienen ninguna política que aplicar y tu dominio sigue siendo suplantable. Ten en cuenta también que el Dominio de correo electrónico personalizado de iCloud+ es un buzón personal / de equipo pequeño (cualquier plan de almacenamiento de pago de iCloud+ lo incluye), no una plataforma de marketing o transaccional: autentícalo como tu buzón humano y mantén el envío masivo en un ESP dedicado.
La realidad del SPF con Apple iCloud+ Custom Email Domain
iCloud es un auténtico proveedor de tipo "include": añades un mecanismo compartido, include:icloud.com, al único registro TXT de SPF de tu dominio raíz, y el asistente de configuración de Apple lo escribe como v=spf1 include:icloud.com ~all. Esa parte es estándar. Lo que casi todas las guías se equivocan es el coste. include:icloud.com NO es un include barato de una sola consulta: es uno de los includes compartidos más caros de uso habitual. Al resolverlo, el registro SPF de icloud.com es v=spf1 redirect=_spf.icloud.com; ese redirect apunta a _spf.icloud.com, cuyo registro es v=spf1 include:_nets0.icloud.com include:_nets1.icloud.com include:_nets2.icloud.com ~all (cada registro _nets contiene únicamente rangos ip4/ip6, así que la cadena termina ahí). Contando según la RFC 7208, eso es el include en sí (1) + el redirect (1) + tres includes _nets anidados (3) = CINCO de tus 10 consultas DNS de SPF permitidas, gastadas solo en iCloud. Si además envías a través de Google Workspace, Microsoft 365 o SendGrid, puedes provocar el PermError de 10 consultas rápidamente, así que trata el include de iCloud como una partida pesada y mantén el resto de tu SPF ligero. Dos reglas más: mantén exactamente un registro SPF en el dominio (fusiona include:icloud.com en tu línea v=spf1 existente en lugar de publicar un segundo TXT: dos registros SPF son un PermError automático) y no confundas la forma include con la forma redirect=icloud.com que muestran algunos tutoriales más antiguos. redirect=icloud.com sustituye toda tu política SPF por la de Apple y descarta silenciosamente a cualquier otro remitente (y cuesta las mismas 5 consultas, así que no te aporta nada), por lo que solo es correcto si iCloud es lo ÚNICO que envía como tu dominio. Apple termina con ~all (softfail), que es el valor por defecto correcto mientras confirmas que todos los remitentes están cubiertos.
Dos formas de configurarlo
include:icloud.com (el valor por defecto de Apple: conserva otros remitentes)
- Lo que realmente genera el asistente de configuración de Apple: v=spf1 include:icloud.com ~all
- Coexiste con otros remitentes: puedes fusionar Google Workspace, M365, SendGrid, etc. en la misma línea
- Cuesta 5 de tus 10 consultas DNS de SPF (redirect + tres includes _nets anidados), así que presupuesta en consecuencia
- Termina en softfail ~all, el valor por defecto seguro mientras confirmas que todos los remitentes están autorizados
redirect=icloud.com (solo si iCloud es tu ÚNICO remitente)
- Sustituye TODA tu política SPF por la de Apple: cualquier cosa que no esté en el registro de icloud.com falla en modo hard-fail
- Rompe silenciosamente cualquier otro servicio que envíe como tu dominio (newsletters, formularios, CRM)
- Sin ahorro de consultas: resuelve la misma cadena de 5 consultas de icloud.com, solo que sin nada de la flexibilidad
- Úsalo solo en un dominio donde iCloud Mail sea la única fuente de envío exclusiva
Paso a paso
- 1
Confirma que tienes iCloud+
El Dominio de correo electrónico personalizado es una función de iCloud+, así que necesitas cualquier plan de pago de iCloud+ (cualquier plan de almacenamiento sirve). El organizador de la cuenta puede compartir un dominio con los miembros de En familia, o puedes configurarlo solo para ti.
- 2
Abre el Dominio de correo electrónico personalizado
En la web, inicia sesión en icloud.com, abre los ajustes de Cuenta/Mail y elige Dominio de correo electrónico personalizado (icloud.com/settings lo muestra directamente). En un iPhone/iPad: Ajustes → toca tu nombre → iCloud → desplázate hasta Dominio de correo electrónico personalizado en Funciones de iCloud+.
- 3
Añade tu dominio
Elige si el dominio es para "Solo tú" o "Tú y otras personas" (En familia), luego escribe tu dominio, p. ej. tudominio.com. iCloud+ permite hasta 5 dominios, con hasta 3 direcciones por persona y dominio.
- 4
Crea las direcciones de correo que vas a usar
Añade los buzones que quieras en el dominio (tu@tudominio.com, hola@tudominio.com, …). Apple no publicará las instrucciones de DNS hasta que hayas definido al menos una dirección: esto es una migración de buzón, no solo una firma de salida, así que decide tus direcciones desde el principio.
- 5
Obtén tus registros DNS
Apple muestra los registros a añadir: dos MX, un valor de verificación TXT apple-domain, la línea SPF y el CNAME de DKIM sig1._domainkey. Usa "Instrucciones por correo" para enviártelos a ti mismo, o copia cada valor. Las instrucciones de Apple indican un TTL de 3600 (1 hora); cualquier TTL estándar sirve.
- 6
Reapunta los MX a iCloud
En tu proveedor de DNS, ELIMINA cualquier registro MX existente y añade mx01.mail.icloud.com y mx02.mail.icloud.com, ambos con prioridad 10. Este es el paso importante: mueve TODO el correo entrante del dominio a iCloud, así que hazlo solo cuando estés listo para convertir a iCloud en el buzón de estas direcciones.
- 7
Añade el TXT de verificación y el registro SPF
En la raíz (host @): añade un registro TXT con el valor de verificación apple-domain=… de Apple, y añade o FUSIONA el registro SPF v=spf1 include:icloud.com ~all. Si ya existe un registro v=spf1, incorpora include:icloud.com en esa única línea: nunca publiques un segundo TXT de SPF.
- 8
Añade el CNAME de DKIM
Crea un CNAME con host sig1._domainkey y destino sig1.dkim.tudominio.com.at.icloudmailadmin.com (Apple sustituye tu dominio real en el destino). Si tu DNS está en Cloudflare, ponlo en DNS only (nube gris): un registro con proxy/nube naranja o el aplanamiento de CNAME rompe la resolución de DKIM.
- 9
Publica tu propio registro DMARC
Apple no crea DMARC. Añade un registro TXT en el host _dmarc con v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com. p=none es solo de monitorización, así que no se bloquea nada mientras confirmas que el correo de iCloud pasa SPF y DKIM alineados.
- 10
Finaliza la configuración y prueba con un mensaje real
De vuelta en iCloud, haz clic en Finalizar configuración para que Apple verifique los registros (la propagación puede tardar de minutos a unas pocas horas). Luego envía un mensaje desde tu nueva dirección a una cuenta de Gmail, abre ⋮ → Mostrar original y confirma SPF: PASS, DKIM: PASS (signed-by tudominio.com, selector sig1) y DMARC: PASS. Envía también un mensaje A la dirección para confirmar que iCloud ya está recibiendo.
Registros que añadir
Apple iCloud+ Custom Email Domain 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 |
|---|---|---|
| MX | @ | mx01.mail.icloud.comPrioridad 10 — redirige todo el correo entrante a iCloud (elimina primero los MX existentes) |
| MX | @ | mx02.mail.icloud.comPrioridad 10 — segundo servidor de correo de iCloud |
| TXT | @ | apple-domain=Ab12Cd34Ef56Gh78Ilustrativo — Apple genera un valor de verificación único por dominio; mantenlo publicado, Apple lo vuelve a comprobar |
| TXT | @ | v=spf1 include:icloud.com ~allFusiónalo en tu única línea SPF si ya existe una. include:icloud.com cuesta 5 consultas DNS (redirect + 3 includes _nets anidados) |
| CNAME | sig1._domainkey | sig1.dkim.yourdomain.com.at.icloudmailadmin.comIlustrativo — Apple inserta tu dominio real. La clave DKIM la guarda/rota Apple; mantén DNS-only (sin proxy de Cloudflare) |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comEsto lo añades tú — Apple no. Un registro DMARC por dominio; empieza en p=none y luego endurece |
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 Apple iCloud+ Custom Email Domain consume de ese presupuesto.
Apple iCloud+ Custom Email Domain añade 5 de tus 10 consultas; los mecanismos ip4: e ip6: no cuentan.
DKIM
El DKIM de iCloud se delega, no se pega. Apple te hace publicar un único CNAME: el host sig1._domainkey.tudominio.com apuntando a sig1.dkim.tudominio.com.at.icloudmailadmin.com (Apple sustituye tu dominio real en ese destino durante la configuración). No hay ninguna clave pública v=DKIM1; p=… que copiar ni ningún selector que inventar: Apple guarda la clave privada detrás de ese CNAME, firma tu correo saliente de iCloud con d=tudominio.com usando el selector sig1 y puede rotar la clave publicada por su lado sin que tú vuelvas a editar el DNS nunca más. Dos puntos prácticos. Primero, iCloud aprovisiona exactamente UN selector, sig1: si un tutorial te dice que añadas también sig2, eso no forma parte del flujo actual de Apple; un único CNAME sig1 es correcto y completo. Segundo, como es un CNAME hacia el nombre de host de Apple, debe resolverse como un registro delegado normal: si tu DNS está en Cloudflare, ponlo en DNS only (nube gris) y evita el aplanamiento de CNAME o cualquier proxy que reescriba el destino, ya que eso rompe la delegación y DKIM deja de firmar en silencio. DKIM es el mecanismo que se alinea de forma más fiable con tu dominio aquí (el d= es tudominio.com), así que es el que sostiene un DMARC PASS incluso cuando un mensaje se reenvía y SPF se rompe: acierta con este CNAME.
DMARC
DMARC es el registro que Apple nunca crea por ti, y sin él el SPF y el DKIM que acabas de publicar no suman ninguna política que se pueda aplicar. Añade un registro TXT en _dmarc.tudominio.com con v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com. p=none es solo de monitorización: no cambia nada en la entrega, pero pide a los receptores que te envíen por correo informes agregados (rua) para que puedas vigilar que el correo de iCloud se autentica. Como iCloud firma con DKIM como tu propio dominio y envía a través de las IP autorizadas por SPF de Apple, deberías ver rápidamente pases limpios y alineados. Deja que los informes corran una o dos semanas, confirma que iCloud más cualquier otro remitente legítimo (una herramienta de newsletter, un formulario de contacto, otro proveedor de buzón) están pasando todos alineados, y luego endurece a p=quarantine y finalmente a p=reject para detener de verdad la suplantación. Mantén exactamente un registro _dmarc para todo el dominio, sin importar cuántos servicios uses: nunca añadas un segundo registro DMARC específico para iCloud. Si alojas el DNS en algún sitio que también te permita recibir los informes, apunta rua a un buzón que vayas a leer de verdad, o pásalos a un analizador de DMARC.
Comprueba que de verdad funcionó
No confíes solo en el tic verde de "Finalizar configuración" de Apple: confirma la autenticación en un mensaje real. Envía desde tu nueva dirección de iCloud a una cuenta de Gmail, abre el mensaje y elige ⋮ → Mostrar original: quieres SPF: PASS, DKIM: PASS con signed-by: tudominio.com y selector sig1, y DMARC: PASS, todos apuntando a tu dominio, no a icloud.com. Como iCloud ahora es también tu anfitrión de recepción, envía también un mensaje A la dirección y asegúrate de que llega, lo que demuestra que el cambio de MX surtió efecto. Para una comprobación en crudo, dig TXT tudominio.com debería mostrar tu único v=spf1 include:icloud.com ~all, dig CNAME sig1._domainkey.tudominio.com debería resolverse a sig1.dkim.tudominio.com.at.icloudmailadmin.com, y dig TXT _dmarc.tudominio.com debería devolver tu política. Luego pasa el dominio por el {healthCheck} de Qualisend para confirmar que todos los registros se resuelven y, algo importante para iCloud, que tu SPF se mantiene por debajo del límite de 10 consultas dadas las 5 consultas que consume include:icloud.com. Una vez que lleguen los informes agregados, mete uno en el {dmarcAnalyzer} para confirmar que iCloud aparece como una fuente alineada y que pasa por completo.
Errores habituales
- Rompe la autenticación
include:icloud.com es caro: cuesta 5 de tus 10 consultas DNS de SPF, no 1. icloud.com redirige a _spf.icloud.com, que anida _nets0/_nets1/_nets2.icloud.com. Apílalo con Google Workspace o Microsoft 365 y puedes provocar el PermError de 10 consultas: mantén el resto de tu SPF ligero y vigila el contador.
- Cobertura
Esto es una migración completa de buzón, no solo firma de salida. Los registros mx01/mx02.mail.icloud.com redirigen TODO el correo entrante del dominio a iCloud. No puedes repartir el alojamiento de las mismas direcciones entre iCloud y otro proveedor: añade los MX solo cuando estés listo para que iCloud reciba ese correo.
- Configuración de DNS
Usa la forma include, no redirect=icloud.com. redirect sustituye toda tu política SPF por la de Apple y descarta silenciosamente a todos los demás remitentes, y cuesta las mismas 5 consultas, así que no hay ninguna ventaja. Solo es correcto cuando iCloud es el único remitente exclusivo del dominio; de lo contrario, tus formularios, newsletters y CRM empiezan a fallar SPF.
- Configuración de DNS
El registro DKIM es un CNAME que no debes poner tras proxy ni aplanar. En Cloudflare pon sig1._domainkey en DNS only (nube gris); un proxy con nube naranja o el aplanamiento de CNAME reescribe el destino y DKIM deja de firmar. Apple guarda la clave: tú nunca pegas ni rotas una clave pública.
- Configuración de DNS
Apple publica SPF y DKIM pero nunca DMARC. Sin tu propio registro _dmarc no hay ninguna política que aplicar y el dominio sigue siendo suplantable: añade v=DMARC1; p=none para empezar y luego endurece.
- Configuración de DNS
iCloud aprovisiona un único selector DKIM (sig1). Si una guía dice que añadas también sig2, eso no es el flujo actual de Apple: un único CNAME sig1 es correcto.
- Rompe la autenticación
Mantén exactamente un registro TXT de SPF. Fusiona include:icloud.com en tu línea v=spf1 existente; dos registros SPF separados son un PermError automático que hace fallar SPF por completo.
- Cobertura
El Dominio de correo electrónico personalizado de iCloud+ es un buzón personal / de equipo pequeño, no un ESP. Apple limita el volumen de envío y prohíbe el correo masivo y comercial, así que no encamines campañas de marketing o transaccionales de alto volumen a través de él: usa una plataforma de envío dedicada para eso.
- Configuración de DNS
No elimines el TXT apple-domain después de la configuración. Apple vuelve a verificar periódicamente la propiedad del dominio con él; eliminarlo puede desactivar el dominio y dejar tu correo fuera de servicio.
Crea tu registro SPF
Apple iCloud+ Custom Email Domain 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 Apple iCloud+ Custom Email Domain — 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.