DKIM Selectors Found
Domain Guarddog detected active DKIM selectors on your domain. This means your domain has DKIM signing configured, which is a key component of email authentication. Here's what those selectors mean and how to make sure everything is working properly.
What are DKIM selectors?
A DKIM selector is a label that identifies a specific DKIM key pair published in DNS.
When a mail server signs an outgoing email, it includes the selector name in the
DKIM-Signature header so that receiving servers know which public key
to look up for verification.
DKIM public keys are published as DNS TXT records at a specific location formed by combining the selector with your domain:
selector._domainkey.example.com
For example, if your domain is example.com and the selector is google,
the receiving server will query DNS for:
google._domainkey.example.com
Domains commonly have multiple selectors because different email services (your primary email provider, marketing tools, transactional email services) each use their own selector and key pair. This is normal and expected.
How DKIM signing works with selectors
When an email is sent from your domain, the sending mail server performs several steps using the selector to sign the message:
The mail server selects a key pair
The sending server has a private key associated with a specific selector (e.g., google or s1). It uses this private key to create a cryptographic signature of the email headers and body.
The signature is added to the email
The server adds a DKIM-Signature header to the email that includes the selector name (s= tag), the signing domain (d= tag), and the signature itself (b= tag).
The receiving server queries DNS
When the recipient's mail server receives the email, it reads the s= and d= tags from the DKIM-Signature header and constructs a DNS query: selector._domainkey.domain.com.
The signature is verified
The receiving server uses the public key from DNS to verify the signature. If valid, the email passes DKIM authentication, proving the email was sent by an authorized server and hasn't been tampered with.
Example DKIM-Signature header
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=google;
h=from:to:subject:date:message-id;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk...
In this example, the selector is google (from the s=google tag)
and the signing domain is example.com (from the d=example.com tag).
The receiving server will look up the public key at google._domainkey.example.com.
Common selectors and what they indicate
The selector name often reveals which email service or provider is configured to send email on behalf of your domain. Here are the most common selectors and what they mean:
| Selector(s) | Provider | What it means |
|---|---|---|
google |
Google Workspace | Your domain uses Google Workspace (Gmail) for email. Google generates a DKIM key published under the google selector. This is a TXT record. |
selector1, selector2 |
Microsoft 365 | Your domain uses Microsoft 365 (Outlook/Exchange Online). Microsoft uses two CNAME selectors that point to their infrastructure for automatic key rotation. |
s1, s2 |
Various (commonly SendGrid) | Short selector names like s1 and s2 are used by several providers. SendGrid commonly uses these as CNAME records pointing to their DKIM infrastructure. |
k1 |
Mailchimp / Mandrill | Mailchimp and its transactional email service Mandrill use the k1 selector. This is typically a CNAME record pointing to Mailchimp's DKIM servers. |
default, mail |
Generic / Custom setup | These are common selector names used in self-hosted mail servers (e.g., OpenDKIM with Postfix). They indicate a custom DKIM configuration rather than a hosted provider. |
mimecast20190104 (varies) |
Mimecast | Mimecast uses date-stamped selectors. If you see a selector starting with mimecast, your domain is using Mimecast's email security gateway. |
| Unique/auto-generated | Amazon SES | Amazon SES generates three unique selectors automatically. These are CNAME records that point to SES infrastructure for automatic key management. |
google
and k1), it means your domain has DKIM configured for both Google Workspace and
Mailchimp. Each service signs emails independently with its own key pair.
How to verify DKIM is working properly
Having DKIM selectors in DNS is the first step, but you should also confirm that emails are actually being signed and that signatures are passing verification. Here's how to check:
Check email headers
Send a test email from your domain to a Gmail or Outlook account, then inspect the email headers to verify DKIM authentication:
Send a test email
Send an email from your domain to a Gmail account (or another provider that shows authentication results).
View the email headers
In Gmail, open the email, click the three-dot menu, and select "Show original." In Outlook, open the message properties to view headers.
Look for the Authentication-Results header
Search for Authentication-Results in the headers. You should see a line like:
Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=google header.b=AuUoFEfD;
The key thing to look for is dkim=pass. This confirms that:
- The sending server signed the email with a DKIM private key
- The receiving server found the corresponding public key in DNS
- The signature verified successfully (the email was not altered in transit)
Query DNS directly
You can verify that the DKIM public key is properly published in DNS by querying for the selector record directly:
dig TXT google._domainkey.example.com +shortOr on Windows:
nslookup -type=TXT google._domainkey.example.com
You should see a response containing v=DKIM1 and a p= tag with the
public key data. If the query returns no results, the DNS record may not be published correctly.
Best practices for DKIM key management
Now that your DKIM selectors are configured, follow these best practices to maintain strong email authentication:
Use 2048-bit RSA keys (or stronger)
1024-bit RSA keys are considered weak and may be rejected by some providers. Always use 2048-bit keys for new deployments. If your DNS provider has record length limits, the key can be split across multiple strings.
Rotate keys every 6–12 months
Regular key rotation limits the impact of a compromised key. Create a new key with a new selector, update your signing configuration, then revoke the old key by setting its p= value to empty in DNS.
Keep private keys secure
Store private keys with restricted file permissions on mail servers. Never share them via email, chat, or version control. If a key is compromised, revoke it immediately by emptying the p= tag in the corresponding DNS record.
Sign all outbound email sources
Every service that sends email on behalf of your domain should have its own DKIM selector and key pair. This includes your primary email provider, marketing platforms, CRM systems, and transactional email services.
Remove the testing flag when ready
If your DKIM DNS record includes t=y, it signals testing mode. Receiving servers may not enforce DKIM results in this mode. Remove the flag once you've confirmed signing works correctly.
Monitor your DKIM configuration continuously
Domain Guarddog watches your DKIM selectors, SPF records, and DMARC policies around the clock and alerts you to any changes or issues before they affect your email deliverability.
Get Started Free