--- title: "DKIM record checker: look up a DKIM key by selector" description: "Check a DKIM record for free. Look up the key at any selector, or find it among common selectors, and see the key type, key length, testing and revocation flags and every tag explained." url: "https://nextmail.sh/tools/dkim-checker" --- Tools # DKIM record checker Find the key, read its strength. Look up the DKIM key receivers use to verify a domain’s mail. Enter the selector if you know it, or leave it empty to try the common ones, and see the key length, testing and revocation flags, and every tag explained. No selector? Leave it empty and the checker tries the common ones. ## How to check a DKIM record 1. 01 Enter the domain Use the domain in the From address, or the d= value of a DKIM signature. 2. 02 Add the selector if you have it It is the s= value of the DKIM-Signature header, or the name your provider gave you. Leave it empty to try the common ones. 3. 03 Read the key See the key type and length, the flags and every tag, with a note on anything receivers would reject. ## How to find your DKIM selector Every DKIM signature names its selector. Open the full headers of a message the domain sent, find the DKIM-Signature header and read two tags: d= is the signing domain and s= is the selector. Together they give the DNS name of the key, so s=selector1 and d=example.com mean selector1.\_domainkey.example.com. The email header analyzer reads every DKIM-Signature in a pasted header and links each one straight back to this checker. Your mail provider also shows the selector on the page where you set up DKIM. If you have neither, leave the selector empty and the checker tries the selectors the common providers use. [Open the header analyzer](https://nextmail.sh/tools/email-header-analyzer.md) ## What is DKIM? DKIM, short for DomainKeys Identified Mail, lets a domain sign the mail it sends. The sending server adds a DKIM-Signature header: a cryptographic signature over the body and a chosen set of headers, made with a private key only the sender holds. The matching public key is published in DNS as a TXT record, at a name built from the selector and the domain. A receiving server reads both from the signature, fetches the key and checks that nothing it covers changed after signing. A valid signature proves the d= domain took responsibility for the message. On its own it says nothing about the From address. DMARC links the two: it passes when SPF or DKIM passes for a domain that matches the From domain. Because the signature travels inside the message, DKIM usually survives forwarding, where SPF breaks. It fails when something on the way changes what was signed, such as a mailing list adding a footer or a tag to the subject. ## DKIM record tags A DKIM record is a list of tag=value pairs separated by semicolons. Only p= is required. - **`v=` DKIM1** The version of the record. Optional, but when it is present it must be v=DKIM1 and it must be the first tag. - **`k=` rsa or ed25519** The key type. Left out, it means rsa. ed25519 is newer and shorter, but not every receiver verifies it yet. - **`p=` base64 key, or empty** The public key, base64 encoded. Required. An empty p= revokes the key, so signatures made with it stop verifying. - **`h=` sha256, sha1** The hash algorithms the key may be used with, separated by colons. Left out, any algorithm is allowed. SHA-1 no longer counts, so h=sha1 on its own breaks verification. - **`t=` y, s** Flags separated by colons. y means the domain is testing DKIM and receivers treat its mail like unsigned mail. s means the i= identity in a signature must use exactly the signing domain. - **`s=` email or \*** The services the key may be used for. Left out, it means all of them. A value that names neither email nor \* makes the key unusable for mail. - **`n=` free text** Notes for people reading the record. Verifiers ignore it. - **`g=` obsolete** Granularity, from the first version of DKIM. Removed from the current standard, so verifiers ignore it. ## 1024 or 2048 bits, and rotating a key RSA keys are measured in bits. Verifiers ignore signatures from keys shorter than 1024 bits, 1024-bit keys still verify but are considered weak, and 2048 bits is the length providers now generate by default. Keys longer than 4096 bits go past what verifiers are required to handle. A 2048-bit key is about 400 characters of base64, longer than the 255 characters one DNS string can hold, so it is published as two or more quoted strings that receivers join back together. Ed25519 keys are much shorter, but not every receiver verifies them yet, so a domain that uses one signs with an RSA key as well. ### Rotating a key without losing mail 1. 01 Publish the new key at a new selector, and leave the old one in place. 2. 02 Wait until the new record shows up here and its TTL has passed. 3. 03 Switch the sender to sign with the new selector. 4. 04 Keep the old key published for a week or so, because mail signed before the switch can still be in transit or queued. 5. 05 Retire the old selector by emptying p=, or delete the record. ## Common DKIM problems and how to fix them ### No record at the selector Receivers fetch the key at selector.\_domainkey and the domain. When nothing is published there, every signature with that s= fails because there is no key to check it against. How to fix Confirm the selector from the s= tag of a signed message, publish the record exactly as your provider shows it, then check again once DNS has updated. ### The domain is doubled in the name Many DNS hosts add the domain to every name you type, so entering selector.\_domainkey.example.com creates selector.\_domainkey.example.com.example.com, where no receiver looks. How to fix Enter only selector.\_domainkey as the name, or end the full name with a dot if your DNS host accepts that. ### The key is shorter than 2048 bits 1024-bit keys still verify but are considered weak, and keys under 1024 bits are ignored outright. How to fix Generate a 2048-bit key at a new selector, then rotate to it as described above. ### The key is revoked An empty p= withdraws the key. That is right for a retired selector, but a sender still signing with it produces signatures that fail. How to fix Point the sender at a live selector, or publish its current public key at this one. ### Testing mode left on t=y tells receivers the domain is still testing DKIM, so they treat its mail like unsigned mail and the signature earns no trust. How to fix Remove t=y from the record once signatures verify. ### A CNAME that points nowhere Providers that manage keys for you ask for a CNAME. If the target has no key yet, or the CNAME has a typo, the lookup finds nothing. How to fix Copy the target exactly from your provider, and finish verifying the domain in its dashboard so it publishes the key. ### A key broken when it was split One DNS string holds at most 255 characters, so long keys are stored as several quoted strings. A character lost or added where they meet breaks the key. How to fix Paste the whole value and let your DNS host split it, or split it into quoted strings without losing anything. This checker joins them the way receivers do. ### Two records at one selector With more than one DKIM record at the same name, verifiers cannot tell which key to use, and signatures may fail. How to fix Keep one record per selector. Put a new key at a new selector instead. ### The key only allows SHA-1 h=sha1 limits the key to SHA-1, and signatures made with SHA-1 are no longer accepted. How to fix Remove the h= tag, or set it to h=sha256, and sign with rsa-sha256. ## DKIM selectors by provider Where the key lives depends on who sends your mail. These are the selectors the common providers use, and how they ask you to publish them. | Provider | Selectors | How it is published | | --- | --- | --- | | Google Workspace | google | A TXT record you copy from the Admin console. google is the default prefix and can be changed. | | Microsoft 365 | selector1, selector2 | Two CNAMEs pointing at Microsoft. The targets are shown in the Microsoft Defender portal. | | Amazon SES | three random tokens | Three CNAMEs pointing at token.dkim.amazonses.com. | | SendGrid | s1, s2 | Two CNAMEs pointing at SendGrid, created during domain authentication. | | Mailchimp | k2, k3 | Two CNAMEs pointing at dkim2.mcsv.net and dkim3.mcsv.net. Older setups used k1. | | Fastmail | fm1, fm2, fm3 | Three CNAMEs pointing at Fastmail. | | Proton Mail | protonmail, protonmail2, protonmail3 | Three CNAMEs pointing at Proton. | | Zendesk | zendesk1, zendesk2 | Two CNAMEs pointing at Zendesk. | | iCloud Mail with a custom domain | sig1 | One CNAME pointing at iCloud. | | HubSpot | hs1-account, hs2-account | Two CNAMEs that include your account number, pointing at HubSpot. | | Mailgun, Postmark and Zoho Mail | set by the provider | Chosen when you add the domain, and shown in the provider’s dashboard. | - **Provider** Google Workspace - **Selectors** google - **How it is published** A TXT record you copy from the Admin console. google is the default prefix and can be changed. - **Provider** Microsoft 365 - **Selectors** selector1, selector2 - **How it is published** Two CNAMEs pointing at Microsoft. The targets are shown in the Microsoft Defender portal. - **Provider** Amazon SES - **Selectors** three random tokens - **How it is published** Three CNAMEs pointing at token.dkim.amazonses.com. - **Provider** SendGrid - **Selectors** s1, s2 - **How it is published** Two CNAMEs pointing at SendGrid, created during domain authentication. - **Provider** Mailchimp - **Selectors** k2, k3 - **How it is published** Two CNAMEs pointing at dkim2.mcsv.net and dkim3.mcsv.net. Older setups used k1. - **Provider** Fastmail - **Selectors** fm1, fm2, fm3 - **How it is published** Three CNAMEs pointing at Fastmail. - **Provider** Proton Mail - **Selectors** protonmail, protonmail2, protonmail3 - **How it is published** Three CNAMEs pointing at Proton. - **Provider** Zendesk - **Selectors** zendesk1, zendesk2 - **How it is published** Two CNAMEs pointing at Zendesk. - **Provider** iCloud Mail with a custom domain - **Selectors** sig1 - **How it is published** One CNAME pointing at iCloud. - **Provider** HubSpot - **Selectors** hs1-account, hs2-account - **How it is published** Two CNAMEs that include your account number, pointing at HubSpot. - **Provider** Mailgun, Postmark and Zoho Mail - **Selectors** set by the provider - **How it is published** Chosen when you add the domain, and shown in the provider’s dashboard. ## Questions this raises Let Nextmail publish your DKIM Connect a domain and Nextmail writes its DKIM records with MX and SPF, so there is no key to copy and no selector to look up. [Set up a domain](https://nextmail.sh/signup.md) [SPF record checker](https://nextmail.sh/tools/spf-checker.md)[MX record lookup](https://nextmail.sh/tools/mx-lookup.md)[DMARC record generator](https://nextmail.sh/tools/dmarc.md)[Email header analyzer](https://nextmail.sh/tools/email-header-analyzer.md)[Deliverability checker](https://nextmail.sh/tools/deliverability.md)[SPF, DKIM and DMARC explained](https://nextmail.sh/blog/spf-dkim-dmarc-explained.md)[All tools](https://nextmail.sh/tools.md)