DKIM

You can't list DKIM keys from DNS. We find them anyway.

DKIM has no directory — selectors are invisible until you know their names. Trustliant probes the selectors every major platform uses today; learning the rest from DMARC aggregate reports is next. The goal: a living inventory of every signing key a client depends on.

Selector discovery, two ways

Well-known selector probing catches Microsoft 365 (selector1/2), Google Workspace, Mailchimp, SendGrid, HubSpot, Zendesk, and more instantly — live today. Aggregate-report discovery, revealing the selectors actually used in the wild (including the ones nobody documented), is next on the roadmap.

Key hygiene that ages well

1024-bit RSA keys get flagged (2048 is the floor now). Revoked-but-still-published records get cleanup findings. Rotation-age tracking is next: keys that haven't rotated in years are a quiet risk nobody watches.

Vendor attribution built in

Every selector maps to the platform that conventionally uses it, so 'k1._domainkey' reads as 'Mailchimp' in the UI. When a signature appears for a vendor the client never authorized, that's not a log line — it's a finding.

For your technicians

Per-selector records with key type, estimated bits, revocation state, and the RFC 6376 rotation procedure (new selector → switch signing → revoke old) spelled out.

For your clients

“Every service that signs email for your company is inventoried, strength-checked, and watched for changes.”