How do I find the DKIM selector for a domain?

Without a signed message you have four options, in descending order of reliability. One: if the domain is yours and publishes a DMARC rua= address, read the selectors out of your aggregate reports. RFC 9990's report schema makes the selector element required on every DKIM result, so the reports name every selector that signed mail as your domain. Two: ask the sending platform, or read it from the tenant admin console; Exchange Online PowerShell's Get-DkimSigningConfig shows the live Microsoft 365 selector state. Three: identify the mail platform from the MX record and query that vendor's documented default, such as selector1 and selector2 for Microsoft 365, google for Google Workspace, or s1 and s2 for SendGrid. Four: if a signed message ever arrives, read the s= tag from the DKIM-Signature header. Guessing is only ever a heuristic. RFC 6376 places no constraint on selector names and warns that some operators choose names specifically to prevent harvesting by outside parties.

How do I look up a DKIM record without an email header?

You query candidate names directly. A DKIM key lives at selector._domainkey.domain, so with a guessed selector you can run dig +short selector1._domainkey.example.com CNAME and dig +short google._domainkey.example.com TXT, or use Resolve-DnsName on Windows. Query for both CNAME and TXT. Microsoft 365 publishes DKIM as CNAME records while Google Workspace publishes TXT, and a checker that only looks for TXT will report a false 'not found' on a healthy Microsoft 365 domain. There is no DNS query that lists the names under _domainkey, so you cannot enumerate selectors. You can only test names you already suspect. If the domain is yours, DMARC aggregate reports name the selectors for you without any guessing at all.

What are the most common DKIM selectors?

The highest-yield vendor-documented names are selector1 and selector2 (Microsoft 365, published as CNAMEs and identical for every tenant worldwide) and google (Google Workspace, a TXT record, and overridable by the admin). After those come s1 and s2 (Twilio SendGrid, CNAMEs), km1, kt1 and ks1 with their paired numbers (Klaviyo static routing, where km is marketing, kt transactional and ks service), and zoho (Zoho Mail's documentation example). The names k1 and k2 for Mailchimp and hs1 and hs2 for HubSpot are widely observed in the wild but are not published host names in either vendor's documentation, so treat them as conventions rather than facts. The names default, dkim and mail are legacy conventions blessed by no standard. No such list can be complete: Amazon SES Easy DKIM uses randomly generated tokens and Postmark uses timestamp-style names such as 20130425164621.pm, neither of which any dictionary will ever contain.

Why does my DKIM record say not found?

Six common causes. You guessed the wrong selector: on 2026-08-01, paloaltonetworks.com published selector2 but not selector1, so a tool that probes only selector1 reports 'not found' incorrectly. The record was published at the wrong name, usually because the DNS provider silently appended the zone name; Mailchimp, AWS and Postmark all document this double-append failure. The CNAME chain is broken or the checker will not follow it, which is common on Microsoft 365 where the record in your own zone is only a pointer to a key held in Microsoft's zone. The key was retired in a rotation, or the record resolves with an empty p= value, which RFC 6376 defines as revoked. The TXT record was split across character-strings and reassembled with stray whitespace, which RFC 6376 forbids. Or provisioning has not finished: AWS documents up to 72 hours for DNS propagation, HubSpot up to 48 hours, and a Microsoft 365 key rotation takes 96 hours before the new key signs. Sometimes 'not found' is also the correct answer. Microsoft tells administrators not to publish DKIM records on parked domains, because the missing public key is what stops forged mail from validating.

What is the default DKIM selector?

There is no default DKIM selector in the standard. RFC 6376 defines the DNS name as the selector, then the label _domainkey, then the domain, but places no constraint on the selector string itself, and no RFC blesses any particular name, including 'default', which is a tutorial convention rather than a specification. What exists instead are vendor defaults. Microsoft 365 uses selector1 and selector2 for every tenant. Google Workspace's documented default prefix is 'google', though an administrator can change it. Zoho Mail's documentation uses 'zoho' as its example while letting the admin type anything. And some platforms have no default at all by design: Amazon SES Easy DKIM generates three random tokens per identity, and SES BYODKIM asks the customer to invent a unique name for the key.

Can you list all the DKIM selectors for a domain?

Not from DNS. There is no query type that returns the child names under the _domainkey label of a domain, and a name that does not exist produces the same answer whether the zone holds zero other selectors or forty. Zone-walking is not a workaround: NSEC enumeration works only against DNSSEC-signed zones that use NSEC, RFC 5155 introduced NSEC3 specifically to provide measures against that enumeration, and most zones are not signed at all. What you can do is test a dictionary of candidate names and report which ones answered. That heuristic will always be incomplete, as shopify.com demonstrated on 2026-08-01 by returning nothing against a 20-name probe list. The only method that approaches a complete inventory is DMARC aggregate reporting, where RFC 9990's schema requires a selector element on every DKIM result, and even that only enumerates selectors that actually signed mail during the reporting period.

August 7, 2026 DNSai Email

How to Find a DKIM Selector Without the Email Headers

Somebody hands you a domain. Maybe it came in with an acquisition. Maybe a monitoring dashboard turned red overnight and you are three hours into the audit that followed. You paste it into a DKIM checker and get back four words.

DKIM record not found.

So you go looking for advice, and every article you open says the same thing. Find a message from that domain, open the raw headers, locate the DKIM-Signature field, read the s= tag. There is your selector.

Fine. Except you do not have a message. You are not going to get one. Nobody at that company is going to send you mail on request so you can read their headers, and the whole reason you are asking is that you sit outside their mail flow. The standard advice is not wrong. It is just addressed to somebody else.

Here is the part that matters, and we will prove it on a domain you can check yourself in about nine seconds: the tool that told you "not found" is quite possibly wrong, and the reason it is wrong is the same reason this question is hard in the first place.

If DKIM itself is new to you, start with our DKIM primer and come back. This article assumes you know what a key record is and picks up at the harder question: how do you find a DKIM selector when you cannot read the headers?

DKIM is the one email-auth record you cannot enumerate

Think about how you find the other two. SPF lives at the domain apex, so you query the domain. DMARC lives at _dmarc.<domain>, so you query that. Both are fixed addresses. You do not have to know anything about the organisation to check them.

DKIM is built differently, on purpose. RFC 6376 explains why in Section 3.1: "To support multiple concurrent public keys per signing domain, the key namespace is subdivided using "selectors"." A domain that sends through six platforms can hold six live keys at once. That flexibility has to be paid for somewhere, and it is paid for at lookup time. Section 3.6.2.1 spells out the address you have to build:

"Given a DKIM-Signature field with a "d=" tag of "example.com" and an "s=" tag of "foo.bar", the DNS query will be for "foo.bar._domainkey.example.com"."

— RFC 6376, Section 3.6.2.1, IETF / RFC Editor, September 2011

The same section says flatly that "All DKIM keys are stored in a subdomain named "_domainkey"." Good. That is one third of the name pinned down, and the domain is another third. The middle piece is the problem, because the specification never tells you what it may contain. It tells you the opposite:

"While some domains may wish to make selector values well-known, others will want to take care not to allocate selector names in a way that allows harvesting of data by outside parties."

— RFC 6376, Section 3.1 (Selectors), IETF / RFC Editor, September 2011

Read that twice. It is the thesis of this entire article, written into an Internet Standard in 2011. Selector discovery is not supposed to be easy. Any page that promises you a complete list of DKIM selectors is contradicting the specification on its face.

And plain DNS gives you nothing to work with. There is no query type that asks "what names exist under _domainkey.example.com?" A name that does not exist returns exactly the same answer whether the zone holds zero other selectors or forty. Absence of an answer is not evidence of absence.

One more wrinkle from Section 3.1: "Periods are allowed in selectors and are component separators." A selector may legally span several DNS labels. Postmark uses that in production. Its support documentation works through a record at a timestamp-style name ending in .pm, such as 20130425164621.pm. No wordlist on earth contains that string.

And no, you cannot zone-walk your way in

Somebody always raises DNSSEC at this point, and it deserves a precise answer rather than a dismissal. The concern is real and documented. RFC 5155 opens by describing exactly what NSEC records leak:

"It is trivial to enumerate the content of a zone by querying for names that do not exist."

— RFC 5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence, IETF / RFC Editor, March 2008

Now the three qualifications that turn that into a non-technique. It applies only to zones that are DNSSEC-signed. It applies only to signed zones using NSEC rather than NSEC3, and RFC 5155 exists specifically to provide measures against zone enumeration, so a zone that cared has already moved. Even against NSEC3 the remaining attack is a dictionary attack on hashed names, which is the same guessing game described in the rest of this article, only slower and with more arithmetic. Most zones are not signed at all.

So: not a general selector-discovery capability. If you have read otherwise, the article you read was wrong.

Four methods that actually work, honestly ranked

Method 1: read `s=` from a message, if one ever lands

RFC 6376 Section 3.5 makes the tag mandatory: "s= The selector subdividing the namespace for the "d=" (domain) tag (plain-text; REQUIRED)". Any valid signature therefore carries the answer in plain text. Take the s= value, take the d= value, and build the name.

One trap while you are in there. The d= tag is the SDID, "claiming responsibility for an introduction of a message into the mail stream", and it does not have to be the domain in the From: address. Microsoft says the same thing in its own documentation: "The domain that's used to DKIM sign the message isn't required to match the domain in the MAIL FROM or From addresses in the message." So a selector you find this way may live under a domain you were not expecting.

That is method one. It is what every other article on this subject is about, and it is the last time we will mention it.

Method 2: guess from a dictionary of documented vendor defaults

This is the practical heart of the problem. Selector names are arbitrary in the specification, but they are not arbitrary in practice, because most domains do not choose their own. A platform chooses for them and hands them a record to paste into DNS. Learn what the platforms hand out and you can guess well above chance.

Start with the MX record, because it usually tells you which platform to guess for. A domain fronted by Microsoft 365 gets Microsoft's selectors. A domain on Google Workspace gets Google's. Then work outward: marketing mail almost never comes from the same platform as corporate mail, so expect two or three unrelated selector families on any domain of size.

The CNAME-versus-TXT split, which most published lists get wrong

Half of the vendor tables on the internet assume every DKIM key is a TXT record. It is not, and Microsoft says so directly:

"The corresponding public keys are stored in DNS records for the signing domain (CNAME records in Microsoft 365; other email systems might use TXT records)."

— How to use DKIM for email in your custom domain, Microsoft Learn, 3 July 2026

This is not a formatting detail. A CNAME at selector1._domainkey.yourdomain.com means the key itself is not in your zone. It is in the vendor's zone, and the vendor can replace it whenever it likes without you touching a thing. That is precisely how Microsoft's rotation model works. It also means two practical things for you. First, a checker that queries only for TXT at that exact name, or that reports the CNAME instead of following it, will produce a false "not found" on a perfectly healthy domain. Second, when you do find a CNAME, follow it: the target tells you who runs the key.

Microsoft's host names are the single highest-yield guess in email, because they are constant everywhere. Its documentation states that "The values are the same for all Microsoft 365 organizations" and gives them as selector1._domainkey and selector2._domainkey. Every tenant on the planet. That is the whole trick: read the MX, then look up two names you already know.

Google Workspace goes the other way. Google's admin help says "The default prefix selector is google. If you are using Google Workspace, this is the recommended option" and "The record type is TXT", so you are looking for google._domainkey.<domain> as a TXT record. Note the word default. The same page tells administrators: "If your domain already uses a DKIM key with the prefix google, enter a different prefix in this field."

Platform	Selector name(s)	Record type	How solid is the name?
Microsoft 365 / Exchange Online	`selector1`, `selector2`	CNAME	Documented, and identical for every tenant
Google Workspace	`google`	TXT	Documented default; the admin can override the prefix
Amazon SES (Easy DKIM)	three generated tokens	CNAME × 3	Unguessable by design — the names are per-identity tokens
Amazon SES (BYODKIM)	whatever the customer types	TXT	Arbitrary by design
Twilio SendGrid	`s1`, `s2`	CNAME × 2	Documented record pair; a custom selector option exists
Mailchimp	`k1`, `k2` (`k3` also seen live)	CNAME × 2 + TXT	Observed convention. Mailchimp documents the record count and uses `k2._domainkey` in a troubleshooting example, but does not publish a host-name table
Zoho Mail	`zoho`	TXT	A documentation example, not a fixed name — the admin types whatever they want
Postmark	timestamp-style, e.g. `20130425164621.pm`	TXT	Unguessable, and a live example of a multi-label selector
Klaviyo (static routing)	`km1`/`km2`, `kt1`/`kt2`, `ks1`/`ks2`	CNAME	Documented family: km = marketing, kt = transactional, ks = service; pairs increment for extra domains
Klaviyo (dynamic routing)	not in your zone at all	NS delegation	The sending subdomain is delegated to Klaviyo. Query the delegated subdomain, never the apex
HubSpot	`hs1`, `hs2`	CNAME × 2	Community-observed only. HubSpot's own page says "DKIM requires two CNAME records" and stops there — it does not publish the host names
Mimecast / Proofpoint	per-tenant, no fixed public default	TXT or CNAME	Nothing to guess. We found no vendor documentation publishing a fixed selector name for either
Generic / legacy	`default`, `dkim`, `mail`, `key1`	TXT	Convention only. No RFC blesses any name, including `default`

Two rows on that table are the honest ones. Amazon SES Easy DKIM publishes three CNAMEs whose names are generated tokens, and AWS's own naming example is a bare token like abc123._domainkey.domain.com. Postmark uses a timestamp. Neither will ever appear in anybody's wordlist. And SES BYODKIM asks the customer to pick "a unique name that identifies the key", which produces exactly the arbitrary selectors the RFC contemplated.

SendGrid has a wrinkle of its own. Its CNAME target uses the label domainkey with no leading underscore, while the record name in your zone uses _domainkey with one. Half the published guidance gets that backwards. Those targets also carry a per-account identifier and a cluster, in the form s1.domainkey.uNNNNNNN.wlNNN.sendgrid.net. That is simply how the record is shaped.

Windows

1. Open PowerShell from the Start menu.

2. Probe a candidate name for both record types:

Resolve-DnsName -Type CNAME selector1._domainkey.example.com

Resolve-DnsName -Type TXT google._domainkey.example.com

macOS

1. Open Terminal from Applications > Utilities.

2. Run the candidate name for each type in turn:

dig +short selector1._domainkey.example.com CNAME

dig +short google._domainkey.example.com TXT

Linux

1. Open a terminal (usually Ctrl+Alt+T).

2. Same commands; install dig first if you need to:

dig +short s1._domainkey.example.com CNAME

sudo apt install dnsutils

Query each candidate twice, once for CNAME and once for TXT, or you will miss half the platforms. For the record-type mechanics themselves, our TXT record guide covers the syntax.

Run the Dictionary Instead of Typing It

DNSai's lookup brute-forces about 400 DKIM selector families against a domain and follows CNAMEs to the key that terminates the chain. Four hundred names is a large heuristic, not a complete list. There is no complete list. It will miss generated selectors, and it misses shopify.com entirely, as the measurements further down this page show.

Look Up a Domain →

Method 3: read the selectors out of your own DMARC aggregate reports

This is the method almost nobody writes about, and for anyone who controls the domain it is better than guessing.

If your domain publishes a DMARC record with a rua= address, receiving mail systems send you XML reports about the mail they saw claiming to be you. The structure of that XML is normative. RFC 9990, published May 2026, defines the aggregate report schema, and inside the DKIM result type it carries this line:

<xs:element name="selector" type="xs:string" minOccurs="1" maxOccurs="1"/>

— RFC 9990: DMARC Aggregate Reporting, Appendix A (XML Schema), IETF / RFC Editor, May 2026

minOccurs="1" means required. Every DKIM result in every conforming aggregate report names its selector, at the path feedback > record > auth_results > dkim > selector, alongside the signing domain and the pass/fail result. Nobody has to guess anything. The reports enumerate the selectors that actually signed mail as your domain, including selectors belonging to senders you never authorised. That is usually the more interesting half of the data.

<dkim> <domain>example.com</domain> <result>pass</result> <selector>abc123</selector> </dkim>

The channel fills quickly. RFC 9990 says "Typically, the reporting period will encompass a single UTC day, beginning at 0000UTC." Turn on rua= today and the first reports land inside about 24 hours. They cover the mail that actually moved in that window, as seen by the receivers that bother to report, so treat the first day as a start rather than a full inventory.

One standards note, because it trips people up: the original DMARC specification, RFC 7489, is obsolete. It was replaced in May 2026 by RFC 9989, RFC 9990 and RFC 9991. Cite RFC 9990 for anything about report structure. The wider standards story is its own subject; for DMARC fundamentals, see our DMARC guide.

Method 4: ask the platform

Unglamorous and frequently fastest. If you can reach the tenant admin console, the selector is sitting in it. On Microsoft 365, Exchange Online PowerShell will read the live state including which selector signs today and which one takes over at the next rotation:

Get-DkimSigningConfig | Format-List Name,Enabled,Status,Selector1CNAME,Selector1KeySize,Selector2CNAME,Selector2KeySize,KeyCreationTime,RotateOnDate,SelectorBeforeRotateOnDate,SelectorAfterRotateOnDate

On Amazon SES, the API returns the DKIM tokens for an identity, which is the only way to recover Easy DKIM names short of reading the zone you already have. If you are auditing somebody else's domain you cannot do either. But if you are auditing your own and you got here by guessing, stop guessing.

Two parts of the name are fixed: _domainkey and your domain.

The selector in the middle is whatever the operator chose.

Query for both CNAME and TXT, or you will miss half the platforms.

And read the CNAME target. It names whoever holds the key.

A worked example you can check today

Back to the four words at the top of this page. Here is a real domain, measured on 2026-08-01, and re-checked against 8.8.8.8, 1.1.1.1 and 9.9.9.9 before it went into this article.

$ dig +short selector1._domainkey.paloaltonetworks.com CNAME (no answer) $ dig +short selector2._domainkey.paloaltonetworks.com CNAME selector2-paloaltonetworks-com._domainkey.paloaltonetworks.onmicrosoft.com.

selector1 is absent. selector2 is right there. Not a transient failure, and not a resolver quirk: three independent public resolvers agreed. The same pattern shows up in the Mailchimp family on that domain, where k1 is missing while k2 and k3 both answer.

Why? We do not know, and neither does anyone else looking from the outside. A completed key rotation would look like this. So would a half-finished provisioning job, or a deliberate teardown of one half of a pair. You cannot tell from DNS, and any article that tells you it can is guessing.

What you can say is the useful part. A checking tool that probes selector1, gets nothing, and reports "DKIM record not found" is wrong about this domain. It was wrong about it on 2026-08-01 and you can re-run the two commands above to see where things stand today. The absence of the first selector in a documented pair proves nothing whatsoever about whether DKIM is configured.

What sixteen domains published on 2026-08-01

To put numbers on how far a dictionary gets you, we ran a 20-name probe list against sixteen well-known domains on 2026-08-01, from one vantage point, with every finding re-verified on three public resolvers. The twenty names were selector1, selector2, google, k1, k2, k3, s1, s2, default, dkim, mail, smtp, hs1, hs2, pm, scph0322, mandrill, sig1, sig2 and protonmail.

Domain	Selectors that answered (2026-08-01)	Type	Where the CNAME pointed
microsoft.com	`selector1`, `selector2`	CNAME	`microsoft.onmicrosoft.com`
github.com	`selector1`, `selector2`, `k1`, `k2`, `k3`, `s1`, `s2`	CNAME	`microsoft.onmicrosoft.com`; Mailchimp's `mcsv.net`; SendGrid's `u51742174.wl175.sendgrid.net`
pfizer.com	`k1`, `k2`, `k3`, `s1`, `s2`	CNAME	`mcsv.net`; `u10297757.wl008.sendgrid.net`
paloaltonetworks.com	`selector2`, `k2`, `k3`, `s1`, `s2` — no `selector1`, no `k1`	CNAME	`paloaltonetworks.onmicrosoft.com`; `mcsv.net`; `u2162085.wl086.sendgrid.net`
salesforce.com	`s1`, `s2`	CNAME	`u2706795.wl046.sendgrid.net`
stripe.com	`s1`, `s2`	CNAME	`u2680008.wl009.sendgrid.net`
cloudflare.com	`k1`, `s1` — no `k2`/`k3`, no `s2`	CNAME	`dkim.mcsv.net`; `u5338572.wl073.sendgrid.net`
shopify.com	nothing	—	—

Read the shopify.com row carefully, because it is the most important line in this article. It does not say Shopify has no DKIM. It says Shopify does not use any of the twenty names we asked for. That is the entire limitation of every dictionary method, printed on a domain you have heard of.

The counterexamples keep coming. Take google._domainkey, the vendor's own documented default. That day it resolved to a v=DKIM1 TXT record on waymo.com, and returned nothing on google.com or youtube.com. Even a vendor's default is not universal across that vendor's own domains.

Two standing caveats on everything in that table. First, a CNAME target pointing into a vendor's zone is a strong inference about who runs the key, not a certainty. The honest phrasing is "points into Mailchimp's zone", not "uses Mailchimp". Second, this is one measurement from one place on one day. Any of it can change tomorrow, without notice, and the only number that means anything is the one you take yourself.

What the Microsoft CNAME target quietly discloses

Follow the Microsoft 365 CNAMEs and they name a tenant. On 2026-08-01, microsoft.com, github.com and xbox.com all pointed into microsoft.onmicrosoft.com, the same tenant. Two other Microsoft-owned domains pointed elsewhere: nuance.com into nuancecommunications.onmicrosoft.com and activision.com into activision.onmicrosoft.com. We found no selector1 CNAME for linkedin.com or skype.com.

What that supports is narrow and mechanical: the Microsoft 365 DKIM CNAME target discloses which tenant signs a domain's mail, and therefore which domains share one. It does not show migration progress, corporate intent, or a timeline, and it does not mean the separate tenants are "not yet integrated". Organisations run multiple tenants permanently and for perfectly good reasons. None of these ownerships are news either; they have been public for years. If tenant fingerprinting through DNS is the thread you want to pull, our piece on DNS recon into Entra tenant IDs covers that disclosure channel properly.

There is a format wrinkle here that most published guidance has not caught up with. Every Microsoft 365 CNAME we observed on 2026-08-01 used the older <selector>-<domain-with-hyphens>._domainkey.<tenant>.onmicrosoft.com shape. But Microsoft documents a newer target format for new custom domains, ending in .dkim.mail.microsoft with a per-tenant partition character in it. The documentation describes the value as "part of the updated DKIM record format for new custom domains in Microsoft 365 introduced in May 2025" and notes that "The old and new formats can't coexist for the same selector." Five domains is not a survey. Our sample supports neither "the new format is unused" nor "the old one is deprecated". Expect to meet both, and do not assume the target shape when you write a parser.

When the checker says "record not found"

Six causes, in rough order of how often they turn out to be the answer.

1. You guessed the wrong selector. Everything above. Try the other half of the pair, try the other platform families, and remember that generated selectors defeat guessing outright.

2. The record was published at the wrong name. The classic is the double-appended domain, where a DNS provider silently adds the zone name to whatever you typed in the host field. Mailchimp documents it with an exact example:

"For example, if you enter "k2._domainkey.example.com" and "k2._domainkey.example.com.example.com" is created, update your CNAME record to only include "k2._domainkey"."

— Set Up Email Domain Authentication, Intuit Mailchimp

AWS documents the same failure in its SES troubleshooting: "Make sure that your provider didn't automatically append your domain name to the Name/host value that you entered in the DNS record. Some providers append the domain name without indicating that they've done so." Postmark warns about it too, noting a key can end up at xxxxxxxxxxxxxx.pm._domainkey.domain.com.domain.com instead of the intended location. Three unrelated vendors documenting one mistake is a strong hint about where to look first. AWS adds a related trap: a small number of DNS providers refuse underscores in record names, and the underscore in _domainkey is not optional.

3. The CNAME chain is broken, or your checker will not follow it. On a Microsoft 365 domain the name in your zone is a pointer; the key lives at the other end. Resolve the target explicitly and confirm a real key comes back. Microsoft's own status values for this family of failure are NoDKIMKeys and CnameMissing, and its advice is to check for typos in the dashes, periods and underscores of the value you pasted at the registrar. Here is what a healthy chain looked like on 2026-08-01:

$ dig +short selector1._domainkey.github.com CNAME selector1-github-com._domainkey.microsoft.onmicrosoft.com. $ dig +short selector1-github-com._domainkey.microsoft.onmicrosoft.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCxZC/z2cK+2s1f/ktzSDSeFzkfIHrjwtG..."

4. The key was removed after a rotation. Selectors retire. A name that answered last quarter can be gone this quarter, and a record can also resolve while carrying nothing: RFC 6376 says of the p= tag that "An empty value means that this public key has been revoked." Found is not the same as usable.

5. The TXT record is split and got reassembled wrong. A 2048-bit key exceeds the 255-character limit of a single DNS character-string, so DKIM keys are almost always published as several quoted strings inside one TXT record. RFC 6376 Section 3.6.2.2 is unambiguous about what to do with them: "Strings in a TXT RR MUST be concatenated together before use with no intervening whitespace." One stray space introduced by a control panel and the key is garbage while the record looks fine. The RFC also requires that when the v= tag is present it "MUST be the first tag in the record."

6. Provisioning simply is not finished. Every vendor publishes a window, and they are longer than people expect. AWS: "It can take up to 72 hours for changes to DNS settings to propagate." HubSpot: "DNS records usually take between 10 and 70 minutes to update, but can take as long as 48 hours in some cases." Microsoft's key rotation is slower still: "It takes four days (96 hours) for the new private key to start signing messages". If the record went in this morning, the answer may be to wait.

And then the case nobody includes on these lists: sometimes "not found" is correct. Microsoft tells administrators outright, "If you own registered domains that aren't used for email or anything at all (also known as parked domains), don't publish DKIM records for those domains". The missing public key is exactly what stops forged mail from validating. An auditor who logs every absent DKIM record as a finding will be wrong on every parked domain in the estate.

Two more places the key may be hiding rather than missing. A Microsoft 365 tenant signs its own initial domain automatically: "Outbound messages from senders in the contoso.onmicrosoft.com domain are automatically DKIM signed by the contoso.onmicrosoft.com domain", with no admin action and no record in the custom domain's zone. And a vendor using NS-delegated sending subdomains (Klaviyo's dynamic routing, for instance) serves the selectors from its own nameservers under something like send.example.com. Querying the apex will fail forever. Query the subdomain.

Rotation, and why every dictionary decays

Selectors exist partly so keys can be replaced. RFC 6376 is explicit that this is the expected lifecycle: "Keys can be replaced on a regular basis; thus, their lifetime can be relatively short." Which means any list of selector names you compile is a photograph, not a map.

Microsoft's model shows the mechanics clearly. It generates two key pairs per custom domain, and "Only one selector is active and used when DKIM signing using a custom domain is enabled." The other one is waiting: "The other selector is inactive. It's activated and used only after any future DKIM key rotation, and then only after the original selector is deactivated." So on a healthy Microsoft 365 domain you can find a perfectly valid record at a selector that is signing nothing at all, and the alternation between the two names is readable through the SelectorBeforeRotateOnDate and SelectorAfterRotateOnDate properties without ever touching a message header.

How often should keys rotate? There is no normative answer, and this is where a lot of articles quietly invent one. M3AAWG publishes a DKIM Key Rotation Best Common Practices document dated March 2019, and twice-yearly rotation is the figure commonly cited in the industry: as common practice, not as a standard, and not as a sentence we read out of the primary PDF. Deliverability practitioner Al Iverson recommended six months in 2020, as his own recommendation. Treat both as practice, not as a rule you can cite in an audit finding.

One more reason a single selector is rarely the whole story. RFC 8463 added Ed25519-SHA256 to DKIM: "This document adds a new signing algorithm, Ed25519-SHA256, to "DomainKeys Identified Mail (DKIM) Signatures" (RFC 6376). DKIM verifiers are required to implement this algorithm." A DNS name holds one key record, so a domain signing with both RSA and Ed25519 must publish two selectors, one per algorithm. Finding one is not finding both.

What a record you found does and does not tell you

You have a hit. Be careful what you conclude from it.

It tells you that somebody completed a DNS configuration step, and where the key lives. If it is a CNAME, the target names the platform holding the private key. If it is a TXT, you can read the key material and, per RFC 8301, expect verifiers to handle RSA keys from 1024 to 4096 bits. That RFC also states plainly that "rsa-sha1 MUST NOT be used for signing or verifying."

It does not tell you that the service is in use, paid for, current, or signing any live mail today. Records outlive contracts. It does not tell you the key is valid, because p= may be empty and revoked. It does not tell you the domain has no other selectors, because you only asked about the names you thought of. And a missing record at the apex does not mean the mail is unsigned, because d= need not match From:, tenants sign their own initial domains automatically, and vendors can serve keys from a delegated subdomain.

If you want the full picture of a domain's email posture rather than one record, the DKIM answer is only one leg of it. SPF and DMARC are the other two, and unlike DKIM, both of them live where you can find them.

Back to the four words

The checker that told you "DKIM record not found" asked a handful of names and got silence. That is all it did. Whether that silence means the domain has no DKIM, or has DKIM under a selector nobody thought to guess, or has a key sitting one CNAME hop away that the tool declined to follow, is not something the tool knows — and on 2026-08-01, on paloaltonetworks.com, a tool that stopped at selector1 would have reported a working configuration as broken.

The specification told us this would happen in 2011. Some domains want their selectors well-known. Others take care not to allocate names that let outsiders harvest data. Both are correct, and DNS will never tell you which kind you are looking at.

So run the dictionary, follow the CNAMEs, turn on rua= if the domain is yours, and write the date next to whatever you find. Then say only what you actually know: that these selectors answered, on this day, from this vantage point. The rest is a guess, and the honest thing is to label it as one.

Sources

RFC 6376: DomainKeys Identified Mail (DKIM) Signatures (Sections 3.1, 3.3.3, 3.5, 3.6.1, 3.6.2.1, 3.6.2.2) — IETF / RFC Editor, September 2011. https://www.rfc-editor.org/rfc/rfc6376.txt
RFC 6376 info page (Internet Standard STD 76; updated by RFC 8301, 8463, 8553 and 8616) — RFC Editor. https://www.rfc-editor.org/info/rfc6376
RFC 8301: Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM) — IETF / RFC Editor, January 2018. https://www.rfc-editor.org/info/rfc8301
RFC 8463: A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM) — IETF / RFC Editor, September 2018. https://www.rfc-editor.org/info/rfc8463
RFC 5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence (Abstract; Security Considerations) — IETF / RFC Editor, March 2008. https://www.rfc-editor.org/rfc/rfc5155
RFC 9990: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting (Appendix A, XML Schema) — IETF / RFC Editor, May 2026. https://www.rfc-editor.org/rfc/rfc9990.txt
RFC 7489 info page — obsoleted by RFC 9989, RFC 9990 and RFC 9991 — RFC Editor, March 2015. https://www.rfc-editor.org/info/rfc7489
How to use DKIM for email in your custom domain — Microsoft Learn (Microsoft Defender for Office 365), 3 July 2026. https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure
Set up DKIM to prevent email spoofing — Google Workspace Admin Help, Google. https://knowledge.workspace.google.com/admin/security/set-up-dkim
Creating and verifying identities in Amazon SES (including Troubleshooting domain verification) — Amazon Web Services. https://docs.aws.amazon.com/ses/latest/dg/creating-identities.html
Provide your own DKIM authentication token (BYODKIM) in Amazon SES — Amazon Web Services. https://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-dkim-bring-your-own.html
How to set up domain authentication — Twilio SendGrid Docs. https://www.twilio.com/docs/sendgrid/ui/account-and-settings/how-to-set-up-domain-authentication
Set Up Email Domain Authentication — Intuit Mailchimp. https://mailchimp.com/help/set-up-custom-domain-authentication-dkim-and-spf/
DKIM Configuration — Zoho Mail Admin Console Help — Zoho. https://www.zoho.com/mail/help/adminconsole/dkim-configuration.html
My DKIM Record Won't Verify — Postmark (ActiveCampaign) Support Center. https://postmarkapp.com/support/article/1095-my-dkim-record-wont-verify
How to set up a branded sending domain — Klaviyo Help Center. https://help.klaviyo.com/hc/en-us/articles/115000357752
Connect your email sending domain — HubSpot Knowledge Base. https://knowledge.hubspot.com/domains-and-urls/connect-your-email-sending-domain
How to Set Up DKIM — Signing, DNS, and Verification — Mimecast. https://www.mimecast.com/content/how-to-set-up-dkim/
DKIM Key Rotation Best Common Practices (March 2019) — M3AAWG. https://www.m3aawg.org/DKIMKeyRotation
How often should you rotate your DKIM key? — Al Iverson, Spam Resource, 12 August 2020. https://www.spamresource.com/2020/08/how-often-should-you-rotate-your-dkim.html
Live DKIM selector measurements, 2026-08-01 — DNSai. A 20-name selector probe run against sixteen domains from a single vantage point, with every finding re-verified against 8.8.8.8, 1.1.1.1 and 9.9.9.9 on the same day.

Share this article