Skip to main content
Cómo ReallyQuickEmails (RQE) autentica tus envíos y qué hay detrás de “¿llega al inbox?”. No es un tutorial paso a paso (para eso ver Dominios), sino la teoría para diagnosticar problemas y decidir qué configurar.

​
El stack de autenticación

Cuando un servidor de correo (Gmail, Outlook) recibe un email, hace 4 chequeos para decidir si va al inbox o a spam: Con los 4 pasando, tu email tiene alignment estricto y la deliverability sube mucho.

​
SPF (Sender Policy Framework)

Un record TXT en tu DNS que lista qué servidores pueden enviar desde tu dominio. Cuando RQE envía desde noreply@tudominio.com, Gmail consulta el SPF de tudominio.com y verifica que el servidor de envío esté en la lista. Ejemplo (el que genera RQE al registrar tu dominio):
~all (soft fail): los servidores no listados se marcan como sospechosos sin rechazarse. Endurécelo a -all (hard fail) cuando confirmes que todo tu tráfico legítimo sale por servidores listados.
Si ya tienes SPF para otro proveedor (Mailgun, Sendgrid, Google Workspace), mergea los include: en un solo record; no agregues otro TXT. Múltiples records SPF rompen la verificación.

​
DKIM (DomainKeys Identified Mail)

Una firma criptográfica del contenido, hecha con una clave privada de RQE. Tu dominio publica la clave pública en DNS vía 3 records CNAME. Al llegar el email, Gmail toma la firma del header, descarga la clave pública del CNAME y valida.
Los tokens (abc123, …) se generan al registrar tu dominio y vienen en la respuesta de POST /domains/register. DKIM también hace que tu dominio aparezca en el signed-by: del header en Gmail web: señal de legitimidad para el usuario final.

​
DMARC

La política sobre qué hacer si SPF o DKIM fallan. Es el más fuerte de los 3 contra spoofing. Ejemplo:
pct=100 aplica la política al 100% del tráfico. Es común empezar con pct=10 y subir gradualmente.
Reportes DMARC — gestionados por RQECon rua=, los servidores receptores envían reportes diarios con qué % de tu tráfico pasó SPF/DKIM. El registro que RQE te genera apunta ese rua a una casilla gestionada por RQE: nosotros recibimos y procesamos esos reportes por ti — no necesitas un servicio externo ni leer XML. Usa el valor exacto que muestra tu dashboard en Dominios (el d-<id> es único por dominio).

​
MAIL FROM domain (custom)

Sin configuración extra, el mailed-by: que ve Gmail es amazonses.com — el dominio del proveedor, no el tuyo. Eso baja el SPF alignment de strict a relaxed. Con un Custom MAIL FROM domain (en RQE, el subdominio bounce.tudominio.com), el mailed-by: pasa a ser tu dominio y SPF queda strict. RQE lo configura con un único record CNAME, incluido en los 7 que se generan al registrar el dominio:
Custom MAIL FROM no es obligatorio: can_send no lo requiere y los emails llegan igual sin él. Pero mejora el alignment SPF, sobre todo en clientes estrictos como ProtonMail u Outlook empresarial. Recomendado para volúmenes grandes.
El error más común: creer que el SPF solo alcanza.SPF no se evalúa contra el dominio del From, sino contra el del Return-Path. Sin Custom MAIL FROM, el Return-Path es @amazonses.com: tu SPF pasa, pero pasa para amazonses.com, así que no alinea con tu From y no aporta a DMARC.Es decir, agregar include:amazonses.com a tu SPF no sirve por sí solo si no publicaste también el registro de Return-Path. Quien cubre DMARC en ese escenario es DKIM, no SPF.

​
El proceso de verificación en RQE

1

Registrar el dominio

POST /domains/register con { "domain": "tudominio.com", "sender_name": "Mi Empresa", "sender_email": "noreply@tudominio.com" } (los tres campos son requeridos). RQE genera los 8 records DNS y los devuelve. Ver Dominios.
2

Configurar los 8 records

En tu proveedor DNS (Cloudflare, GoDaddy, Route 53, etc):
  • 1 TXT verificación de dominio
  • 3 CNAME DKIM
  • 1 TXT SPF (mergear con existente si aplica)
  • 1 TXT DMARC
  • 1 MX send + 1 TXT send (Return-Path / Custom MAIL FROM)
3

Esperar propagación

5–10 minutos en Cloudflare/Route 53. Hasta 48h en proveedores lentos.
4

Verificar

POST /domains/:domain/verify comprueba la verificación del dominio, los 3 CNAME de DKIM y los registros de MAIL FROM (SPF y DMARC no se validan ahí: los resuelve un barrido propio cada 6 horas). Con dominio y DKIM verificados, la respuesta incluye can_send: true y puedes enviar desde *@tudominio.com.

​
Reputación: lo que decide el inbox cuando la auth ya está bien

Tener los 4 registros en verde no garantiza el inbox. La autenticación demuestra que el correo es tuyo; la reputación decide si lo quieren. Es el caso más común de soporte: un dominio con todo configurado que igual cae en spam.
La reputación es del dominio, no de la IP.Gmail y Outlook evalúan sobre todo el dominio que firma DKIM (el d= de la firma). Esa reputación te sigue aunque cambies de proveedor o de servidor. Por eso casi nunca el problema se arregla “cambiando de IP”.
Si el From dice @tudominio.com pero los enlaces apuntan a otro dominio, los filtros lo leen como señal de suplantación: es una técnica clásica de phishing. Pasa sin querer cuando el open/click tracking envuelve los links con un dominio compartido. La solución es el dominio de tracking (links.tudominio.com): los enlaces y el pixel salen alineados con tu From. Ver Tracking.

​
Warming: cómo estrenar un dominio

Un dominio nuevo no tiene historial, así que el receptor desconfía por defecto. Warming es subir el volumen de a poco y de forma constante, para que el proveedor acumule señales positivas. Escala de referencia para un dominio nuevo: De ahí en adelante, subir alrededor de 1,4x por día hasta llegar a tu volumen objetivo. Cuanto más alto el objetivo, más largo el ramp: para decenas de miles diarios, calcula cuatro a seis semanas.
Estas cifras son techos, no metas. Superarlas quema el dominio, pero enviar 20 correos por día tampoco lo calienta: sin volumen consistente el proveedor nunca acumula historial y cada envío vuelve a parecer de un remitente desconocido.Durante el warming vigila dos números: rebotes bajo 4% y quejas bajo 0,08%. Si los superas, baja el ritmo e investiga la causa antes de seguir subiendo.
Un detalle que decide el resultado: a quién le envías primero. Empieza por tus contactos más comprometidos —los que abren, responden y pidieron recibirte— y deja la prospección fría para cuando el dominio ya tenga historial. Las aperturas y respuestas tempranas son la señal que construye la reputación.

​
Usa subdominios para aislar el riesgo

Envía lo transaccional y lo de marketing desde subdominios distintos (por ejemplo envios.tudominio.com y noticias.tudominio.com). Si una campaña genera quejas, el daño queda contenido en ese subdominio y tus correos críticos —contraseñas, comprobantes— siguen llegando. El mismo principio aplica si envías en nombre de terceros: un subdominio compartido por varios emisores tiene reputación compartida, y basta uno con listas malas para arrastrar a todos.

​
Cómo probar que tu dominio quedó bien

1

Envía a una casilla externa

Manda una prueba a un Gmail que no sea de tu propio dominio. Un correo que sale de tu dominio y vuelve a tu dominio pasando por un proveedor externo es la firma clásica de la suplantación: Google lo castiga aunque toda la autenticación esté correcta. Es la prueba que más falsos negativos genera.
2

Abre 'Mostrar original'

En Gmail, menú del mensaje → Mostrar original. Ahí buscas tres líneas:
Lo importante es que el dominio del DKIM sea el tuyo, no amazonses.com. Si dice amazonses.com, falta la identidad de dominio: tu correo se firma, pero no a tu nombre.
3

Revisa el 'mediante'

Si Gmail muestra tudominio.com mediante amazonses.com, te falta el Custom MAIL FROM. Llega igual, pero es la línea que hace dudar al lector.
No pruebes con direcciones inventadas. Los rebotes duros provocados a propósito cuentan igual para tu reputación.

​
¿Necesitas una IP dedicada?

Casi con seguridad, no. Es la pregunta que más aparece cuando algo cae en spam, y rara vez es la respuesta. Por defecto tus envíos salen desde un pool de IPs compartidas con reputación ya construida, y te beneficias de ella desde el primer día. Una IP dedicada arranca sin ningún historial: hay que calentarla, y hasta entonces entrega peor. Tiene sentido cuando se cumplen las tres condiciones a la vez:
  • Volumen alto: del orden de cientos de miles de correos al mes.
  • Volumen constante semana a semana. Con envíos esporádicos la IP se “enfría” entre tandas y cada campaña vuelve a partir de cero.
  • Rebotes y quejas bajo control (rebotes bajo 2%). Con una tasa alta, una IP nueva se quema durante el propio warm-up.
Si no cumples las tres, el pool compartido va a entregar mejor. Y en ningún caso una IP dedicada compensa una reputación de dominio dañada: eso se arregla con listas limpias y engagement, no con infraestructura.

​
Próximos pasos