Domain verification confirms that you own the domain you want to send from. SendOps manages this process through AWS SES, which requires DKIM CNAME records in your DNS. Verification succeeds when SES confirms that all three DKIM records are in place and resolve correctly. Most verification problems come down to DNS records that are missing, malformed, or have not propagated yet.
## DNS records not propagating
**Symptom:** You added the DNS records but SendOps still shows the domain as "Pending" after several minutes.
**Cause:** DNS changes take time to propagate across the internet. Propagation depends on the TTL (time to live) of your existing records and your DNS provider's infrastructure.
**Fix:**
1. Wait at least 15 to 30 minutes. Some providers can take up to 72 hours, though most complete within an hour.
2. Verify the records are published correctly by querying DNS directly from your terminal:
3. If the records do not appear in DNS query results, return to your DNS provider and confirm they were saved correctly.
If your domain previously had a high TTL (e.g., 86400 seconds / 24 hours), old cached records may take that long to expire before new records become visible. Consider lowering TTL before making DNS changes, then restoring it afterward.
## DKIM not verifying
**Symptom:** The domain DKIM status shows "Pending" or "Failed" in the Identities table even though you added DNS records.
**Cause:** The DKIM CNAME records are incorrect. Common mistakes include:
- **Trailing dot issue** — some DNS providers automatically append a dot to the record value; others require you to include it. Adding a dot when the provider already appends one creates a double dot (`example.com..`), which fails.
- **Wrong record type** — DKIM records must be CNAME records, not TXT records.
- **Truncated value** — the CNAME target value is long. Some DNS provider interfaces truncate it if you do not paste carefully.
- **Wrong token** — SES generates three unique DKIM tokens for your domain. All three CNAME records must be added using the exact token values shown in the SendOps dashboard, not generic selectors like `selector1`, `selector2`, `selector3`.
**Fix:**
1. Check that all three CNAME records exist. SES generates unique tokens for each domain (not numbered selectors). The record names follow the pattern `{token}._domainkey.example.com` pointing to `{token}.dkim.amazonses.com`.
2. Verify each record with `dig`, using the actual token values from your SendOps dashboard:
```bash
dig CNAME {token1}._domainkey.example.com +short
dig CNAME {token2}._domainkey.example.com +short
dig CNAME {token3}._domainkey.example.com +short
```
3. Compare the output to the values shown in the SendOps Identities page. They must match exactly.
4. If your DNS provider adds a trailing dot automatically, do not include one yourself.
## Wrong DNS provider settings
**Symptom:** Records appear correct in your DNS provider's interface but do not resolve when queried.
Different DNS providers have quirks that can cause issues:
- **Cloudflare** — disable the orange cloud (proxy) for CNAME records used by SES. DKIM CNAMEs must be DNS-only (grey cloud). Cloudflare's proxy rewrites the record and breaks DKIM verification.
- **GoDaddy** — omit the domain name from the "Host" field. For `{token}._domainkey.example.com`, enter only `{token}._domainkey`. GoDaddy appends the domain automatically.
- **Route 53** — include the trailing dot in CNAME target values (e.g., `{token}.dkim.amazonses.com.`). Route 53 treats records as fully qualified domain names.
- **Namecheap** — similar to GoDaddy, enter only the subdomain portion in the "Host" field.
When in doubt, query the actual DNS to see what resolves rather than relying on your provider's UI.
## Domain stuck in "Pending"
**Symptom:** The domain has been in "Pending" for more than 72 hours despite correct DNS records.
**Fix:**
1. Verify the records resolve correctly using `dig` or `nslookup` as shown above.
2. Click the **Refresh** button (the circular arrow icon) on the domain row in the Identities page. This calls SES to re-check DKIM status and updates the domain record.
3. Check the domain status directly in the [AWS SES Console](https://console.aws.amazon.com/sesv2/) under **Identities**. If SES shows it as verified but SendOps does not, try clicking Refresh again — the status should sync.
4. If SES also shows "Pending," try removing the domain from SendOps and re-adding it. This calls SES `CreateEmailIdentity` again, which forces SES to re-check the DNS records. Note that removing a domain from SendOps enqueues a deletion of the identity from SES, so you will need to re-add the DNS records after adding the domain again.
5. Confirm you are checking the correct AWS region — domain verification is region-specific, and your organization's region is set during AWS connection setup.
SendOps tracks several DKIM status values from SES: **Pending** (waiting for DNS verification), **Success** (DKIM verified), **Failed** (verification failed), **Temporary Failure** (transient issue, may resolve on its own), and **Not Started** (DKIM has not been initiated). The domain is marked as verified only when DKIM status reaches Success.
## SPF and DMARC issues
**Symptom:** Emails are delivered but fail SPF or DMARC checks, visible in recipient mail headers or deliverability reports from your email provider.
### SPF
SPF tells receiving servers which mail servers are authorized to send on behalf of your domain. SendOps generates a recommended SPF record when you add a domain: `v=spf1 include:amazonses.com ~all`. Common misconfigurations:
- **Missing SES include** — your SPF record must include `include:amazonses.com`. A typical SPF record looks like: `v=spf1 include:amazonses.com ~all`
- **Multiple SPF records** — a domain must have only one SPF TXT record. If you have multiple, merge them into a single record.
- **Too many lookups** — SPF allows a maximum of 10 DNS lookups. If you have many `include` statements, you may exceed this limit. Use an SPF flattening tool if needed.
### DMARC
DMARC builds on SPF and DKIM to tell receivers what to do when authentication fails. SendOps generates a recommended DMARC record using `p=quarantine` (e.g., `v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com`). Common issues:
- **No DMARC record** — add a TXT record at `_dmarc.example.com`. The SendOps-recommended policy is: `v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com`
- **Strict SPF alignment** — if your DMARC policy uses `aspf=s` (strict SPF alignment), the envelope sender domain must exactly match the From header domain. Consider using `aspf=r` (relaxed) if you encounter alignment failures.
- **Policy too aggressive too soon** — if you are not yet confident all legitimate mail passes authentication, start with `p=none` to monitor, then move to `p=quarantine` (the SendOps default), and finally `p=reject` once everything is verified.
## What's next?
- If your domain is verified but emails are not arriving, see [Deliverability Problems](/troubleshooting/deliverability-problems).
- For a full guide on DNS records, see [DNS Configuration](/domains/dns-configuration).
- If your AWS connection itself is failing, see [Connection Issues](/troubleshooting/connection-issues).