How do you check DKIM for application email?

Treat a DKIM check as four separate tests

A DNS lookup alone is not a complete DKIM check. First, confirm that the message contains a DKIM-Signature field and identify the signature you intend to test. Second, retrieve and parse the public-key record named by that signature. Third, verify that the signed headers and canonicalized body still match the cryptographic signature. Fourth, decide whether a passing signing domain aligns with the visible From domain for DMARC. These layers answer different questions. A published record can be unused, a message can reference a missing selector, a signature can fail after content modification, and a cryptographic pass can remain unaligned with the author domain. Record each outcome rather than presenting one green badge. Also keep transport and mailbox states separate: provider acceptance, receiving-server acceptance, and inbox placement are not DKIM verification results.

Start from the signature on a real message

Obtain the raw message from a controlled recipient reached through the normal application path. In each DKIM-Signature field, record the `d=` signing domain, `s=` selector, `a=` algorithm, `c=` canonicalization modes, `h=` signed-header list, `bh=` body hash, `b=` signature data, and timestamps when present. RFC 6376 defines the signing-domain and selector tags and uses them to locate the public key. Do not guess the selector from a provider dashboard or query `_domainkey` without it. A message can carry multiple signatures from a sender, intermediary, or mailing system, so preserve the result for each signature. Avoid pasting production messages into public checkers: raw headers and bodies can expose recipients, message identifiers, routing details, unsubscribe tokens, and application content. Use restricted storage and a redacted diagnostic copy when full content is unnecessary.

Query the exact selector and signing domain

Construct the DNS name from the signature as `<selector>._domainkey.<signing-domain>`. If the header contains `s=app2026` and `d=notify.example.test`, query TXT at `app2026._domainkey.notify.example.test`. Record the original name, resolver, response, TTL, and any CNAME chain. Parse the resulting tag-value record rather than searching for a text fragment. The record can declare its version, key type, service restriction, flags, hash algorithms, and public-key data. An empty public-key value revokes the key. Distinguish NXDOMAIN, an empty answer, malformed content, an unsupported algorithm, an unusable key, and a transient resolver failure. Repeat a changed lookup after TTL expiry through an independent resolver, but do not assume all receivers have updated immediately. DNS success proves only that a record was returned at that moment; it does not prove that the tested message verifies or that the provider is signing current traffic with the selector.

Verify the headers, body hash, and signature

DKIM verification follows the signature's declared canonicalization rules. The verifier canonicalizes the body, calculates its hash, and compares it with `bh=`. It also canonicalizes the signed headers named in `h=`, incorporates the DKIM-Signature field as specified, and verifies `b=` with the public key. Use a maintained verifier library or a receiver's trusted authentication result rather than recreating these transformations with string operations. A body-hash mismatch often means the body changed after signing, while a header-signature failure can indicate signed-header modification, a wrong key, corrupted signature data, or implementation error. Capture which phase failed. Inspect whether important fields such as From, Subject, Date, and Message-ID were signed, but do not invent a universal signed-header policy. Canonicalization tolerates defined formatting changes; it does not make arbitrary footer injection, MIME rewriting, line-ending damage, or transport modification safe.

Read receiver results inside their trust boundary

RFC 8601 defines the Authentication-Results header and DKIM results including none, pass, fail, policy, neutral, temperror, and permerror. A pass means the receiver found an acceptable signature that passed verification tests. A temperror can reflect a condition likely to change, such as temporary key lookup failure; a permerror is unlikely to succeed on a later attempt without correction. Record the reporting authentication service, signing domain, selector, and algorithm where supplied. Trust only results inserted inside the receiving system's documented boundary because a sender can add a forged Authentication-Results field before transmission. Examine the topmost trusted result for the final receiving environment and account for intermediate hops. If different receivers disagree, compare the exact message version, DNS view, evaluation time, supported algorithms, and local policy. Do not convert `dkim=pass` into a claim that the mailbox provider endorsed the content or placed it in the inbox.

Check DMARC alignment separately from DKIM pass

A DKIM pass authenticates the signing domain in `d=`; it does not require that domain to equal the visible RFC 5322 From domain. RFC 9989 uses a passing DKIM-authenticated identifier for DMARC only when it aligns with the author domain under the applicable strict or relaxed alignment mode. For example, a message from `billing.example.test` signed with `d=provider.test` can pass DKIM but remain unaligned. A valid signature from `d=example.test` may align under relaxed mode, depending on the organizational-domain calculation and policy. Report three fields: DKIM result, signing domain, and alignment decision. A message can also pass DMARC through aligned SPF when DKIM fails or is unaligned, so a DMARC pass does not prove that the particular DKIM signature passed. Current Gmail sender guidance includes authentication and alignment requirements for applicable traffic, but satisfying them still does not guarantee receiving-server acceptance or mailbox placement.

Check current algorithms and key rotation

RFC 8301 updates DKIM cryptographic requirements: signers must use `rsa-sha256`, verifiers must support it, and `rsa-sha1` must not be used. It also requires RSA signing keys of at least 1024 bits while explaining why larger keys are preferable when operationally possible. A checker should identify the algorithm and flag obsolete or unusable material without claiming that key length alone makes a mail stream trustworthy. Provider workflows differ. Amazon SES documents Easy DKIM using 2048-bit keys by default and warns that changing signing methods without an intermediary step can create a period when messages are not DKIM-signed. Plan rotation with two valid selectors or the provider's documented overlap mechanism, confirm that new messages use the new selector, retain the old public key while delayed mail can still arrive, and remove it only after the overlap period. Never publish the private signing key in DNS, logs, tickets, or prompts.

Diagnose failures from the message outward

When a check fails, preserve the raw message and receiver result before changing DNS. Confirm the expected application and provider actually produced the message. If there is no signature, inspect whether signing was enabled for that identity, region, tenant, or message class. If the selector lookup fails, compare the exact `d=` and `s=` values, DNS zone, CNAME target, TTL, and recent rotation. If the key parses but the body hash fails, check gateways, list footers, tracking rewrites, MIME transformations, line endings, and security products that may modify content after signing. If the cryptographic signature fails with a matching body hash, inspect signed-header changes, key mismatch, and signing implementation. If DKIM passes but DMARC fails, test alignment rather than republishing the same key. Retest through controlled recipients after the relevant TTL or configuration propagation, and record evidence for each message class instead of declaring the entire domain fixed from one successful sample.

Keep an auditable DKIM check record

For every controlled message, retain a non-sensitive correlation identifier, sending system, provider account or workspace, visible From domain, receiving system, message time, and the complete result for each signature. Include `d=`, `s=`, `a=`, canonicalization, signed headers, DNS query name, DNS response time and TTL, key-record status, body-hash result, signature result, trusted Authentication-Results value, DMARC alignment decision, and remediation owner. Store raw messages only where access and retention controls are appropriate. Add the test scenario: normal application send, provider migration, key rotation, gateway path, or forwarding case. This makes regressions comparable and prevents a screenshot from becoming permanent proof after selectors or message processing change. Recheck after provider setup changes, DNS changes, signing-method changes, routing changes, or a new message class. An operational dashboard should show unknown and unavailable states explicitly instead of silently treating them as pass or fail.

Understand how SendHQ fits the check

SendHQ requires a verified From domain and provides delivery events. For a DKIM check, send a controlled message through the intended application path, inspect the received signature, query the actual `d=` and `s=` values, and record alignment separately. Do not infer a selector, key length, signing algorithm, inbox placement, or delivery guarantee from product documentation alone.

Frequently asked questions

Sources

• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures — RFC Editor
• RFC 8301: Cryptographic Algorithm and Key Size Update to DomainKeys Identified Mail (DKIM) — RFC Editor
• RFC 8601: Authentication-Results Header Field — RFC Editor
• RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — RFC Editor
• Gmail Email Sender Guidelines — Google
• Easy DKIM in Amazon SES — Amazon Web Services
• SendHQ OpenAPI Contract — SendHQ