Skip to main content

Domain Verification Troubleshooting

Domain verification fails for predictable reasons. This page walks through the diagnosis tree.

The three records​

Mailtarget verifies three DNS records before a sending domain is usable:

  1. SPF (TXT) authorizing Mailtarget to send.
  2. DKIM (TXT on a Mailtarget-issued selector) signing outbound messages.
  3. Tracking domain (CNAME on a subdomain) so click and open links resolve under your domain.

If any record fails, verification fails. Read Sending Domains for the full record format.

Diagnose with dig​

Always confirm with dig before opening a support ticket.

dig +short TXT yourdomain.com | grep spf1
dig +short TXT <selector>._domainkey.yourdomain.com
dig +short CNAME track.yourdomain.com

If any returns empty or wrong, that is the failure. Fix at the DNS provider, not at Mailtarget.

Common failures​

"SPF record not found"​

Causes:

  • Record published on the wrong host. SPF goes on the apex.
  • Record published as legacy SPF type instead of TXT. Use TXT.
  • Multiple SPF records on the same host. Only one TXT may start with v=spf1.

Fix: publish one TXT record with both existing senders and the Mailtarget include.

"SPF lookup limit exceeded"​

SPF allows ten DNS lookups. Each include: and redirect= counts. Five or more email vendors usually hit the limit.

Fix: audit the include chain; consolidate or remove unused vendors.

"DKIM record truncated"​

Some DNS providers cap TXT record values at 255 characters. DKIM keys are longer.

Fix: use a provider that supports long TXT, or split into multiple quoted strings inside one record (NOT multiple records).

"Tracking domain CNAME does not resolve"​

Causes:

  • CNAME proxied at Cloudflare (orange cloud). Proxying breaks tracking.
  • Apex flattening of the CNAME by the DNS provider.
  • CNAME pointed at a typo'd target.

Fix: set CNAME to DNS-only (gray cloud); use a subdomain not apex; copy target verbatim.

Verification fails after DNS change​

Causes:

  • DNS propagation incomplete.
  • DNS provider caching the wrong response.
  • Local resolver caching.

Fix: wait. Confirm with dig @8.8.8.8 (Google) and dig @1.1.1.1 (Cloudflare). If both show right value, retry verification.

Indonesian DNS providers (Niagahoster, Rumahweb, IDwebhost)​

Known issues:

  • Underscores stripped from labels (breaks DKIM selectors).
  • Long TXT records truncated silently.
  • Auto-transforms applied to record values.

Fix: contact provider support; ask for the record published verbatim with no transformation.

Re-verification flow​

After fixing DNS:

  1. Wait for propagation. Confirm with dig @8.8.8.8 from a clean shell.
  2. Click Verify in the dashboard.
  3. If still fails, dashboard error message points at the specific record.
  4. If dashboard says verified but DKIM signing fails on real sends, wait 5 minutes for key rollout, then resend.

When to open a support ticket​

Open when:

  • All three records resolve correctly via dig from multiple resolvers.
  • Dashboard still fails after 30 minutes.
  • Dashboard error generic with no specific record name.

Include: domain name, expected DNS values, dig output from Google 8.8.8.8 and Cloudflare 1.1.1.1.