If POST /v2/email_domains/{domain_id}/verify is not returning a verified status, the cause is almost always in the DNS records — either they have not finished propagating, or one of them does not exactly match what Telnyx expects. This guide walks through the real, common causes in order, so you can find the one that applies to you.

Start here every time: run verify and read the per-record status in the response. The verify response tells you which records passed and which did not, so you can go straight to the one that needs fixing instead of guessing.

The most common cause. A required ownership or DKIM record is missing, or its host or value contains a small mistake — an extra space, a missing character, or a transposed value. MX is also required when inbound email is enabled, but not for a send-only domain.

Even a single wrong character in a DKIM or ownership value will cause verification to fail, so this is always worth double-checking first.

DNS changes are not instant. After you add or edit a record, it can take anywhere from a few minutes to a few hours (occasionally up to 24–48 hours, depending on your provider's TTL settings) before Telnyx can see it.

If a record looks correct and simply is not being seen yet, propagation delay is the likely reason — patience and a retry usually resolve it.

DKIM values are long — often longer than a single DNS TXT string allows. Some registrar interfaces silently cut off a long value, or split it into multiple quoted chunks and then reassemble it incorrectly.

A DKIM record that is even slightly truncated will not validate, so this is the first thing to check when the ownership record and any applicable MX record pass but DKIM does not.

Different DNS providers expect the host field in different formats, and mixing them up produces an invalid host. The classic mistake is the domain appearing twice:

This happens when a provider automatically appends your domain to whatever you type, but you entered the full host anyway. To fix it:

SPF is designed so a domain has one SPF record. If you already send mail through another provider, you may already have an SPF record — and adding a second one, or leaving two in place, breaks SPF entirely.

For example, an existing Google Workspace SPF record could become v=spf1 include:_spf.google.com include:spf.telnyx.com ~all. SPF is recommended rather than strictly required for verification, but getting it wrong hurts deliverability, so it is worth fixing properly.

Verification is not permanent. If a previously verified domain has required DNS drift, Telnyx can mark it degraded. Sends then fail with public error code 10007 and the detail Domain is in a degraded state. The service uses domain_degraded internally, but that is not the public error code. Telnyx periodically re-checks verified domains.

Common triggers:

To recover, re-fetch the expected records with GET /v2/email_domains/{domain_id}/dns_records. Restore required ownership and DKIM records and, when inbound email is enabled, MX. Wait for propagation, then run verify again. Once the required records match, the domain returns to verified and sending resumes. Repair SPF or DMARC problems for deliverability, but changes to those optional records alone do not degrade the domain or block sending.