Find and validate your DKIM public key
DNS & Records
DNS Lookup Every DNS record for any domain A Record Lookup IPv4 addresses for a domain AAAA Record Lookup IPv6 addresses for a domain MX Lookup Mail servers for a domain NS Lookup Authoritative name servers TXT Lookup TXT records, SPF, verification CNAME Lookup Canonical name (alias) records SOA Lookup Start of Authority record SRV Lookup Service location records CAA Lookup Which CAs may issue certificates Reverse DNS (PTR) IP address to hostname DNSSEC Check Is the domain signed and validated? DNS Health Check A full delegation & DNS report cardEmail Deliverability
SPF Check Validate your Sender Policy Framework record DMARC Check Inspect and grade your DMARC policy DKIM Check Find and validate your DKIM public key Blacklist Check Check an IP against email blocklists (DNSBLs) SMTP Test Connect to a mail server and check STARTTLS MTA-STS Check Enforced TLS policy for inbound mail BIMI Check Brand logo record for email TLS-RPT Check SMTP TLS reporting policyNetwork & Web
SSL Certificate Check Inspect a site's TLS certificate and expiry HTTP Header Check Inspect response headers, redirects and security Ping (TCP) Reachability and latency over TCP Port Check Which common ports are openDomain
WHOIS Lookup Registration data for domains, IPs and ASNsDKIM adds a cryptographic signature to your outgoing email; receivers verify it against a public key you publish in DNS at selector._domainkey.your-domain. Because DNS provides no way to list selectors, IPeek probes the selectors used by Google, Microsoft, Amazon SES and other major providers.
When you send mail, your provider signs selected headers and the body with a private key, adding a DKIM-Signature header to the message. The receiver reads the d= (domain) and s= (selector) tags from that header, fetches the matching public key at selector._domainkey.d, and verifies the signature. If it validates, the content wasn't altered in transit and genuinely came from a key holder for that domain. The private key stays on the sending server; only the public key lives in DNS.
A selector lets one domain publish multiple DKIM keys — useful for rotation or for different sending services. The public key is a TXT record at selector._domainkey.your-domain, such as google._domainkey.example.com, containing v=DKIM1; k=rsa; p=<base64 public key>. Because DNS offers no directory of selectors, you can't simply ask which ones a domain uses. That's why IPeek probes the common selectors used by Google (google), Microsoft, Amazon SES, and other major providers to locate your published keys.
DKIM is the content-authentication layer of the three. Where SPF authorizes sending hosts by IP, DKIM cryptographically proves a message's headers and body weren't tampered with and ties it to a signing domain. DMARC then checks that the DKIM signing domain aligns with the visible From address. DKIM has a key advantage over SPF: because the signature travels with the message, it survives forwarding, which often breaks SPF. For strong deliverability, publish DKIM and align it under DMARC.
A selector is a label that points to a specific DKIM public key in DNS, letting a single domain publish multiple keys for rotation or different sending services. It appears as the s= tag in the DKIM-Signature header and forms part of the DNS location selector._domainkey.your-domain. For example, Google Workspace commonly uses the selector google.
DKIM records live at selector._domainkey.your-domain, and DNS provides no way to list which selectors a domain uses — so you have to know the selector to query it. Different providers use different selectors. IPeek solves this by probing the common selectors used by Google, Microsoft, Amazon SES, and other major providers to locate your published keys automatically.
A DKIM public key is published as a TXT record in DNS at selector._domainkey.your-domain — for example, google._domainkey.example.com. The record contains tags like v=DKIM1; k=rsa; p= followed by the base64-encoded public key. The matching private key stays on your sending mail server and is never published. Receivers fetch the public key to verify each signature.
Yes, in most cases. Because the DKIM signature travels inside the message headers, it remains valid after forwarding as long as the signed headers and body aren't modified. This is a major advantage over SPF, which typically breaks on forwarding because the sending IP changes. It's also why DMARC can still pass via DKIM when SPF fails on forwarded mail.
SPF authorizes which hosts may send mail for your domain by checking the sending IP, while DKIM cryptographically signs each message so receivers can verify its content wasn't altered and that it came from your domain. SPF validates the path; DKIM validates the message. They're complementary, and DMARC ties both to your visible From address.