Deliverability y autenticación
Cómo ReallyQuickEmails autentica tus envíos (SPF, DKIM, DMARC, MAIL FROM custom) y por qué importa para llegar al inbox y no a spam.
Esta página explica los mecanismos detrás de "¿llega al inbox?". No es un tutorial paso a paso (para eso ver Dominios) — es la teoría que necesitás 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:
| Chequeo | Qué verifica | Quién lo configura |
|---|---|---|
| SPF | El servidor que envió el email tiene permiso para enviar desde tu dominio | DNS de tu dominio |
| DKIM | El email fue firmado criptográficamente con una clave que publicaste en DNS | DNS + RQE genera y firma |
| DMARC | Política sobre qué hacer si SPF/DKIM fallan (none/quarantine/reject) | DNS de tu dominio |
| MAIL FROM domain | El "envelope sender" (Return-Path) coincide con tu dominio, no con amazonses.com | DNS + SES configurado |
Cuando los 4 pasan, tu email tiene alignment estricto y la deliverability sube significativamente.
SPF (Sender Policy Framework)
Un record TXT en tu DNS que lista qué servidores pueden enviar emails desde tu dominio. Cuando RQE/SES envían un email desde noreply@tudominio.com, Gmail consulta el SPF de tudominio.com y verifica que SES esté en la lista.
Ejemplo de record:
tudominio.com. TXT "v=spf1 include:amazonses.com -all"-all (hard fail): cualquier servidor no listado se rechaza. Es lo recomendado — cualquier flexibilidad acá es spoofeable.
Si ya tenés SPF configurado para otro proveedor (Mailgun, Sendgrid, Google Workspace), tenés que mergear los include: en un solo record, no agregar otro TXT. Múltiples records SPF rompen la verificación.
DKIM (DomainKeys Identified Mail)
Una firma criptográfica del contenido del email, hecha con una clave privada de RQE. Tu dominio publica la clave pública en DNS via 3 records CNAME. Cuando el email llega, Gmail toma la firma del header, descarga la clave pública del CNAME, y valida.
selector1._domainkey.tudominio.com. CNAME selector1.dkim.amazonses.com.
selector2._domainkey.tudominio.com. CNAME selector2.dkim.amazonses.com.
selector3._domainkey.tudominio.com. CNAME selector3.dkim.amazonses.com.DKIM también permite que tu dominio aparezca en el signed-by: del header en Gmail web, lo cual es señal de legitimidad para el usuario final.
DMARC
La política que indica qué debería pasar si SPF o DKIM fallan. Es el más fuerte de los 3 en términos de protección anti-spoofing.
| Política | Qué hace si falla SPF/DKIM | Cuándo usar |
|---|---|---|
p=none | Solo reporta, no rechaza | Primera implementación, mientras analizás reportes |
p=quarantine | Manda a spam | Después de 1–2 semanas de none sin issues |
p=reject | Rechaza el email completamente | Producción estable, máxima protección |
Ejemplo:
_dmarc.tudominio.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@tudominio.com; pct=100"pct=100 aplica la política al 100% del tráfico. Empezar con pct=10 y subir gradualmente es una práctica común.
Reportes DMARC
Si pasás rua=, los servidores receptores te mandan reportes diarios con qué % de tu tráfico pasó SPF/DKIM. Útil para detectar suplantación o configuraciones rotas. Hay servicios gratuitos para parsear los reportes (Postmark, dmarcian).
MAIL FROM domain (custom)
Cuando enviás un email vía SES 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.
Configurando un Custom MAIL FROM domain (típicamente bounces.tudominio.com), el mailed-by: pasa a ser tu dominio y SPF queda alineado strict.
Requiere 2 DNS records adicionales:
bounces.tudominio.com. MX 10 feedback-smtp.us-east-1.amazonses.com.
bounces.tudominio.com. TXT "v=spf1 include:amazonses.com -all"Custom MAIL FROM no es estrictamente necesario — los emails llegan igual sin él. Pero la mejora marginal de deliverability puede ser ~5–10% en clientes estrictos como ProtonMail o Outlook empresarial. Recomendado para volúmenes grandes.
El proceso de verificación en RQE
Registrar el dominio
POST /domains/register con { domain: "tudominio.com" }. RQE genera los 7 records DNS y los devuelve en la respuesta. Ver Dominios.
Configurar los 7 records
En tu proveedor DNS (Cloudflare, GoDaddy, Route 53, etc):
- 1 TXT verificación SES
- 3 CNAME DKIM
- 1 TXT SPF (mergear con existente si aplica)
- 1 TXT DMARC
- 1 CNAME Return-Path (Custom MAIL FROM)
Esperar propagación
5–10 minutos en Cloudflare/Route 53. Hasta 48h en proveedores lentos.
Verificar
POST /domains/:domain/verify chequea cada record. Cuando los 7 pasan, can_send: true y podés mandar emails desde *@tudominio.com.
Por qué los emails llegan a spam (más allá de la auth)
Aunque la auth técnica esté OK, hay factores reputacionales:
| Factor | Impacto |
|---|---|
| Dominio nuevo (< 30 días) | Alto — hay que hacer warming |
| Tasa de bounces > 2% | Alto — limpia tu lista regularmente |
| Tasa de complaints > 0.1% | Crítico — Gmail/Outlook degradan reputación rápido |
Sin List-Unsubscribe header | Alto — RQE lo agrega automático en campañas; en transaccionales requiere custom_headers |
| Contenido sospechoso | Medio — palabras como "GRATIS", "URGENTE" en mayúsculas, ratio HTML/texto malo |
| Listas compradas | Crítico — la mayoría son spam traps |
Warming
Si tu dominio es nuevo o no envió en > 60 días, hay que hacer warming gradual: día 1 ~50k emails, día 2 ~75k, día 3+ resto. El modo por lotes automatiza esto.
Próximos pasos
- Dominios — endpoints para registrar y verificar.
- Tracking — cómo funciona el open/click tracking.
- FAQ — ¿por qué van a spam? — checklist práctico.