Skip to main content
Endpoints for managing sending domains: registration, DNS verification, status, and sender profile. Base URL: https://api.reallyquickemails.com

Authentication

All domain endpoints require a Secret Key:

Integration flow

If you’re automating domain onboarding from your own application, here’s the full path:
1

Register the domain

POST /domains/register returns all 8 DNS records in dns_records, ready to display.
2

Offer one-click setup

GET /domains/{domain}/domain-connect. If it returns supported: true, redirect the user to apply_url and their provider creates the records automatically. Otherwise, show the records for manual setup.
3

Verify

POST /domains/{domain}/verify checks the real status and updates the records. Call it when the user says they’ve configured their DNS.
4

Confirm before sending

Receive domain.verified via webhook, or check GET /domains/{domain}/status. The domain can send when can_send: true.
Don’t poll — listen for the webhook. When a domain becomes verified, RQE emits domain.verified to your project’s webhook URL (and domain.failed if verification fails). It fires once, on the transition. See Webhooks.
Pending domains are re-checked on their own, with no call from you: frequently on the first day, spacing out as the registration ages. If your user publishes their DNS days after registering, you still get the webhook. POST /verify remains useful for an immediate response when the user says “I’ve set it up”.
SPF and DMARC are checked every 6 hours, not on demand. A server-side sweep resolves them over DNS and writes their status into dns_records, so they can come back verified or mismatch without you calling anything — you no longer need to resolve them yourself. Two caveats: can_send ignores them (they drive deliverability and DMARC alignment, not sending permission), and POST /domains/{domain}/verify resets both to not_set until the next sweep.

POST /domains/register

Registers a sending domain: creates the sending identity, generates the DNS records, and creates the sender profile.

Request Body

Example

Response 201 Created
Each DNS record includes: id, record_type (TXT, CNAME or MX), name, value, purpose (ses_verification, dkim, spf, dmarc, return_path), status, and ttl_hint (suggested TTL in seconds). status values: not_set, propagating, mismatch, verified.

Generated DNS records

The DMARC rua points to an RQE mailbox rather than one of your own: that’s how we receive your aggregate reports and surface them on the domain detail page. Domains start at p=none (monitoring only) so legitimate mail from your other tools isn’t sent to spam while alignment settles.
Names are relative to the domain. With domain mystore.com, the _amazonses record is configured as _amazonses.mystore.com. Some providers append the domain automatically, so you only enter _amazonses.
Configure the DNS records with your provider and call POST /domains/{domain}/verify to validate. See Deliverability.

Error Codes

Registration is idempotent. If the domain already has an incomplete record, the operation reconciles it instead of failing: it responds 201 with reused: true and the existing DKIM records. Retrying a half-finished registration is safe and won’t create duplicates.

GET /domains/:domain/dns-records

Returns the stored DNS records with their last known status, without external lookups.

Path Parameters

Example

Response 200 OK
Per-record status: not_set, propagating, mismatch, or verified. last_checked_at is null until the first verification with POST /domains/{domain}/verify.
AWS does not report SPF or DMARC: a sweep of ours resolves them over DNS every 6 hours. After a POST /verify they go back to not_set until that sweep.

Error Codes


POST /domains/:domain/verify

Checks the DNS status directly against the sending infrastructure, updates the stored status of the records, and returns whether the domain can send.

Path Parameters

Example

Response 200 OK
Verification checks three things:
  1. Domain verification — The _amazonses TXT record is configured.
  2. DKIM — All 3 DKIM CNAME records are configured and propagated.
  3. MAIL FROM — The Return-Path records on send (MX and TXT) are configured.
Key fields: can_send is true when details.domain_verification and details.dkim_verification are Success (equivalent to verification_status: "verified"). MAIL FROM is not required to send, but it improves deliverability.

Error Codes


GET /domains/:domain/status

Returns the stored verification status, without querying the sending infrastructure. Fast, ideal for polling from the interface.

Path Parameters

Example

Response 200 OK
dns_records_summary groups the records by purpose: records_count is how many there are and all_verified indicates whether all of them are status: "verified". can_send is true when verification_status is verified. last_verified_at is the last update to the domain’s status.

Error Codes


GET /domains

With the domain parameter, looks up one by name. Without it, lists the project’s domains with pagination — so you can reconcile N domains in one request instead of N lookups.

Query Parameters

Example — listing

Response 200 OK
Domains come ordered by creation date, newest first. total is the full count matching the filter; keep paginating while has_more is true.

Example — single lookup

Response 200 OK

Error Codes


GET /domains/health

Sending health for all your domains in a single call: which one can send, how its authentication looks, how much it sent, how it bounces, and what to do about each. Built for integrators running several customers. It joins server-side what you’d otherwise piece together by hand across GET /domains, the DNS records and /v1/domain-stats.
The issues field comes back as plain, actionable text — you can forward it straight to your end customer without rewriting it.

Query Parameters

Example

issues strings are returned in Spanish today. Match on status and auth.* rather than on the message text.

Response fields

Domains come back sorted by volume: the ones where fixing pays off most come first.

How status is computed

can_send: true alongside status: critical is the costliest case. It means email goes out with a 200 and nobody sees an error, but it ships without DKIM on the customer’s domain: it gets signed with the platform’s shared domain, so their reputation blends with everyone else’s and they can’t use their own reply domain or tracking domain.This shows up when a domain was verified by email only (the one-click link) instead of by DNS, or when sending from a domain you don’t own such as gmail.com — which can’t be authenticated at all, since you don’t control its DNS.

Error Codes


GET /domains/:domain/domain-connect

One-click DNS setup. If the domain’s DNS provider supports the Domain Connect standard, this returns a signed URL that creates all 8 records automatically: the end user just confirms on their provider’s screen, with nothing to copy by hand. Use it right after POST /domains/register. If the provider doesn’t support it, fall back to showing the dns_records for manual setup.
Measured coverage across real domains: roughly 50% support Domain Connect. Cloudflare is live. Always handle the supported: false case.

Path Parameters

Query Parameters

redirect_uri only accepts ReallyQuickEmails hosts (app.reallyquickemails.com) and local development hosts. If you send your own application’s domain, the response is supported: false with reason: "invalid_redirect_uri". Omit the parameter instead: the apply_url still works, the user just lands on their DNS provider’s page rather than returning to your app.

Example

Response 200 OK — supported provider
Redirect the user to apply_url. Once they confirm, their provider creates the records. Then call POST /domains/{domain}/verify to confirm the status. Response 200 OK — unsupported provider

Response Fields

reason values

supported: false is not an error — the response is still 200 OK. Show the DNS records from GET /domains/{domain}/dns-records so the user can configure them manually.

Error Codes


POST /domains/:domain/recreate

Deletes and recreates the domain’s sending identity. Useful when DKIM gets stuck in a failed state.

Path Parameters

Example

Response 200 OK
It keeps the domain and sender profile, regenerates the DNS records, and resets verification_status to pending. Then call POST /domains/{domain}/verify. If the records were already propagated, verification can complete in seconds.

Error Codes


DELETE /domains/:domain

Removes the domain from the sending infrastructure and deactivates its sender profile.

Path Parameters

Example

Response 200 OK
The same domain can be registered again later.
After deleting it, you will need to register the domain and configure the DNS records again to send from it.

Error Codes


PUT /domains/:domain/sender

Updates the sender profile associated with a domain.

Path Parameters

Request Body

Example

Response 200 OK
The reply_email field is saved but not included in the response.

Error Codes


Reply domain (clean Reply-To, token-less)

Configure a branded reply domain per project (reply.yourdomain.com) so the Reply-To of API sends comes out clean —localpart@reply.yourdomain.com— instead of the encoded token. Sending and reply resolution are automatic once verified. Without a reply domain configured, the usual token is used. How it affects the webhook: Webhooks · reply domain.
Model for integrators (several reply domains per project). The reply domain belongs to the project of the API key you call with, and a project can have several: each send resolves the one matching the sender’s domain.To offer clean replies to your own clients from a single project, register each one’s domain with your key: POST /domains/reply { "domain": "phrasso.com" } and that client’s replies arrive at name@reply.phrasso.com. To verify a specific one, pass domain in the body of POST /domains/reply/verify.You can also give each client their own project and key — see Partner quickstart for when each model fits.

POST /domains/reply

Registers the reply domain: verifies the identity in SES for receiving and returns the 2 DNS records the client must publish.

Request Body

Response 201 Created
The client publishes those 2 records (SES verification TXT + MX that routes replies to RQE’s inbound). Then calls verify.

POST /domains/reply/verify

Queries SES and marks the reply domain verified once the TXT has propagated. From then on, the project’s API sends go out with the clean Reply-To.
Response 200 OK
reply_domain_status: pending (not yet verified) · verified (in use) · failed. can_receive is true when SES can receive for the domain.

GET /domains/reply

Status and DNS records of the project’s reply domain. reply_domain: null if none is configured.

DELETE /domains/reply

Removes the reply domain (takes it out of inbound routing, deletes the SES identity, clears the project). Sends revert to the token Reply-To.

Wrap click-tracking links with your own subdomain (links.yourdomain.com) instead of RQE’s shared one. Isolates tracking reputation and aligns links with your From. Configured with a single CNAME record.
The tracking domain is changed, never deleted: links in already-sent emails depend on the domain still resolving. That’s why there’s no DELETE endpoint — to migrate, publish the new CNAME and call PUT with the new domain.
These endpoints live under /api/projects/:projectId. The :projectId is your project UUID —the project_id returned by any send response— and must match the project of your API key.

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

Current tracking domain status for the project.
Response 200 OK
domain, status and cname are null if none is configured.

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

Set or change the tracking domain. Stays pending until verified. Must be a subdomain you own (e.g. links.yourdomain.com), never an RQE domain.

Request Body

Response 200 OK
Publish the CNAME links.yourdomain.com → track.reallyquickemails.com in your DNS, then call verify.

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

Checks DNS and marks verified once the CNAME resolves to our target (supports Cloudflare CNAME flattening by comparing A records).
Response 200 OK
verified: false with status: "pending" if DNS hasn’t propagated yet (detail explains why). Returns 404 NO_DOMAIN if no tracking domain is configured.
An alternative to full domain verification: verify an individual email as a sender without configuring DNS. A verification email is sent; clicking the link verifies the email for sending.
It is faster but does not include DKIM/SPF. For better deliverability, verify the full domain.
When the status changes (from pending to verified or failed), RQE emits the sender.verified or sender.failed webhook. See Webhooks.

POST /domains/verify-email

Starts the verification of an email as a sender by sending it a verification link.

Request Body

Example

Response 201
The sender will receive an email with a link. Clicking it verifies their email.

Errors


GET /domains/verify-email/status

Queries the verification status of an email against the sending infrastructure in real time.

Query Parameters

Example

Response 200
sender_profile can be null if no active sender profile exists. can_send is true when verification_status is verified.

Verification statuses

Errors


POST /domains/verify-email/resend

Resends the verification email to the sender. Only valid while verification is pending.

Request Body

Example

Response 200

Errors


DELETE /domains/verify-email

Deletes an email verified as a sender; the same email can be registered again later.

Query Parameters

Example

Response 200

Errors