Enter a domain and a DKIM selector to look up the public key TXT record published at <selector>._domainkey.<domain> and read its tags. It is free, runs instantly in your browser over DNS-over-HTTPS, with no signup and nothing stored.
Create a free Unspam account to save your results and re-run these checks anytime, so you catch a broken setup before it costs you. No credit card.
DKIM (DomainKeys Identified Mail) lets a sending server attach a cryptographic signature to each message. The matching public key is published in DNS as a TXT record at <selector>._domainkey.<domain>, where the selector is a label the sender chooses so it can run several keys at once. A receiving server reads the selector from the message's DKIM-Signature header, fetches that public key, and verifies the signature to confirm the message was not altered in transit and really came from the signing domain. A valid DKIM signature is also one of the ways a message can align with and pass DMARC. Mailbox providers like Gmail and Yahoo expect bulk senders to authenticate with DKIM, so a published, correct record is part of getting to the inbox.
DKIM is published per selector, not per domain, so you must supply one. Find it in a message you received from the domain: open the raw headers and read the s= tag inside the DKIM-Signature line. If you cannot see a header, try common selectors such as google (Google Workspace), selector1 and selector2 (Microsoft 365), k1 (Mailgun), s1 and s2 (SendGrid), k1, k2 and k3 (Mailchimp), default, or dkim.
The version tag. It should read v=DKIM1 and, when present, must be the first tag in the record. Anything else means the record is not a valid DKIM key record.
The key type. Most records use k=rsa; some modern setups use k=ed25519. If k= is omitted it defaults to rsa, so a missing k tag is normal.
The base64-encoded public key. This is the core of the record. Whitespace inside it is legal, because RFC 6376 lets the base64 be folded and a verifier strips it before decoding; a character that is not base64 is not. RFC 8301 sets a 1024-bit minimum for RSA, and 2048-bit is the current recommendation.
If the record exists but p= is empty (p=), the key has been deliberately revoked per RFC 6376. This is different from no record at all: an empty p= tells verifiers to treat any signature using this selector as invalid.
The lookup returns nothing because the selector is wrong or the key was never published. Confirm the exact selector from the s= tag in a real DKIM-Signature header, then re-check. Each selector is separate, so the right key may live under a different selector.
The record is present but the p= value is blank, which RFC 6376 defines as a revoked key. Receivers will fail any signature signed with this selector. Republish the record with the current public key, or point your sending platform at a selector that still has a valid p= value.
The p= value was pasted across multiple strings or carries stray spaces and line breaks. That is legal: RFC 6376 section 3.6.1 lets the base64 be folded, and a verifier strips the whitespace before decoding it. What really breaks a key is a character that is not base64, or a value your DNS host quietly cut short, and both of those read here as a corrupt key rather than a missing one. Splitting a long TXT record into quoted chunks is fine too.
If the record does not start with v=DKIM1, parsers may reject it. Make sure the version tag is present and first, with tags separated by semicolons.
A 1024-bit RSA key meets the RFC 8301 minimum but 2048-bit is the current recommendation, and a t=y tag tells receivers to treat mail signed with this key as unsigned rather than merely to be lenient about failures, so DKIM cannot align for DMARC while it is there. For production mail, use a 2048-bit key and remove t=y once you have confirmed signing works.
When you rotate keys, mail already in transit is still signed with the previous selector. Removing that record immediately makes those messages fail verification, so keep the old selector published until the queue has drained.
Every date and figure Unspam publishes about sender requirements is kept here, checked against each provider’s own documentation. Last read August 16, 2026.
| Provider | What | Value | Applies to |
|---|---|---|---|
| Bulk sender rules in force since source | February 2024 required | mail to personal Gmail addresses | |
| Enforcement tightening since source | November 2025 observed Google calls this gradual and progressive rather than a switch that flipped on a date. | mail to personal Gmail addresses | |
| Counts as a bulk sender at source | 5,000 required This is Google’s number. Yahoo declines to publish one at all. | mail to personal Gmail addresses | |
| Spam complaint rate ceiling source | 0.3% required Google describes the effect as graduated rather than a cutoff: above the recommended figure inbox placement already suffers, and at the ceiling it suffers more. | every sender to Gmail, not only bulk | |
| Spam complaint rate to aim for source | 0.1% recommended Postmaster Tools does not divide complaints by everything you sent. It measures them against DKIM-signed messages that reached an engaged recipient’s inbox, so a sender already being filtered can see an artificially low rate. | every sender to Gmail, not only bulk | |
| Yahoo | Bulk sender rules in force since source | February 2024 required | mail to Yahoo, AOL and Yahoo’s other mailboxes |
| Counts as a bulk sender at source | not published Yahoo states it will not specify a volume threshold, so no figure can be attributed to it. | mail to Yahoo, AOL and Yahoo’s other mailboxes | |
| Spam complaint rate ceiling source | 0.3% required | mail to Yahoo, AOL and Yahoo’s other mailboxes | |
| Outlook.com | Bulk sender rules in force since source | May 2025 required | Outlook.com and Microsoft’s other consumer mailboxes, never a Microsoft 365 tenant |
| Counts as a bulk sender at source | 5,000 required The rule applies to any domain that has ever crossed the threshold, so it keeps applying on a quieter day. | Outlook.com and Microsoft’s other consumer mailboxes, never a Microsoft 365 tenant | |
| What happens to failing mail source | 550 5.7.515 observed Failing mail is refused during the SMTP conversation rather than filed in a spam folder. Microsoft’s postmaster policy page still describes junk foldering as a first step, so a sender may see either, but the bounce is the outcome to plan for. | Outlook.com and Microsoft’s other consumer mailboxes, never a Microsoft 365 tenant | |
| SPF and DKIM must both pass, not just DMARC source | required Stricter than DMARC alone. DMARC passes when either SPF or DKIM aligns, and Outlook.com asks for both checks to pass on top of that. | Outlook.com and Microsoft’s other consumer mailboxes, never a Microsoft 365 tenant | |
| Apple | Bulk sender rules in force since source | February 2025 required | mail to iCloud Mail, me.com and mac.com |
| ARC headers on forwarded mail source | required Apple is the only one of the four to ask for this, which is the honest reason to look at ARC at all. | mail to iCloud Mail, me.com and mac.com |
Unspam reads all of these from your domain name alone.
No DNS lookup can reach these. They need a real message or real sending history, which is what an inbox placement test is for.
