Deliverability server test

Check how a domain is set up to send mail. The server test reads a domain's DNS records — MX, SPF, DMARC, reverse DNS and, when you supply a selector, DKIM — and returns a plain-language fix for anything weak. It is read-only: no mail is sent, and no mailbox is contacted beyond a coarse reachability probe.

Available on the Clean Pro plan and above. It deducts zero credits and is subject to the shared per-key rate limit. Results are cached per domain and selector for about 15 minutes, so repeated checks of the same domain do not re-query DNS.

What it checks

Check	What it looks at
MX	Whether mail servers are published, and their priority order.
SPF	Whether a single valid `v=spf1` record exists, and the common faults: more than one record, a `+all` that authorises the whole internet, and exceeding the ten-lookup limit.
DMARC	Whether a DMARC record exists, the policy in force (`none` / `quarantine` / `reject`), and whether a `rua` report address is set.
DKIM	Only when you supply a selector: whether a public key is published at `<selector>._domainkey.<domain>`, and whether it has been revoked.
Reachability	A coarse SMTP liveness signal via the same validation path used for email verification. Best-effort — the MX and DNS findings are the authoritative signals.
Reverse DNS	Whether the domain's primary mail host has a `PTR` record, and whether that name forward-confirms — resolves back to the same IP address. A missing PTR, or one that does not forward-confirm, is a routine cause of mail being rejected or spam-foldered.

Statuses

Status	Meaning
fail	A real problem that stops or endangers mail (for example no MX or no SPF). Fix it.
warn	A weakness worth fixing (for example no DMARC, or a DKIM key missing for the selector you gave).
pass	Configured correctly. No action needed.
info	Informational — for example, a DKIM selector is required to check DKIM.
unknown	The lookup was inconclusive (throttled or temporarily unavailable). Re-run in a moment.

The report's overall is the worst status across the checks. Every failing or weak check carries a remediation line telling you exactly what to publish.

API

POST /v1/server-test — authenticate with your API key as a Bearer token (see Authentication).

curl -X POST https://ratifai.app/hook/FlowClick/FlowVerify/v1/server-test \
  -H "Authorization: Bearer vk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"domain":"example.com","selector":"selector1"}'

The selector is optional; omit it to skip the DKIM check. The response is a report:

{
  "request_id": "req_...",
  "cached": false,
  "result": {
    "domain": "example.com",
    "selector": "selector1",
    "overall": "warn",
    "checks": [
      { "check": "mx", "status": "pass", "title": "MX records present",
        "detail": "...", "remediation": "..." },
      { "check": "dmarc", "status": "warn", "title": "No DMARC record",
        "detail": "...", "remediation": "Publish a TXT record at _dmarc.example.com ..." },
      { "check": "reverse_dns", "status": "pass", "title": "Reverse DNS present and forward-confirmed",
        "detail": "...", "remediation": "No action needed." }
    ],
    "reverse_dns": { "status": "pass", "host": "mail.example.com", "ip": "203.0.113.10",
      "ptr": "mail.example.com", "forward_confirmed": true }
  }
}

A domain below the Clean Pro plan receives 403 forbidden; a missing or malformed domain receives 400 invalid_request. See Errors.

Reverse DNS

Reverse DNS (a sending host's PTR record) is one of the most consequential deliverability signals: a mail host whose IP has no PTR, or whose PTR does not match its forward record, is treated as suspicious by most receiving mail servers and is a routine cause of rejection or spam-foldering. The test resolves the domain's primary (lowest-preference) mail host, looks up the PTR for its IP address, and forward-confirms it — resolving the PTR name back to an address and checking it matches.

Present and forward-confirmed — a clean pass; this is what receiving servers check for.
No PTR record — reverse DNS is set by whoever owns the IP address, so this is a request to your hosting or email provider, not a change you make in your own DNS.
Does not forward-confirm — the PTR name and the address it resolves to are both shown so you can see the mismatch.

A throttled or temporarily-unavailable lookup is reported as “could not check”, distinct from “no record”. Both IPv4 and IPv6 mail hosts are covered.

Domain verification

Before VerifAi will hold or show any per-domain report data for a domain, a tenant must prove they control it. On the Verified domains page, claim a domain and we issue a single token to publish as a TXT record:

Host: _verifai.<your-domain>
Value: verifai-verification=<token>

Click Verify and we look up that one record. A throttled or temporarily-unavailable lookup is reported as “could not check yet”, never as a failure. Verification is per tenant: two organisations can verify the same domain independently. We re-check verified domains daily; if the record is missing for more than 7 days the domain is marked unverified — a single transient DNS failure never removes it, and your data is never deleted on a lapse.

DMARC readiness

When you run the server test in the console, the result includes a DMARC readiness panel that turns the DMARC finding into the exact record to publish:

No DMARC record — the exact v=DMARC1; p=none; rua=… record to add. Publishing p=none changes nothing about delivery; it only starts the reporting.
A record with no rua — the exact edited record, preserving your current policy.
A record that already sets rua — a note that rua accepts a comma-separated list, so you can add a destination without disturbing the first.

VerifAi does not yet ingest DMARC aggregate reports — today, publishing rua sends them to a mailbox you choose, which you read yourself.

In the app

The same test is available in the console on the Deliverability page, with the results laid out check by check.

← All docs