Skip to main content
Endpoints para gestionar dominios de envío: registro, verificación DNS, estado y perfil de remitente. Base URL: https://api.reallyquickemails.com

Autenticacion

Todos los endpoints de dominios requieren Secret Key:

Flujo de integracion

Si automatizas el alta de dominios desde tu propia aplicación, este es el recorrido completo:
1

Registra el dominio

POST /domains/register retorna los 8 registros DNS en dns_records, ya listos para mostrar.
2

Ofrece la configuración en un clic

GET /domains/{domain}/domain-connect. Si retorna supported: true, redirige al usuario a apply_url y su proveedor crea los registros solo. Si no, muestra los registros para configuración manual.
3

Verifica

POST /domains/{domain}/verify consulta el estado real y actualiza los registros. Llámalo cuando el usuario indique que ya configuró su DNS.
4

Confirma antes de enviar

Recibe domain.verified por webhook, o consulta GET /domains/{domain}/status. El dominio puede enviar cuando can_send: true.
No pollees: escucha el webhook. Cuando un dominio queda verificado, RQE emite domain.verified hacia la URL de webhooks de tu proyecto (y domain.failed si la verificación falla). Se emite una sola vez, en la transición. Ver Webhooks.
Los dominios en pending se re-verifican solos, sin que llames a nada: con frecuencia alta el primer día y espaciándose a medida que el alta envejece. Si tu usuario publica el DNS días después del registro, igual recibirás el webhook. POST /verify sigue siendo útil para respuesta inmediata cuando el usuario dice “ya lo configuré”.
SPF y DMARC se verifican cada 6 horas, no en el momento. Un barrido server-side los resuelve por DNS y escribe su status en dns_records, así que pueden llegarte verified o mismatch sin que llames a nada — no necesitas resolverlos por tu cuenta. Dos salvedades: can_send no los considera (de ellos dependen la entregabilidad y la alineación DMARC, no el permiso de envío), y POST /domains/{domain}/verify reescribe ambos a not_set hasta el siguiente barrido.

POST /domains/register

Registra un dominio de envío: crea la identidad de envío, genera los registros DNS y crea el perfil de remitente.

Request Body

Ejemplo

Respuesta 201 Created
Cada registro DNS incluye: id, record_type (TXT, CNAME o MX), name, value, purpose (ses_verification, dkim, spf, dmarc, return_path), status y ttl_hint (TTL sugerido en segundos). Valores de status: not_set, propagating, mismatch, verified.

Registros DNS generados

El rua del DMARC apunta a un buzón de RQE, no a una casilla tuya: así recibimos los reportes agregados por ti y los puedes ver en el detalle del dominio. El dominio nace en p=none (solo monitoreo) para no mandar a spam el correo legítimo de tus otras herramientas mientras se alinea.
Los nombres son relativos al dominio. Con dominio mitienda.com, el registro _amazonses se configura como _amazonses.mitienda.com. Algunos proveedores agregan el dominio automáticamente, así que solo ingresas _amazonses.
Configura los registros DNS en tu proveedor y llama a POST /domains/{domain}/verify para validar. Ver Deliverability.

Codigos de Error

El alta es idempotente. Si el dominio ya tiene un registro incompleto, la operación lo reconcilia en vez de fallar: responde 201 con reused: true y sus registros DKIM existentes. Reintentar un alta que quedó a medias es seguro y no crea duplicados.

GET /domains/:domain/dns-records

Retorna los registros DNS almacenados con su último estado conocido, sin consultas externas.

Parametros de Ruta

Ejemplo

Respuesta 200 OK
status por registro: not_set, propagating, mismatch o verified. last_checked_at es null hasta la primera verificación con POST /domains/{domain}/verify.
SPF y DMARC no los reporta AWS: los resuelve un barrido propio por DNS cada 6 horas. Tras un POST /verify vuelven a not_set hasta ese barrido.

Codigos de Error


POST /domains/:domain/verify

Consulta el estado DNS directamente en la infraestructura de envío, actualiza el estado almacenado de los registros y retorna si el dominio puede enviar.

Parametros de Ruta

Ejemplo

Respuesta 200 OK
La verificación comprueba tres aspectos:
  1. Verificación de dominio — El registro TXT _amazonses está configurado.
  2. DKIM — Los 3 registros CNAME de DKIM están configurados y propagados.
  3. MAIL FROM — Los registros de Return-Path en send (MX y TXT) están configurados.
Campos clave: can_send es true cuando details.domain_verification y details.dkim_verification son Success (equivalente a verification_status: "verified"). MAIL FROM no es obligatorio para enviar, pero mejora la entregabilidad.

Codigos de Error


GET /domains/:domain/status

Retorna el estado de verificación almacenado, sin consultar la infraestructura de envío. Rápido, ideal para polling desde la interfaz.

Parametros de Ruta

Ejemplo

Respuesta 200 OK
dns_records_summary agrupa los registros por propósito: records_count es cuántos hay y all_verified indica si todos están en status: "verified". can_send es true cuando verification_status es verified. last_verified_at es la última actualización del estado del dominio.

Codigos de Error


GET /domains

Con el parámetro domain busca uno por nombre. Sin él, lista los dominios del proyecto de forma paginada — para reconciliar N dominios en una request en lugar de N consultas.

Query Parameters

Ejemplo — listado

Respuesta 200 OK
Los dominios vienen ordenados por fecha de creación descendente. total es la cantidad total que coincide con el filtro; pagina mientras has_more sea true.

Ejemplo — lookup de uno

Respuesta 200 OK

Codigos de Error


GET /domains/health

Salud de envío de todos tus dominios en una sola llamada: cuál puede enviar, cómo está su autenticación, cuánto envió, cómo rebota y qué hacer con cada uno. Pensado para integradores que operan a varios clientes. Cruza en el servidor lo que de otro modo tendrías que juntar a mano entre GET /domains, los registros DNS y /v1/domain-stats.
El campo issues viene en texto plano y accionable — puedes reenviarlo directo a tu cliente final sin traducirlo.

Query Parameters

Ejemplo

Campos de respuesta

Los dominios vienen ordenados por volumen: primero donde el arreglo rinde más.

Cómo se calcula status

can_send: true con status: critical es el caso que más cuesta. Significa que los emails salen con 200 y nadie ve un error, pero van sin DKIM del dominio del cliente: se firman con el dominio compartido de la plataforma, así que su reputación se mezcla con la de todos y no puede usar reply domain ni tracking domain propios.Aparece cuando el dominio se verificó solo por email (el enlace de un clic) en vez de por DNS, o cuando se envía desde un dominio ajeno como gmail.com — que no se puede autenticar de ninguna forma porque no controlas su DNS.

Codigos de Error


GET /domains/:domain/domain-connect

Configuración de DNS en un clic. Si el proveedor DNS del dominio soporta el estándar Domain Connect, retorna una URL firmada que crea los 8 registros automáticamente: el usuario final solo confirma en la pantalla de su proveedor, sin copiar nada a mano. Úsalo justo después de POST /domains/register. Si el proveedor no lo soporta, cae de vuelta a mostrar los registros de dns_records para configuración manual.
Cobertura medida sobre dominios reales: alrededor del 50% soporta Domain Connect. Cloudflare está operativo. Siempre debes manejar el caso supported: false.

Parametros de Ruta

Query Parameters

redirect_uri solo acepta hosts de ReallyQuickEmails (app.reallyquickemails.com) y de desarrollo local. Si envías el dominio de tu propia aplicación, la respuesta es supported: false con reason: "invalid_redirect_uri". Omite el parámetro: la apply_url sigue siendo válida, solo que el usuario termina en la página de su proveedor DNS en vez de volver a tu aplicación.

Ejemplo

Respuesta 200 OK — proveedor compatible
Redirige al usuario a apply_url. Al confirmar, su proveedor crea los registros. Después llama a POST /domains/{domain}/verify para confirmar el estado. Respuesta 200 OK — proveedor no compatible

Campos de respuesta

Valores de reason

supported: false no es un error: la respuesta es 200 OK. Muestra los registros DNS de GET /domains/{domain}/dns-records para que el usuario los configure manualmente.

Codigos de Error


POST /domains/:domain/recreate

Elimina y recrea la identidad de envío del dominio. Útil cuando DKIM queda atascado en estado fallido.

Parametros de Ruta

Ejemplo

Respuesta 200 OK
Conserva el dominio y el perfil de remitente, regenera los registros DNS y reinicia verification_status a pending. Luego llama a POST /domains/{domain}/verify. Si los registros ya estaban propagados, la verificación puede completarse en segundos.

Codigos de Error


DELETE /domains/:domain

Elimina el dominio de la infraestructura de envío y desactiva su perfil de remitente.

Parametros de Ruta

Ejemplo

Respuesta 200 OK
El mismo dominio puede registrarse de nuevo más adelante.
Tras eliminarlo, deberás registrar el dominio y configurar los registros DNS de nuevo para enviar desde él.

Codigos de Error


PUT /domains/:domain/sender

Actualiza el perfil de remitente asociado a un dominio.

Parametros de Ruta

Request Body

Ejemplo

Respuesta 200 OK
El campo reply_email se guarda pero no se incluye en la respuesta.

Codigos de Error


Reply domain (Reply-To limpio, sin token)

Configura un dominio de reply branded por proyecto (reply.tudominio.com) para que el Reply-To de los envíos API salga limpio —localpart@reply.tudominio.com— en vez del token codificado. El envío y la resolución de las respuestas son automáticos una vez verificado. Sin reply domain configurado, se usa el token de siempre. Cómo afecta el webhook: Webhooks · reply domain.
Modelo para integradores (varios reply domains por proyecto). El reply domain pertenece al proyecto de la API key con la que llamas, y un proyecto puede tener varios: cada envío resuelve el que corresponde al dominio del remitente.Para ofrecer reply limpio a tus propios clientes desde un mismo proyecto, registra el dominio de cada uno con tu key: POST /domains/reply { "domain": "phrasso.com" } y las respuestas de ese cliente llegan a nombre@reply.phrasso.com. Para verificar uno concreto, pasa domain en el body de POST /domains/reply/verify.También puedes darle un proyecto propio a cada cliente, con su key — ver Partner quickstart para cuándo conviene cada modelo.

POST /domains/reply

Registra el reply domain: verifica la identidad en SES para recibir y devuelve los 2 registros DNS que el cliente debe publicar.

Request Body

Respuesta 201 Created
El cliente publica esos 2 registros (TXT de verificación SES + MX que enruta las respuestas al inbound de RQE). Luego llama a verify.

POST /domains/reply/verify

Consulta SES y marca el reply domain como verified cuando el TXT ya propagó. A partir de ahí, los envíos API del proyecto salen con el Reply-To limpio.
Respuesta 200 OK
reply_domain_status: pending (aún sin verificar) · verified (en uso) · failed. can_receive es true cuando SES puede recibir en el dominio.

GET /domains/reply

Estado y registros DNS del reply domain del proyecto. reply_domain: null si no hay ninguno configurado.

DELETE /domains/reply

Quita el reply domain (lo saca del ruteo de inbound, borra la identidad SES y limpia el proyecto). Los envíos vuelven al Reply-To con token.

Envuelve los links de click-tracking con tu propio subdominio (links.tudominio.com) en vez del compartido de RQE. Aísla la reputación del tracking y alinea los links con tu From. Se configura con un solo registro CNAME.
El tracking domain se cambia, nunca se borra: los links de los emails ya enviados dependen de que el dominio siga resolviendo. Por eso no hay endpoint DELETE — para migrar, publica el CNAME nuevo y llama a PUT con el nuevo dominio.
Estos endpoints cuelgan de /api/projects/:projectId. El :projectId es el UUID de tu proyecto —el project_id que devuelve cualquier respuesta de envío— y debe coincidir con el proyecto de tu API key.

GET /api/projects/:projectId/tracking-domain

Estado actual del tracking domain del proyecto.
Respuesta 200 OK
domain, status y cname son null si no hay ninguno configurado.

PUT /api/projects/:projectId/tracking-domain

Setea o cambia el tracking domain. Queda en pending hasta verificar. Debe ser un subdominio propio (ej. links.tudominio.com), nunca un dominio de RQE.

Request Body

Respuesta 200 OK
Publica el CNAME links.tudominio.com → track.reallyquickemails.com en tu DNS y luego llama a verify.

POST /api/projects/:projectId/tracking-domain/verify

Chequea el DNS y marca verified si el CNAME ya resuelve a nuestro target (soporta el CNAME flattening de Cloudflare comparando registros A).
Respuesta 200 OK
verified: false con status: "pending" si el DNS aún no propagó (detail explica el motivo). Responde 404 NO_DOMAIN si no hay tracking domain configurado.
Alternativa a la verificación de dominio completo: verifica un email individual como remitente sin configurar DNS. Se envía un email de verificación; al hacer clic en el enlace, el email queda verificado para enviar.
Es más rápida pero no incluye DKIM/SPF. Para mejor deliverability, verifica el dominio completo.
Cuando el estado cambia (de pending a verified o failed), RQE emite el webhook sender.verified o sender.failed. Ver Webhooks.

POST /domains/verify-email

Inicia la verificación de un email como remitente enviándole un enlace de verificación.

Request Body

Ejemplo

Respuesta 201
El remitente recibirá un email con un enlace. Al hacer clic, su email queda verificado.

Errores


GET /domains/verify-email/status

Consulta el estado de verificación de un email en la infraestructura de envío en tiempo real.

Query Parameters

Ejemplo

Respuesta 200
sender_profile puede ser null si no existe un perfil de remitente activo. can_send es true cuando verification_status es verified.

Estados de verificacion

Errores


POST /domains/verify-email/resend

Reenvía el email de verificación al remitente. Solo válido mientras la verificación está en pending.

Request Body

Ejemplo

Respuesta 200

Errores


DELETE /domains/verify-email

Elimina un email verificado como remitente; el mismo email puede registrarse de nuevo más adelante.

Query Parameters

Ejemplo

Respuesta 200

Errores