Domain will not verify
Read the per-record DKIM and MAIL FROM statuses, find the DNS record that is missing or wrong, and re-check before the 72-hour window closes.
Verification is driven entirely by what resolves in public DNS, so a domain stuck short of verified points at a record that's absent, misnamed, or altered somewhere between your DNS host and the resolver.
Read the statuses
GET /v1/domains/:id returns the domain's overall status alongside a dkim_status and mail_from_status for each of the two records that gate verification:
curl https://api.mailfully.com/v1/domains/dom_01J1PZ3M8Q7VXCK4T2R9WFH6BD \
-H "Authorization: Bearer mf_live_xxxxxxxxxxxx"{
"status": "partially_verified",
"dkim_status": "pending",
"mail_from_status": "verified"
}verified requires DKIM and MAIL FROM to both report verified; DMARC is advisory and never gates the domain either way. See Verification statuses for what each value of status means.
Check what actually resolves
Query these four lookups, and read what comes back. Verification itself checks only DKIM and MAIL FROM; SPF and DMARC are included here too because a doubled suffix can affect every record type. The first line stands in for all three DKIM CNAMEs: repeat it for each of the three tokens Mailfully returned before concluding DKIM itself is fine.
dig +short <token>._domainkey.mail.acme.com CNAME
dig +short send.mail.acme.com MX
dig +short send.mail.acme.com TXT
dig +short _dmarc.mail.acme.com TXT- An empty answer means the record is either missing at your DNS host or hasn't propagated yet. It doesn't tell you which, so look at the record at the host before you put it down to propagation.
- A wrong target, such as a DKIM CNAME that resolves to anything other than
<token>.dkim.amazonses.com, or an MX that isn'tfeedback-smtp.us-east-1.amazonses.com, means the value at the host doesn't match what Mailfully returned. - A doubled suffix, where the resolved name ends in your zone twice, means the record was entered as a full name at a host that also appends the zone automatically.
The usual causes
| Cause | Affected record | What to do |
|---|---|---|
| Zone name appended twice | Any | Some hosts append your zone to whatever you type in the Name field. Enter the relative form instead of the full name Mailfully returned. |
| CNAME proxied by the DNS host (Cloudflare's orange cloud) | DKIM CNAMEs | A proxied record resolves to the proxy's address, not the DKIM target. Publish these as unproxied, DNS-only records. |
| TXT value split or unquoted | SPF or DMARC TXT | Some hosts wrap or split long TXT strings. Confirm the value matches what Mailfully returned exactly, quotes included where the host expects them. |
| MAIL FROM MX omitted because it looked like it would clash with corporate mail | MAIL FROM MX | It doesn't; see MX record conflicts for why the two never compete. |
| Records added to the wrong zone when the domain is delegated elsewhere | Any | Confirm your DNS is actually managed where you're editing it. |
Re-check
POST /v1/domains/:id/verify re-reads Amazon SES's latest recorded result and re-runs the verification state machine, so it's safe to call repeatedly while you fix records:
curl -X POST https://api.mailfully.com/v1/domains/dom_01J1PZ3M8Q7VXCK4T2R9WFH6BD/verify \
-H "Authorization: Bearer mf_live_xxxxxxxxxxxx"See POST /v1/domains/{id}/verify for the full response shape.
The 72-hour window
The window can elapse while records are still wrong, finalizing the domain as failed or partially_verified. That isn't a dead end: a later re-check that finds both DKIM and MAIL FROM verified still flips the domain to verified, so fix the records and call verify again. See Verification statuses for the full rules.