Skip to main content
Signal verifies the public authoritative DNS answer against the record returned for the registered domain. A record saved in a provider dashboard is not verified until public DNS returns the expected value.

​
Diagnostic sequence

1

Identify the failing component

Open the domain Records tab. Record the failing entry’s type, name, value, priority, and status.
2

Find authoritative nameservers

Confirm which provider the domain’s current NS records delegate to. Edit that active zone, not an old registrar or previous provider zone.
3

Inspect the final host name

Check whether the provider appended the zone automatically. A repeated suffix creates a different DNS name from the one Signal queries.
4

Compare the complete value

Match the returned value exactly. Remove accidental quotes, spaces, line breaks, or copied punctuation, and place MX priority in its dedicated field.
5

Remove proxy interference

Keep DKIM, tracking, and verification CNAME records in direct DNS mode so the public answer remains the expected target.
6

Account for cached answers

A recursive resolver can return the old value until its TTL expires. Verify again after public resolvers can see the new record.

​
Conflicts to check

  • A CNAME shares its owner name with another record.
  • A previous provider’s DKIM record remains at the same selector.
  • More than one DMARC TXT record exists at the same policy host.
  • A proxy or CNAME-flattening feature changes the expected answer.
  • The domain moved nameservers, but changes were made in the old zone.
  • A delegated subdomain points to different nameservers from the parent zone.
  • DNSSEC validation broke after a nameserver or DS-record change.

​
When one record verifies and another does not

Treat each record independently. A valid DKIM record does not prove the MAIL FROM MX or SPF record is correct. An optional DMARC or BIMI problem is also different from a required sending check. Use the component status returned by Signal rather than replacing all records at once.

​
When a verified domain becomes degraded

A later degraded or failed status means a previously accepted public condition changed or could not be confirmed. Review recent DNS edits, nameserver changes, provider-account changes, proxy settings, and deleted records. Restore the exact expected answer before relying on that sender.
Deleting and re-adding the domain changes the diagnostic context but does not repair authoritative DNS. First identify the exact record that differs.