My DNS Status Never Turns Green

DNS verification on TrekMail checks several records per domain (MX, SPF, DKIM, DMARC, plus recommended ones like MTA-STS and TLS-RPT). If any required record isn't right, the domain stays amber or pending. This guide walks through every reason that happens — in order of frequency.

How fast should it propagate?

Most TrekMail DNS checks pass within 5-15 minutes after you publish the records at your DNS provider. The slowest providers (small registrars, older ccTLDs) can take up to 60 minutes. After 60 minutes with status still amber, the issue is never "still propagating" — it's a misconfiguration.

The two most common timing-related mistakes:

• Checking too early. Saving records at GoDaddy/Namecheap/etc. and refreshing the TrekMail Domains page 30 seconds later. Give it a minute or three.
• Caching at your local resolver. Your home machine may have cached "no SPF record" for an hour. TrekMail's checker queries authoritative servers, not your local cache, so we'll see the new records as soon as they publish — but dig from your laptop may lie to you for up to an hour.

Required records — full reference

If any of these is wrong, the domain won't go fully green:

Recommended (won't block status but improves deliverability):

Optional client-autoconfig CNAMEs (autoconfig, autodiscover) speed up email-app setup but don't affect mail delivery.

Check 1 — Duplicate SPF records

The #1 cause of red status: you have two TXT records starting with v=spf1 at the apex. This is invalid per the SPF spec — mail servers consult the first one they find and discard subsequent ones, and the behaviour is undefined across providers. Some receivers reject mail outright if they detect duplicate SPFs.

Symptom: Both records show in your DNS, but TrekMail's check still flags SPF as not configured.

Fix: Merge them into one. If you have:

v=spf1 include:_spf.google.com ~all
v=spf1 include:spf.trekmail.net -all

Replace with:

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

Note that -all (hard fail) is what TrekMail recommends. If your other service requires ~all (soft fail) at the end, use ~all. You can only have one terminator.

Maximum 10 include: lookups in a single SPF record — if you have many, you'll need to consolidate or use SPF flattening (some providers like ImprovMX offer this as a service).

Check 2 — Cloudflare proxy is "orange-cloud" on a CNAME

TrekMail uses CNAMEs for mta-sts, autoconfig, autodiscover, and (on paid SMTP) smtp. If any of these has the orange-cloud (Proxied) mode on Cloudflare, TrekMail's checker can't validate them properly.

Symptom: MTA-STS shows "Blocked (Cloudflare)", or Autodiscover not detected, or generic "expected xxx.trekmail.net, got proxied IP".

Fix: Cloudflare Dashboard → DNS → find the record → click the orange cloud icon to turn it grey ("DNS only"). Save. Recheck on TrekMail's side after 2-3 minutes.

The orange cloud is fine for HTTP/HTTPS records (your website's A or main CNAME). It is not fine for email-infrastructure CNAMEs. TrekMail-checker can't validate through Cloudflare's reverse proxy because the proxy replaces the real upstream with a Cloudflare IP.

Check 3 — DMARC at the wrong host

DMARC must live at _dmarc.yourdomain.com, not at the apex. Some DNS provider UIs default the host field to @ (apex), and users save without noticing.

Symptom: DMARC record exists in your DNS but TrekMail says not found.

Fix: Delete the DMARC record at @ and re-add at _dmarc. Some DNS interfaces want the host field as _dmarc (relative) and some want _dmarc.yourdomain.com (fully qualified) — they mean the same thing but you have to match what the UI expects.

Check 4 — DKIM record split incorrectly

DKIM keys are long (TrekMail uses 2048-bit RSA keys). Many DNS providers limit a single TXT record string to 255 characters. Long DKIM records are stored as multiple concatenated strings:

"p=MIIBIjANBgkqhki..." "...continues here" "...and ends here"

The DNS spec says receivers must concatenate these strings before parsing. Most providers do this correctly automatically, but a few mangle it (extra whitespace, line breaks, dropped strings).

Symptom: DKIM record visible in your DNS but TrekMail says "DKIM key invalid" or "p= does not match".

Fix:

• If your DNS provider has a "quoted string" entry field, paste the value exactly as TrekMail shows it.
• If your DNS provider has separate fields for each 255-char segment, split the value carefully at quote boundaries.
• If your DNS provider auto-splits, paste the whole thing without quotes and let it handle it.
• Use dnschecker.org to query the TXT record and see whether the public key is reassembled correctly when read by external parties.
• Some providers (Cloudflare especially) have a "split into 255-char chunks" toggle for TXT records — turn it on if available.

Check 5 — MTA-STS issues

MTA-STS requires both a TXT record AND a CNAME, and both must be correct.

"Blocked (DNS)" status. The CNAME mta-sts is missing or pointing somewhere else. Fix: add mta-sts CNAME mta-sts.trekmail.net. at your DNS provider.

"Blocked (Cloudflare)" status. The CNAME exists but the orange cloud is on. See Check 2 above — turn it grey.

"Degraded" status after previously working. The CNAME was deleted, modified, or the policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt became unreachable. Restore the CNAME exactly and the system auto-recovers within a check cycle (usually 10-15 minutes).

Check 6 — Records visible to you but not to us

Sometimes your local DNS resolver caches an old "no record" answer for an hour, so you see your new records via dig on your laptop, but the TrekMail checker (using authoritative servers) actually sees the truth. The reverse can happen too — you see nothing because your local cache is stale, but our checker actually does see them.

The way to know which side is real:

1. Open dnschecker.org or whatsmydns.net.
2. Enter your subdomain and the record type (e.g. _dmarc.yourdomain.com for DMARC, type TXT).
3. Look at the global propagation map — every green tick is one of their globally-distributed checker nodes that sees the record.
4. If the map shows full propagation but TrekMail still says no record, the issue is at our checker — open a support ticket.
5. If the map shows partial propagation or no records, wait or fix.

Check 7 — TTL too high on the old record

When you change a DNS record, the old value can stay cached at intermediate resolvers for up to its TTL (Time To Live, in seconds). TTLs of 24 hours (86400 seconds) are common for older records.

Symptom: You changed a record an hour ago, but checkers still see the old value worldwide.

Fix: This is mostly a "wait it out" situation. If you're about to migrate a domain, set the TTL to 300 (5 minutes) a day or two before the migration so changes propagate fast on the day. Once stable, raise TTL back to 3600+ for caching efficiency.

How to debug step-by-step

1. Open the Domains page, click your domain.
2. Click View Conflicts (or similar — exact label depends on dashboard version).
3. The panel shows each record we expected, what we found, and where the mismatch is.
4. Cross-reference with the table at the top of this guide.
5. Fix at your DNS provider.
6. Click Verify DNS in TrekMail. (Or wait — we re-check automatically every few minutes.)
7. Status flips to green within a check cycle once everything matches.

For records you can verify yourself, use these commands from a terminal (Mac/Linux/WSL):

dig +short MX yourdomain.com
dig +short TXT yourdomain.com
dig +short TXT _dmarc.yourdomain.com
dig +short TXT dkim._domainkey.yourdomain.com
dig +short CNAME mta-sts.yourdomain.com

The output should match exactly what's in the required-records table. Any deviation is the bug.

Common pitfalls by DNS provider

• Cloudflare: orange-cloud proxy on CNAMEs is the #1 issue. Also: their DNS UI doesn't always show the trailing . on CNAME values — that's normal, they handle it internally.
• GoDaddy: older UI uses "Host = @" for apex; newer UI uses blank field. Their TXT record entry has been known to add hidden quotes around values.
• Namecheap: their advanced DNS panel handles TXT records cleanly. Their basic panel (URL forwarding included) often misformats SPF.
• Squarespace / Wix / hosted-website builders: their DNS UIs are limited; sometimes you can't add TXT records at all. Move DNS to a real provider (Cloudflare is free) and point your registrar's nameservers there.
• Route 53: straightforward; just make sure the hosted zone is correctly bound to your domain.

When everything checks out and we still say red

If dig confirms all records are correct and TrekMail still flags the domain as unverified after 60 minutes, that's a bug on our side. Open a support ticket with:

• Your domain name.
• Output of dig +short MX yourdomain.com and the other commands above.
• A screenshot of the View Conflicts panel.

We can usually identify the issue from our checker's recent log within a few minutes.