Find your DKIM keys
and CNAMEs
in one check.

What it is. A CNAME record makes one domain name an alias of another name. The alias has no records of its own and points to the target name.

How it works. A lookup of the alias returns the target name, and the target is looked up next. If shop.example.com has a CNAME to stores.provider.example, visitors reach the servers of stores.provider.example.

Why it matters. An alias points a subdomain at a service without copying its IP addresses, so the service can change its servers without a change on your side. Many email providers publish their DKIM keys through CNAME records.

Common problems. A CNAME cannot share a name with other records, so it is not allowed at the bare domain, where MX and TXT records are published. A CNAME whose target no longer exists is broken, and the app marks it as broken.

shop.example.com CNAME stores.provider.example.

What it is. DKIM adds a digital signature to each email you send. The receiving server uses it to check that the message came from your domain and was not changed on the way.

How it works. Your mail system signs each message with a private key. The matching public key is published in your DNS, and the receiver fetches it to check the signature.

Why it matters. A valid signature helps your messages reach the inbox instead of the spam folder. It also gives DMARC a way to confirm that a message is genuine.

Common problems. A key that is cut off or contains stray spaces makes the signatures fail. Keys shorter than 2048 bits are considered weak, and an empty key verifies no signatures.

selector1._domainkey.example-shop.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."

What it is. SPF is a public list of the servers that are allowed to send email for your domain. A receiving server compares the sending server against this list.

How it works. The list is one text record at your domain. When a message claims to come from example-shop.com, the receiver reads the record and checks whether the sending server is on it. The record ends with a rule for all other servers, such as a soft fail (~all) or a hard fail (-all).

Why it matters. Without SPF, it is easier for others to send mail in the name of your domain, and your own messages may be treated as suspicious.

Common problems. A domain may have only one SPF record, because two records make the check fail. The record may cause at most ten DNS lookups, so too many includes break it. A sender that is missing from the list may have its mail rejected.

example-shop.com TXT "v=spf1 include:provider.example ~all"

What it is. DMARC tells receiving servers what to do when a message fails the SPF and DKIM checks. It also asks them to send you reports about mail sent in the name of your domain.

How it works. The record is published at the name _dmarc. The policy is none (reports only), quarantine (failing messages go to spam) or reject (failing messages are refused). The rua address receives the reports.

Why it matters. DMARC makes it harder for others to send mail in the name of your domain, and the reports show who sends mail in your name. Many large mailbox providers expect it from domains that send email regularly.

Common problems. A reject policy set too early blocks your own mail when SPF and DKIM are not complete. Start with none, read the reports and then tighten the policy.

_dmarc.example-shop.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

What it is. An MX record names the server that receives email for your domain.

How it works. When someone writes to [email protected], their server looks up the MX records of example-shop.com. Each record has a priority number, the lowest number is tried first, and the next one is used when that server is unavailable.

Why it matters. Without correct MX records, incoming messages bounce or are lost. Changing your email provider usually means changing these records.

Common problems. Old MX records left beside new ones send some messages to the former provider. An MX record that points at a CNAME is not allowed by the DNS standards and can cause delivery problems.

example-shop.com MX 10 mail.provider.example. MX 20 backup.provider.example.

What it is. A TXT record stores a piece of free text in your DNS that other systems can read.

How it works. Services use text records to check ownership or to publish rules. A provider may ask you to add a given code at example-shop.com and then looks for that code. SPF, DKIM and DMARC are stored as TXT records.

Why it matters. TXT records are the main way to prove that you control a domain and to protect your email. They appear in most setup guides.

Common problems. Typing errors, missing quotation marks and extra spaces are the usual causes of failures. Some DNS panels add the domain name automatically, so a name entered in full ends up doubled and is not found.

example-shop.com TXT "site-verification=abc123"

What it is. An A record connects a domain name to an IPv4 address, such as 192.0.2.10. An AAAA record does the same for an IPv6 address.

How it works. When someone opens example-shop.com, their device asks DNS for the A and AAAA records and connects to the address it receives. A domain can have both kinds at once.

Why it matters. These records make your website and many services reachable by name. If they point to the wrong place, visitors see the wrong site or an error.

Common problems. After a move to a new host, the A record is often updated and the AAAA record forgotten, so some visitors still reach the old server. A typing error in one digit sends visitors to the wrong server.

example-shop.com A 192.0.2.10 AAAA 2001:db8::10

What it is. An NS record names the servers that hold the DNS records of your domain.

How it works. The name servers are set where the domain is registered. Lookups for example-shop.com go to those servers, and they answer with your other records. A domain normally has at least two of them.

Why it matters. Whoever runs your name servers controls the other records of your domain, including those for mail delivery. Changing them moves your whole setup to a new place.

Common problems. Switching name servers without copying the existing records stops the website and email at once. A listed name server that does not know the domain causes failures that are hard to trace.

example-shop.com NS ns1.provider.example. NS ns2.provider.example.

What it is. TTL is the number of seconds that other computers may keep a DNS answer before they ask again.

How it works. With a TTL of 3600, resolvers keep the answer for one hour and do not ask your servers again in that time. A shorter TTL spreads changes faster, a longer one means fewer lookups.

Why it matters. A sensible TTL lets you move a website or change an email provider without a long period of mixed answers. Lower it before a planned change.

Common problems. A record changed while its TTL is very long keeps its old answer for some people for days. A very short TTL on many records adds load and can make lookups slower.

example-shop.com A 192.0.2.10 TTL 3600

What it is. A selector is a short label that tells receivers which DKIM key to use for a signature.

How it works. The selector is part of the signature of each message. The receiver combines it with your domain to find the key, for example selector1._domainkey.example-shop.com. A domain can publish several keys side by side.

Why it matters. Selectors let you replace keys without interruption and let different services sign mail for your domain with their own keys.

Common problems. If the selector in the signature does not match the name in your DNS, the key is not found and the check fails. An old selector deleted too soon makes the check fail for messages that are still in transit. The header of an email shows the selector in its s= part.

selector1._domainkey.example-shop.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."

What it is. Hornetsecurity is an email security service that filters and signs mail for a domain. Its support article "How do I set up DKIM?" names two CNAME records, and the app checks them when a domain uses the service.

How it works. According to the Hornetsecurity article, customers add the CNAMEs hse1._domainkey and hse2._domainkey, which point to hse1._domainkey.hornetsecurity.com and hse2._domainkey.hornetsecurity.com. Hornetsecurity customers whose MX records contain pp-tp (shown as Proofpoint in the Mail services section) add pp-tp1._domainkey and pp-tp2._domainkey, which point to pp-tp1._domainkey.pp-tp.com and pp-tp2._domainkey.pp-tp.com. The key itself is published by the service at the target, so a key rotation needs no change in your DNS.

Why it matters. According to the Hornetsecurity article, outgoing mail is signed only for domains with valid DKIM settings. The app recognizes the service by MX records that contain hornetsecurity, vade, antispameurope or pp-tp, by the SPF include spf.hornetsecurity.com, or by the CNAMEs themselves, and it lists the missing records under Recommended DNS changes.

Common problems. A common gap is one CNAME instead of two, a CNAME with a different target, or MX records that point to the service while the DKIM CNAMEs are missing. The SPF record should include spf.hornetsecurity.com when outgoing mail goes through the service. DNS changes can take up to 72 hours to take effect.

hse1._domainkey.example-shop.com CNAME hse1._domainkey.hornetsecurity.com. hse2._domainkey.example-shop.com CNAME hse2._domainkey.hornetsecurity.com.

What it is. Many mail services publish their DKIM keys through CNAME records and ask for an SPF include and MX records in their setup guides. The app has a table of these records for known services.

How it works. When the MX records, the SPF record or the DKIM CNAMEs of a domain point to a service, a Mail services section lists the records from that service's guide: each DKIM CNAME as OK, Missing, Wrong target or Broken, the MX records and the SPF include. Where a service gives each customer unique values, the app checks that the CNAME ends at the service's domain and asks you to copy the exact value from the service's admin console.

Why it matters. A missing or wrong record is listed under Recommended DNS changes with its exact name and value, so the gap can be closed without searching the setup guide.

Common problems. The table covers Hornetsecurity, Proofpoint (pp-tp), Proton Mail, Microsoft 365, Google Workspace, Fastmail, iCloud Mail, IONOS, Zoho Mail, Cloudflare Email Routing, Amazon SES, SendGrid, Mailchimp, Mandrill, Mailgun, Postmark, Mailjet, Zendesk, Brevo, Mimecast, IceWarp and GoDaddy email. A service that is not in the table is not shown, and its keys appear under DKIM keys only when their selector is in the app's list.

selector1._domainkey.example-shop.com CNAME selector1-example-shop-com._domainkey.tenant.onmicrosoft.com. fm1._domainkey.example-shop.com CNAME fm1.example-shop.com.dkim.fmhosted.com.

The app only reads public DNS records, which is information that others on the internet can also look up. It does not ask for a password, does not log in to your mail account or your DNS host, and does not change your records.

DKIM is a digital signature that shows an email came from your domain. Its public key is stored in your DNS under a name such as selector1._domainkey. A CNAME is a DNS record that points one name to another name. Many mail services use CNAMEs to publish their DKIM keys and other settings for you. Tap the info button next to a section heading for a longer explanation.

DNS does not offer a way to list a domain's DKIM keys. The app tries a long list of common selector names, including hse1 and hse2 (Hornetsecurity) and pp-tp1 and pp-tp2 (Proofpoint). If a key is still not found, paste the header of an email that you received from the domain, because the header names the exact key. With Check subdomains on, subdomains that send mail (those with MX or SPF records) are also tested for their own DKIM keys, and the result note says how many were tested.

It appears when the MX records, the SPF record or the DKIM CNAMEs of a domain point to a known mail service. For Hornetsecurity it checks that hse1._domainkey and hse2._domainkey are CNAMEs to hse1._domainkey.hornetsecurity.com and hse2._domainkey.hornetsecurity.com, as the Hornetsecurity setup guide describes, and that the SPF record includes spf.hornetsecurity.com. A missing or wrong record is listed under Recommended DNS changes with the exact name and value. Hornetsecurity customers whose MX records contain pp-tp are checked for pp-tp1 and pp-tp2 in the same way, in a separate Proofpoint block. With Check subdomains on, a subdomain that sends mail through a known service gets its own block, marked with the subdomain name (for example dkn-365 · Hornetsecurity), and its record names are written relative to the domain (hse1._domainkey.dkn-365).

Hornetsecurity, Proofpoint (pp-tp), Proton Mail, Microsoft 365, Google Workspace, Fastmail, iCloud Mail, IONOS, Zoho Mail, Cloudflare Email Routing, Amazon SES, SendGrid, Mailchimp, Mandrill, Mailgun, Postmark, Mailjet, Zendesk, Brevo, Mimecast, IceWarp and GoDaddy email. The records come from each service's own setup guide. Where a service gives each customer unique values, the app checks that the CNAME ends at the service's domain and asks you to copy the exact value from the service's admin console. A service is shown only when the domain clearly uses it.

When Check subdomains is on, the app asks three public sources which subdomains of the domain they know of: the certificate records at crt.sh, the Certspotter service and the HackerTarget service. It also tries a list of common names such as autodiscover and mail, and then follows each CNAME to its target. Each name that the app finds appears in the Subdomains section. Subdomains that send mail (those with MX or SPF records) are also tested for their own DKIM keys and mail service setup. Private names that are not listed in these sources and are not common names usually stay hidden from outside checks.

The domain name you check, names derived from it (subdomains and DKIM names) and the names in its SPF record are sent to the public DNS service you choose in Settings. When Check subdomains is on, the domain name is also sent to three public services: crt.sh, Certspotter and HackerTarget. The app does not send this information to us.

Your history is saved only inside the app on your phone. There is no account, and we have no server that stores it. You can delete it at any time in Settings. If you delete the app, the history is deleted as well.

No. DNS Domain Detective is for informational purposes only. It shows what public DNS records say at the moment of the check. Please discuss changes with your IT provider before you make them.

The current DNS answer differs from the one saved in the earlier check. DNS changes can take some time to spread across DNS servers, so a record can appear and disappear for a while after you edit it.

Open Settings and tap "Report a problem or suggest an idea". You can add screenshots in the app, and your mail app shows the email before you send it. You can also write to [email protected].