My DNS Status Never Turns Green

DNS verification checks the records required for the setup you selected. A domain that receives mail through TrekMail normally needs MX, SPF, DKIM, and DMARC. Recommended records such as MTA-STS and TLS-RPT can be shown separately. This guide helps you compare the Dashboard with your DNS provider without guessing.

Start with the Dashboard record table

Open Domains, choose the affected domain, and open its DNS status. Copy the type, host, value, and, for MX, priority from that table. The table is the source of truth because DKIM values and some policy records are unique to the domain.

Before changing a record, check whether another service still needs the existing value. In particular, keep one SPF record and preserve any valid sender include that another service uses.

How fast should it propagate?

DNS updates can take different amounts of time to appear, depending on the provider, the previous record's TTL, and resolver caches. A pending result is not proof that the value is wrong, and elapsed time alone is not proof that it is right.

Use this order instead:

1. Save the record at the provider that hosts the authoritative DNS zone.
2. Compare the saved record with the Dashboard table, including MX priority and the full DKIM value.
3. Use Verify DNS once to request another TrekMail check.
4. If it is still pending, use the conflict details and an independent lookup to see which public value is currently visible.

Required records

For a normal mail-hosting setup, these are the key records. Copy the values from your own Dashboard instead of substituting a value from another domain:

Recommended records can improve delivery security. They are not a replacement for the core records:

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

Check 1: Combine duplicate SPF records

Only one TXT record at the root of the domain should start with v=spf1. If there are two, receiving servers cannot reliably tell which sending policy to use and TrekMail cannot validate the record correctly.

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

Fix: Merge the sender rules into one record. 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

Which ending to use: -all or ~all

Use only one ending. Both -all and ~all pass TrekMail's check, as long as include:spf.trekmail.net appears before the ending. The choice affects mail sent by services other than TrekMail.

An advisory note about the ending is not a failed verification. The domain can be verified with either ending.

Do not use these endings:

• ?all does not provide a useful authorization policy.
• +all authorizes every sender on the internet.

An SPF record may use at most ten DNS lookups. If you have many third-party senders, reduce the number of includes or ask the relevant provider for a supported consolidation option.

Check 2: A Cloudflare mail CNAME is proxied

Cloudflare can proxy website traffic, but a mail-related CNAME needs to be DNS only. This can include mta-sts, autoconfig, autodiscover, or another hostname the Dashboard asks you to add.

Symptom: The record is shown as blocked or cannot be validated, even though it appears in the Cloudflare DNS list.

Fix: In Cloudflare, open DNS, find the hostname, and change the orange cloud to the grey DNS only state. Then use Verify DNS in TrekMail to request a new check.

Your website's A or main web CNAME can remain proxied. Change only the mail-related host that the Dashboard identifies.

Check 3: DMARC is at the wrong host

DMARC belongs at _dmarc.yourdomain.com, not at the root of the domain. Some DNS provider forms prefill the host with @, so it is easy to save it in the wrong place.

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

Fix: Add the record at _dmarc. Some DNS interfaces want _dmarc; others want _dmarc.yourdomain.com. Check the provider's form hint before saving. Remove an incorrect record at @ only after confirming it is not used for another purpose.

Check 4: DKIM was pasted or split incorrectly

DKIM values are long. DNS providers can store a long TXT value as several connected text segments, but the public result still needs to match the full value shown in the Dashboard.

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

Most providers handle this automatically. A bad paste can add or remove characters, whitespace, or quotation marks.

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

Fix:

• Paste the value exactly as the Dashboard shows it.
• If the provider splits long TXT values automatically, paste the whole value and let it do so.
• If it asks for separate segments, follow that provider's own instructions and keep every character from the Dashboard value.
• Use an independent DNS lookup to confirm that the public TXT result contains the complete key.

Check 5: MTA-STS needs attention

MTA-STS is a recommended delivery-security feature for domains that receive mail through TrekMail. If the Dashboard shows it for your domain, it needs both the TXT record and the mta-sts CNAME shown there. Do not add these records to a sending-only domain unless the Dashboard explicitly asks for them.

Blocked by DNS. The mta-sts CNAME is missing or points somewhere else. Add or correct it with the current target from the Dashboard.

Blocked by Cloudflare. The CNAME exists but is proxied. Set that hostname to DNS only, as described in Check 2.

Degraded after it previously worked. Compare the TXT record and CNAME with the Dashboard. A changed or removed record is the usual cause. Restore the required value, then run Verify DNS and check the updated status.

Check 6: Compare a public lookup with the Dashboard

Your local network and TrekMail can see different DNS results while a change is still propagating. A public lookup is useful for checking what other networks can see.

To compare the result:

1. Open dnschecker.org or whatsmydns.net.
2. Enter the full hostname and record type. For example, use _dmarc.yourdomain.com and TXT for DMARC.
3. Compare the returned host, value, and MX priority with the Dashboard table.
4. If a public lookup shows the right value but TrekMail still reports a mismatch, include that result in a support ticket.

Check 7: An old DNS value is still cached

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: Avoid repeated edits while the same change is still appearing across DNS resolvers. For a planned migration, you can lower the TTL in advance if your DNS provider supports it. Once the migration is stable, choose a TTL that suits your normal DNS management policy.

How to debug step-by-step

1. Open the Domains page, click your domain.
2. If View conflicts is available, open it. It separates records that must be fixed from recommended and informational items.
3. Compare each expected host, value, and MX priority with the DNS provider's saved record.
4. Make the smallest necessary change at the provider. Keep records needed by other services.
5. Click Verify DNS in TrekMail to request another check.
6. Read the updated record status. A domain is active when the records required for its selected setup are valid; recommended records can be shown separately.

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

Compare the output with the values shown for your own domain in the Dashboard. Do not copy a DKIM key, MTA-STS policy ID, or other domain-specific value from an example.

Common DNS-provider pitfalls

• Cloudflare: mail-related CNAMEs must be DNS only. The provider may hide a trailing dot in a CNAME target; compare the resolved target rather than adding duplicate dots.
• GoDaddy: use @ for the root domain and _dmarc for the DMARC host. GoDaddy appends the domain name itself.
• Namecheap: add records in Advanced DNS only when Namecheap is the authoritative DNS provider. Use @ for the root domain.
• Route 53: select the hosted zone that is actually connected to the domain, then paste the full Dashboard value.
• Website builders and registrars: the place where you bought the domain may not control its DNS. Check the nameservers and edit records at the provider that does.

When everything checks out and we still say red

If the Dashboard and an independent public lookup show the same required records but TrekMail still reports a mismatch, open a support ticket with:

• Your domain name.
• The public lookup result for the affected record.
• A screenshot of the View conflicts panel, if it is available.

Do not include account passwords, mailbox passwords, recovery codes, or access tokens.