DMARC Analyzer

TL;DR

• DKIM cryptography is the public-key (asymmetric) digital-signature scheme defined by RFC 6376 that binds a signing identity to the body and selected headers of an email message. The signer holds a private key; the public key is published in DNS under a selector-scoped TXT record.
• The default signing algorithm is rsa-sha256: RSA digital signatures over a SHA-256 hash. RFC 8301 (2018) prohibits the older rsa-sha1 as cryptographically broken following the SHAttered SHA-1 collision demonstration.
• Ed25519 (RFC 8463) is the modern alternative signing algorithm: shorter keys (32-byte public key versus 256-byte RSA-2048), faster signing and verification, no 255-byte TXT-segment splitting, strong cryptographic margins. The canonical dual-algorithm deployment publishes both an RSA-2048 selector and an Ed25519 selector.
• Key size minimums: RFC 8301 requires at least 1024-bit RSA and recommends 2048-bit RSA. NIST SP 800-57 part 3 deprecates 1024-bit RSA for new signing keys. Modern operators publish 2048-bit RSA or Ed25519 public keys.
• The DKIM signing workflow has five steps: (1) canonicalize the body, (2) compute a SHA-256 body hash and base64-encode into the bh= tag, (3) build the signed-headers blob in canonicalized form, (4) sign the SHA-256 hash of the blob with the private key, (5) base64-encode the signature into the b= tag.
• Canonicalization (relaxed- relaxed is recommended) tolerates whitespace normalisation and header refolding so legitimate transit modifications by intermediate MTAs do not invalidate the body hash or the signed-headers hash. Without canonicalization, DKIM would fail on virtually every message.
• A 2048-bit RSA public key does not fit in a single 255-byte DNS TXT character-string (RFC 1035 §3.3.14) and is split across multiple strings within one TXT record. The receiver concatenates them transparently. Ed25519 public keys (44 bytes base64-encoded) avoid the issue.
• DKIM cryptography defends against unauthenticated forgery and in-transit body modification. It does NOT defend against replay (see DKIM replay attacks) or against compromise of the signing private key (mitigated by key rotation — see DKIM key rotation).

1. Overview: what DKIM cryptography is and why it matters

DomainKeys Identified Mail (DKIM) is one of the three pillars of modern email authentication (alongside SPF and the DMARC policy layer built on top of them). DKIM works by attaching a cryptographic signature to every outgoing message and publishing the corresponding verification public key in DNS, so any receiver in the world can independently verify that the message body and selected headers have not been modified in transit and that the signing identity really did sign the message.

The cryptographic primitives DKIM relies on are well-studied: RSA (Rivest-Shamir-Adleman, 1977) for digital signatures over a SHA-256 hash, or the more modern Ed25519 (Bernstein et al., 2011) elliptic-curve digital signature scheme defined for DKIM by RFC 8463. The signing operation is standard public-key cryptography: a private key held by the sender produces a signature; a public key published in DNS lets anyone verify the signature. What DKIM contributes on top of the primitives is the canonicalization layer (so the signature survives legitimate transit modifications by intermediate MTAs) and the DNS publication format (so a receiver can locate the public key by domain and selector).

This page is the foundational cryptographic reference for the DKIM cluster. For DKIM DNS syntax, selectors, and deployment, see the pillar at DKIM explained. For the operational rotation procedure, see DKIM key rotation. For the security-research analysis of replay attacks (which DKIM by design does not prevent), see DKIM replay attacks. This page focuses on the cryptographic primitives themselves: what asymmetric cryptography is, how RSA and Ed25519 work in the DKIM context, what SHA-256 contributes, the five-step signing workflow, the five-step verification workflow, and the key-size and publication-format details that come up in real-world DKIM deployments.

2. Asymmetric (public-key) cryptography in plain language

Asymmetric cryptography (also called public-key cryptography) is a class of cryptographic algorithms that use two mathematically related keys instead of one. The two keys form a keypair: a private key that must be kept secret by its owner, and a public key that can be freely distributed. The mathematical relationship between the two keys is constructed so that:

• Anyone with the public key can verify a signature produced by the corresponding private key.
• Only the holder of the private key can produce a signature that verifies under the public key.
• Knowing the public key does not give an attacker the ability to derive the private key (this is the load-bearing assumption: it relies on the computational hardness of either integer factorisation for RSA or the elliptic-curve discrete-logarithm problem for Ed25519).

DKIM uses asymmetric cryptography in the digital-signature mode (not the encryption mode). The signing domain holds the private key on its mail-sending infrastructure and uses it to sign every outgoing message; the public key is published in DNS under a selector-scoped TXT record at selector._domainkey.example.com so every receiver in the world can verify the signature without needing to negotiate a shared secret with the sender.

The reason DKIM uses asymmetric cryptography rather than a shared-secret HMAC scheme is scalability. Email exchanges between any two domains; a shared-secret scheme would require every sending domain to negotiate and exchange a secret with every receiving domain in the world, which does not scale to internet email. Public key cryptography lets the sender publish its verification key once in DNS, and every receiver in the world can independently locate it.

3. RSA in DKIM (rsa-sha256)

RSA (Rivest-Shamir-Adleman, 1977) is the historically dominant public-key signature algorithm and the default DKIM signing algorithm per RFC 6376 and RFC 8301. An RSA keypair is generated by selecting two large prime numbers, computing their product (the modulus), and deriving a related private exponent and public exponent. The security of RSA rests on the computational hardness of factoring the modulus back into its prime factors: a 2048-bit modulus is currently believed to require approximately 2^112 operations to factor with the best-known classical algorithms, placing it well beyond the reach of any foreseeable computing resource.

The DKIM signing algorithm name rsa-sha256 denotes the combination of RSA signature generation over a SHA-256 hash of the canonicalized signed-headers blob. The older rsa-sha1 algorithm is deprecated by RFC 8301 because the SHA-1 hash function was demonstrated to admit practical collisions in 2017 (Stevens et al., the "SHAttered" attack). Modern DKIM signers MUST use rsa-sha256; receivers SHOULD reject rsa-sha1 signatures.

The a= tag in the DKIM-Signature header declares the algorithm. A modern conforming signature looks like:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=example.com; s=mail2026; t=1747843200;
    h=From:To:Subject:Date:Message-ID;
    bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
    b=Z8sLqp...base64encoded2048bitRSAsignature...sKf3Q==

The k= tag in the DNS TXT record declares the matching key type (k=rsa). A 2048-bit RSA public key base64-encoded is approximately 392 characters, which does not fit in a single 255-byte DNS TXT character-string (see section 11).

4. Ed25519 in DKIM (ed25519-sha256, RFC 8463)

Ed25519 (Bernstein, Duif, Lange, Schwabe, Yang, 2011) is a modern elliptic-curve digital signature algorithm defined for DKIM by RFC 8463. Ed25519 signatures are built on the Curve25519 elliptic curve and rely on the computational hardness of the elliptic-curve discrete-logarithm problem (ECDLP), which is fundamentally different from the integer-factorisation problem underlying RSA.

The practical advantages of Ed25519 over RSA-2048 for DKIM are:

• Smaller public keys: 32 bytes raw, 44 bytes base64-encoded. An Ed25519 DKIM public-key TXT record fits comfortably in a single DNS character-string with no splitting.
• Smaller signatures: 64 bytes raw, 88 bytes base64-encoded in the b= tag — versus approximately 344 base64 characters for RSA-2048.
• Faster signing and verification: Ed25519 signing is roughly 10x faster than RSA-2048 signing on commodity hardware; verification is roughly 2x faster.
• Strong cryptographic margins: Ed25519 provides approximately 128-bit security against the best-known classical attacks, comparable to RSA-3072 in security margin but with much smaller keys.

The DKIM signing algorithm name ed25519-sha256 denotes Ed25519 signature generation over a SHA-256 hash. A conforming Ed25519 DKIM signature looks like:

DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed;
    d=example.com; s=ed2026; t=1747843200;
    h=From:To:Subject:Date:Message-ID;
    bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
    b=Z8sLqp...base64encoded64byteEd25519signature==

The DNS TXT record uses k=ed25519 to declare the key type. The practical caveat is receiver-side support: RFC 8463 was published in 2018 and major receivers (Gmail, Microsoft, Yahoo, Apple) support Ed25519 verification, but smaller MTAs and self-hosted Postfix or Exim deployments may not. The canonical safe deployment publishes BOTH an RSA-2048 selector AND an Ed25519 selector and signs each outgoing message with both signatures; receivers verify whichever they support, and the message passes DKIM if either signature verifies (RFC 8463 section 5).

5. The SHA-256 hash function in DKIM

SHA-256 is the cryptographic hash function used by both rsa-sha256 and ed25519-sha256 to produce a fixed-length 256-bit (32-byte) digest of the canonicalized body and of the canonicalized signed-headers blob. SHA-256 was standardised by NIST in FIPS 180-2 (2002) and is one of the SHA-2 family of hash functions, distinct from the older and now-broken SHA-1.

DKIM uses the SHA-256 hash for two distinct purposes:

• Body hash: the SHA-256 digest of the canonicalized body is base64-encoded into the bh= tag of the DKIM-Signature header. The body hash gives DKIM verifiers a way to confirm the message body has not been modified in transit.
• Signed-headers hash: the SHA-256 digest of the canonicalized signed-headers blob (including the DKIM-Signature header itself with an empty b= placeholder) is the input the RSA or Ed25519 signature is actually computed over. The signature does NOT sign the body directly — it signs the hash of the signed-headers blob, which itself contains the body hash.

The two-level structure (body hash inside signed-headers hash inside signature) is the cryptographic chain that gives DKIM its security properties: a modification to any byte of the canonicalized body changes the body hash; a different body hash changes the signed-headers blob; a different signed-headers blob changes the SHA-256 hash the signature was computed over; the signature no longer verifies. Each link in the chain is cryptographically strong (SHA-256 is collision-resistant; RSA-2048 and Ed25519 signatures are forgery-resistant under the standard hardness assumptions).

The older rsa-sha1 algorithm deprecated by RFC 8301 used SHA-1 (160-bit digest) instead of SHA-256. SHA-1 was demonstrated to admit practical collisions in 2017 (the SHAttered attack by Stevens, Bursztein, Karpman, Albertini, and Markov), and theoretical work going back to 2005 had already weakened SHA-1 below the security margins required for digital signatures. Modern DKIM signers MUST use SHA-256.

6. The five-step DKIM signing operation

A DKIM signer (typically the outbound MTA or a library inside an application sending mail) follows a fixed five-step sequence to produce a DKIM-Signature header for an outgoing message. Understanding this sequence is essential for debugging DKIM verification failures.

1. Step 1: Canonicalize the body. Apply the body canonicalization algorithm (simple or relaxed; relaxed is recommended). Relaxed-body strips trailing whitespace from each line, collapses multiple internal whitespace runs to a single space, and removes empty trailing lines. Simple-body strips only trailing empty lines after the last non-empty line.
2. Step 2: Compute the body hash. Compute the SHA-256 hash of the canonicalized body and base64-encode the 32-byte digest into a 44-character string. Place this string in the bh= tag of the DKIM-Signature header that is being constructed.
3. Step 3: Build the signed-headers blob. Assemble the headers listed in the h= tag (typically From, To, Subject, Date, Message-ID, Reply-To, plus any others the sender chooses to bind to the signature) in the order they appear in the message, in their canonicalized form (relaxed-headers lowercases header names, unfolds folded lines, and strips trailing whitespace from values). Append the DKIM-Signature header itself with an empty b= tag placeholder. The concatenation is the signed-headers blob.
4. Step 4: Sign the signed-headers blob. Compute the SHA-256 hash of the signed-headers blob. Apply the configured signing algorithm (RSA private-key sign, producing an approximately 256-byte signature for RSA-2048; or Ed25519 private-key sign, producing a 64-byte signature). The signing operation is a single private-key operation on the 32-byte SHA-256 hash; the body itself is not passed to the signing operation.
5. Step 5: Base64-encode the signature. Base64-encode the raw signature bytes (344 characters for RSA-2048; 88 characters for Ed25519) and replace the placeholder b= tag value with the encoded signature. The completed DKIM-Signature header is now attached to the outgoing message before transmission.

The signing operation is deterministic for a given (message, private key, algorithm, canonicalization) tuple in the case of RSA (PKCS#1 v1.5 deterministic padding) and in the case of Ed25519 (which is deterministic by construction). The same message signed twice with the same key produces the same signature.

7. The five-step DKIM verification operation

A DKIM verifier (typically the inbound MTA or an anti-abuse library at the receiver) follows the same five steps in reverse to validate a DKIM-Signature header on an incoming message:

1. Step 1: Parse the DKIM-Signature header. Extract the tags: v= (version, always 1), a= (algorithm), c= (canonicalization pair), d= (signing domain), s= (selector), h= (signed headers list), bh= (body hash), b= (signature), t= (timestamp), x= (expiry, if present).
2. Step 2: Fetch the public key from DNS. Look up the TXT record at {selector}._domainkey.{d-value} (for example mail2026._domainkey.example.com). Parse the returned TXT body for the v=DKIM1; k=rsa; h=sha256; p=<base64-encoded-public-key> tags. Base64-decode the public-key bytes. If the record is missing, malformed, or revoked (p= empty), DKIM verification fails with dkim=none or dkim=permerror.
3. Step 3: Recompute the body hash. Apply the body canonicalization algorithm declared in the c= tag to the received body. Compute the SHA-256 hash of the canonicalized body. Base64-encode the 32-byte digest. Compare against the bh= value in the DKIM-Signature header. If the values differ, DKIM verification fails with body-hash-mismatch.
4. Step 4: Reconstruct the signed-headers blob. Assemble the canonicalized headers in the order listed in the h= tag, followed by the DKIM-Signature header itself with an empty b= tag placeholder (the b= value in the received header is replaced with the empty string for hashing purposes). Compute the SHA-256 hash of the assembled blob.
5. Step 5: Verify the signature. Base64-decode the b= value into raw signature bytes. Apply the public-key verification operation appropriate to the algorithm declared in the a= tag (RSA-2048 verify, or Ed25519 verify) using the public key fetched in step 2 and the SHA-256 hash computed in step 4. If verification succeeds, the signature is valid and the message has not been modified in transit. If verification fails, DKIM verification fails with dkim=fail.

A passing DKIM verification result is what the DMARC alignment layer requires: DMARC checks that the d= value of the passing DKIM signature aligns with the From: header domain (strictly or relaxed per the adkim= DMARC tag). DKIM verification with a non-aligned d= is still a passing DKIM result but does not contribute to DMARC alignment.

8. Canonicalization and why it matters cryptographically

Canonicalization is the normalisation step that prepares the message body and signed headers for hashing. Without canonicalization, the body hash and the signed-headers hash would be invalidated by virtually any transit modification: trailing whitespace stripping by an intermediate MTA, header refolding by a mailing-list server, character-case changes in a header field name, or any of a dozen other benign modifications that internet email routinely applies.

RFC 6376 defines two body canonicalization algorithms and two header canonicalization algorithms; the c= tag declares which pair the signer chose, in the form c=header/body:

• simple/simple: minimal normalisation. Headers passed through verbatim; body trailing empty lines stripped. Brittle in practice — many legitimate transits break this.
• relaxed/relaxed (recommended): relaxed-headers lowercases the header name, unfolds folded lines, strips trailing whitespace from the header value, and collapses internal whitespace runs in the value to a single space; relaxed-body strips trailing whitespace from each line, collapses internal whitespace runs to a single space, and removes empty trailing lines. Survives the vast majority of legitimate transit modifications.
• simple/relaxed and relaxed/simple: the two mixed combinations are permitted but rarely used in practice.

The cryptographic significance of canonicalization is that it defines the input bytes the signature is computed over. The signer and the verifier MUST apply identical canonicalization rules; otherwise the recomputed hash at the verifier will not match the one computed at the signer, and verification will fail even though the underlying content is logically unchanged. The c= tag in the DKIM-Signature header is the explicit synchronisation mechanism: it tells the verifier exactly which canonicalization pair to apply.

Common signer-side mistakes (covered in section 13) include omitting the c= tag (which defaults to simple/simple, a strict canonicalization that breaks easily) and forgetting that the signed-headers blob during verification includes the DKIM-Signature header itself with an empty b= placeholder — not the literal received header string.

9. RSA key sizes and the 1024-bit deprecation

RFC 8301 (Cryptographic Algorithm and Key Usage Update to DKIM, 2018) updated RFC 6376 with current cryptographic guidance. The relevant requirements are:

• Minimum RSA key size: 1024 bits for verification, 2048 bits recommended for signing. Signers MUST publish keys at least 1024 bits long and SHOULD publish keys of at least 2048 bits.
• Maximum RSA key size: RFC 8301 caps RSA verification keys at 4096 bits (some receivers may reject larger keys because the DNS encoding becomes unwieldy).
• Required hash: SHA-256. SHA-1 is prohibited (deprecated post-SHAttered).
• Required canonicalization: no requirement, but relaxed/relaxed is the de-facto standard.

The practical guidance from NIST SP 800-57 part 3 (Application-Specific Key Management Guidance, 2015 / 2020) deprecates 1024-bit RSA for new signing keys: NIST projects that 1024-bit RSA may become factorable by nation-state-scale resources in the late 2020s. Operators publishing new DKIM signing keys in 2026 should use 2048-bit RSA at minimum; 3072-bit RSA is a reasonable conservative choice for high-value senders; Ed25519 (RFC 8463) is the modern cryptographic alternative.

The base64-encoded DKIM public-key sizes are approximately:

• RSA-1024: 216 characters base64 — fits in a single 255-byte DNS TXT character-string.
• RSA-2048: 392 characters base64 — does NOT fit in a single character-string, must be split.
• RSA-3072: 564 characters base64 — must be split into 3+ strings.
• RSA-4096: 736 characters base64 — must be split into 3+ strings.
• Ed25519: 44 characters base64 — fits comfortably in one string.

10. DNS TXT record key-publication format

The DKIM public key is published as a TXT record at the name {selector}._domainkey.{signing-domain}. The TXT body is a semicolon-delimited list of tag=value pairs. The defined tags per RFC 6376 section 3.6 are:

• v=DKIM1 — version, RECOMMENDED (defaults to DKIM1 if absent).
• k=rsa or k=ed25519 — key algorithm. Defaults to rsa if absent.
• h=sha256 — hash algorithm. Defaults to allow any supported hash if absent; modern keys SHOULD declare h=sha256 per RFC 8301.
• s=email — service type. Defaults to * (all). The email value scopes the key to email signing.
• n=... — notes, free-form. Not cryptographically significant.
• p=<base64-encoded-public-key> — the public key itself. MANDATORY. An empty p= value revokes the key (signatures referencing this selector will fail verification).
• t=y — testing mode (signatures treated as invalid by the verifier even if they otherwise verify). For deployment testing only; remove for production.

A canonical 2048-bit RSA DKIM TXT record looks like this (with the long p= value split across multiple character-strings — the receiver concatenates them transparently):

mail2026._domainkey.example.com. 300 IN TXT (
  "v=DKIM1; k=rsa; h=sha256; s=email; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvfZ..."
  "...wWl0iiE9dQwIDAQAB"
)

An Ed25519 DKIM TXT record fits comfortably in a single string because the public key is only 32 bytes:

ed2026._domainkey.example.com. 300 IN TXT
  "v=DKIM1; k=ed25519; h=sha256; s=email; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo="

The 255-byte character-string limit on DNS TXT records comes from RFC 1035 section 3.3.14. A single TXT record can contain multiple character-strings, each enclosed in its own quotes, and the receiver resolver concatenates them before passing the body to the DKIM parser. This is a DNS encoding detail with no cryptographic significance; it is the most common source of DKIM TXT-record errors when an operator pastes a long key into a DNS provider UI that does not split it automatically.

11. Best practices for DKIM cryptography

• Publish 2048-bit RSA keys at minimum. Do not publish new 1024-bit keys in 2026 or later. NIST SP 800-57 part 3 deprecates 1024-bit RSA for new signing keys.
• Use rsa-sha256, never rsa-sha1. RFC 8301 prohibits SHA-1. Receivers SHOULD reject SHA-1 signatures.
• Declare c=relaxed/relaxed explicitly. The default (simple/simple) breaks easily on legitimate transits. Relaxed/relaxed is the de-facto standard.
• Use h=sha256 in the DNS TXT record. Modern DKIM verifiers prefer explicit declaration; some legacy verifiers default to allowing SHA-1, which is unsafe.
• Use s=email in the DNS TXT record. The email service-type value scopes the key to email signing and prevents misuse for other DKIM applications.
• Rotate signing keys regularly. Monthly or quarterly for high-value senders; annually at minimum. See DKIM key rotation for the operational procedure.
• Publish a short TTL on the DKIM TXT record. 300 seconds (5 minutes) is a reasonable default. Short TTLs enable fast emergency key rotation if the private key is compromised.
• Consider Ed25519 (RFC 8463) for new deployments. Dual-algorithm deployment (RSA-2048 selector + Ed25519 selector) gives modern receivers the smaller, faster signature while maintaining compatibility with receivers that do not yet support Ed25519.
• Sign with as many headers as practical. The h= tag should include From, To, Cc, Subject, Date, Message-ID, Reply-To, References, In-Reply-To, and any other headers an attacker could usefully manipulate. Signing more headers broadens the bytes the signature binds.
• Sign From: at least once, twice if possible. The h= tag can list From: twice; the second occurrence binds against From-header injection attacks where an attacker prepends a second From: header that some MUAs display in preference to the original.
• Protect the private key. Store on disk with mode 0400 owned by the MTA user. Do not commit to version control. Treat compromise as a security incident requiring immediate rotation.
• Monitor DMARC aggregate reports for DKIM failures. A sudden increase in dkim=fail in DMARC RUA reports often indicates a canonicalization mismatch, key-rotation misstep, or content-modifying intermediary.

12. Common DKIM cryptography mistakes

• Publishing a 1024-bit RSA key in 2026. Deprecated by NIST. Use 2048-bit at minimum.
• Forgetting to split a 2048-bit RSA key across multiple TXT character-strings. A 392-character base64-encoded key does not fit in a single 255-byte string. Some DNS provider UIs split automatically; others require the operator to insert quote-string boundaries manually.
• Including the -----BEGIN PUBLIC KEY----- and -----END PUBLIC KEY----- PEM armour in the p= tag. The p= tag holds only the raw base64-encoded key bytes, not the PEM-wrapped form. Strip the armour and the embedded newlines before pasting into the DNS UI.
• Using rsa-sha1. Prohibited by RFC 8301 since 2018. Modern receivers MAY reject SHA-1 signatures outright.
• Forgetting t=y in production. The testing-mode flag instructs verifiers to treat the signature as invalid even if it otherwise verifies. Remove from the TXT record before going live.
• Mixing canonicalization algorithms. The c= tag declares one pair (header/body); the signer must apply the declared pair consistently. A mismatch between signer and verifier results in body-hash-mismatch on every message.
• Not including the DKIM-Signature header with empty b= in the signed-headers blob. The DKIM-Signature header is itself signed (with the b= placeholder) so the signature binds the metadata of its own construction. Forgetting this step produces signatures that fail verification at every receiver.
• Reusing a selector after publishing a different public key. Once published, a selector should be retired after rotation rather than reused. Receivers may cache the old public key briefly even after DNS TTL expiry.
• Empty p= tag without intent to revoke. An empty p= value tells the verifier the key has been revoked; signatures referencing this selector will fail. A misconfigured empty p= can accidentally revoke a live signing key.
• Forgetting that DKIM does not sign the SMTP envelope. MAIL FROM and RCPT TO are NOT covered by DKIM. This is the structural reason DKIM cannot prevent replay attacks — an attacker can change the envelope while keeping the body and signed headers (and therefore the signature) intact.

13. FAQ — common questions about DKIM cryptography

What is DKIM cryptography?

DKIM cryptography is the public-key (asymmetric) digital-signature scheme used by DomainKeys Identified Mail (RFC 6376) to bind a signing identity to the body and selected headers of an email message. The signer holds a private key; the public key is published in DNS under a selector-scoped TXT record. The signing algorithm is rsa-sha256 (RSA over SHA-256) by default, with ed25519-sha256 (RFC 8463) as the modern alternative.

How does DKIM signing actually work step by step?

Five steps. Step 1: canonicalize the message body (relaxed/relaxed is recommended). Step 2: compute a SHA-256 hash of the canonicalized body and base64-encode into the bh= tag. Step 3: assemble the canonicalized signed-headers blob including the DKIM-Signature header itself with empty b= placeholder. Step 4: sign the SHA-256 hash of the blob with the private key (RSA-2048 or Ed25519). Step 5: base64-encode the signature into the b= tag. The completed DKIM-Signature header is attached to the outgoing message.

Is RSA-1024 still safe for DKIM in 2026?

No. RFC 8301 sets the floor for DKIM RSA keys at 1024 bits but recommends 2048; NIST SP 800-57 part 3 deprecates 1024-bit RSA for new signing keys. Public-research factoring of 1024-bit RSA has not been demonstrated but is within projected reach of nation-state-scale resources by the late 2020s. Publish 2048-bit RSA at minimum; Ed25519 (RFC 8463) is the modern alternative.

Should I use Ed25519 instead of RSA for DKIM?

Ed25519 is preferable cryptographically: shorter keys (32 bytes versus 256 bytes for RSA-2048), faster signing and verification, no 255-byte TXT-segment splitting, strong cryptographic margins. The practical caveat is receiver-side support. The canonical safe deployment publishes BOTH an RSA-2048 selector AND an Ed25519 selector and signs with both; receivers verify whichever they support (RFC 8463 section 5).

What is the DKIM body hash?

The DKIM body hash is the base64-encoded SHA-256 digest of the canonicalized message body, published in the bh= tag of the DKIM-Signature header. It gives DKIM verifiers a way to confirm the message body has not been modified in transit. The body hash is computed AFTER body canonicalization, so legitimate transit normalisation does not invalidate it.

What is SHA-256 in DKIM and why not SHA-1?

SHA-256 is the cryptographic hash function used by rsa-sha256 and ed25519-sha256 to produce a fixed-length 256-bit digest of the canonicalized body and the signed-headers blob. RFC 8301 deprecates the older rsa-sha1 because SHA-1 was demonstrated to admit practical collisions in 2017 (the SHAttered attack). Modern signers MUST use rsa-sha256 or ed25519-sha256.

What is DKIM canonicalization and why does it matter cryptographically?

Canonicalization is the normalisation step that prepares the body and signed headers for hashing. The recommended combination is relaxed/relaxed, which tolerates trailing-whitespace stripping, header refolding, and other common transit modifications. Without canonicalization, the body and signed-headers hashes would be invalidated by virtually any benign transit modification by intermediate MTAs.

Why is my DKIM public key split across multiple strings in DNS?

DNS TXT record character-strings are limited to 255 bytes per RFC 1035 section 3.3.14. A 2048-bit RSA public key base64-encoded with DKIM tags is approximately 420 bytes long and must be split across multiple character-strings (each in its own quotes) within a single TXT record. The receiver resolver concatenates them transparently. Ed25519 public keys (44 bytes base64) fit comfortably in a single string.

14. Related guides

• DKIM explained — the DKIM pillar covering DNS syntax, selectors, deployment, and high-level troubleshooting. Start here if DKIM is new to you; return here for the cryptographic primitives.
• DKIM DNS record syntax — the CRYPTO-ALGORITHM-FIELDS-RESOLVE-TO- DNS-BYTE-SYNTAX companion to this DKIM cryptography deep dive. Where THIS page documents the cryptographic primitives underlying DKIM (RSA / ed25519 key pair generation, public-key / private-key partition, SHA-256 hash function, the BASE64-encoded public-key wire format, recommended key strengths, replay-resistance properties), the DKIM DNS-record-syntax spoke is the BYTE-SYNTAX REFERENCE documenting how each cryptographic primitive THIS page covers RESOLVES to a specific tag field in the published selector._domainkey.<domain> TXT record. The CRYPTO-ALGORITHM-FIELDS- RESOLVE-TO-DNS-BYTE-SYNTAX cross-reference establishes five specific crypto-primitive- to-DNS-tag mappings: (i) key-type algorithm primitive → k= tag value in the TXT record — k=rsa (default per RFC 6376) OR k=ed25519 (per RFC 8463 extension); THIS page's "which algorithm to use" decision RESOLVES to the k= tag value the operator publishes; (ii) public-key primitive (the BASE64-encoded SubjectPublicKeyInfo blob) → p= tag value in the TXT record — the byte-syntax spoke documents the 255-octet TXT-chunking constraint that splits a 2048-bit RSA public key across multiple quoted substrings; THIS page's "how big is the public key" answer RESOLVES to a specific p= field length in the wire format (≈216 chars for 2048-bit RSA, ≈44 chars for ed25519); (iii) hash- algorithm primitive → h= tag value (in the DNS record, not the signature header) — the byte- syntax spoke documents the h=sha256 default vs h=sha1 deprecated value; THIS page's "which hash function" answer RESOLVES to the published h= constraint set the receiver enforces; (iv) key-revocation primitive → p= empty-value semantics — the byte-syntax spoke documents the RFC 6376 §3.6.1 revocation convention where p= with empty value (or absent) signals key revocation; THIS page's key-rotation / key-compromise lifecycle discussion RESOLVES to the operator's p=-empty publication step at revocation time; (v) testing-mode / service- type primitive → t=y / t=s / s=email tag values in the TXT record — the byte-syntax spoke documents the four canonical t= / s= flag combinations that constrain how receivers SHOULD interpret the published key (testing-only, strict-d=-match-required, service-type- scoped-to-email, etc.). Read THIS page when authoring the cryptographic primitives the operator deploys; read the DKIM DNS- record-syntax spoke for the byte-format reference whose tag fields RESOLVE the cryptographic decisions at the wire-format layer the receiver parses.
• DKIM selectors explained — the selector address-space deep dive that names WHICH public key under _domainkey.example.com the receiver fetches to verify a given signature. Selectors are the DNS-level addressing layer wrapping the cryptographic primitives this page documents: the eight canonical naming patterns (numbered / dated / provider / short-letter / opaque / purpose / domain-prefix / hosted-prefix), the seven failure modes, and the eleven provider conventions. Without correct selector publication the public key documented here is unreachable; without the cryptography here the published selector key has nothing to verify.
• DKIM key rotation — the operational rotation procedure that relies on the cryptographic primitives this page documents. The canonical dual-selector zero-downtime procedure and the per-provider automation matrix.
• DKIM signatures explained — the DKIM-Signature header byte-layout sibling whose a= algorithm tag THIS page documents — the DKIM-cluster sibling that documents the full DKIM-Signature header byte-layout in which the a= signing- algorithm tag this page describes (the rsa-sha256 / ed25519-sha256 / legacy rsa-sha1 values per RFC 6376 §3.5 + RFC 8463 §3) is one of fourteen tags (v, a, b, bh, c, d, h, i, l, q, s, t, x, z). Where THIS page documents the cryptographic primitives the a= tag value selects (RSA-2048 vs Ed25519 keypair generation, SHA-256 hashing, the RSASSA-PKCS1-v1_5 signature scheme per RFC 8017 §8.2 for RSA, the Edwards-curve signature scheme per RFC 8032 §5.1 for Ed25519, and the per-algorithm key-size, signature-size, and computational-cost properties), the signatures-explained spoke documents the LARGER container the a= tag lives in — the DKIM-Signature header itself, the tag-grammar per RFC 6376 §3.5 that the a= tag obeys, the operationally-load-bearing interactions between a= and the b= signature-data tag (the byte-length and base64-encoding of b= is determined by the algorithm selected in a= — RSA-2048 produces ~256-byte signatures encoded as ~344 base64 chars, Ed25519 produces 64-byte signatures encoded as ~88 base64 chars), and the position of a= in the canonical operator-published tag order (v=1; a=...; c=...; d=...; s=...; h=...; bh=...; b=...). Read the signatures-explained spoke when an operator asks "where exactly in the DKIM-Signature header does the a= tag live, and how does the algorithm choice impact the signature-byte structure" — the spoke is the authoritative DKIM-Signature- header byte-layout sibling of the cryptographic-algorithm deep dive on this page. Closes the DKIM-cluster sibling-orphan parity gap between dkim_cryptography_basics (the a=-tag algorithm reference) and dkim_signatures_explained (the DKIM-Signature-header byte-layout reference).
• DKIM canonicalization explained (simple vs relaxed) — the byte-level input-normalisation layer that determines exactly WHICH bytes the cryptographic hash on this page computes over. Covers the two header algorithms (simple per RFC 6376 section 3.4.1 and relaxed per section 3.4.2), the two body algorithms (simple per section 3.4.3 and relaxed per section 3.4.4), the four c= tag combinations, the optional l= partial- body-length tag with its security trade-off, and the seven most common body-hash mismatch causes that cause SHA-256 verification to fail despite the cryptography being intact (forwarder whitespace folding, mailing-list footer injection, content-transform middleware, transfer-encoding changes, MIME re- encoding, trailing CRLF normalisation, Subject-prefix rewriting). Read this as the per-message processing layer that wraps the cryptographic primitives documented here — the bh= body hash on this page is the SHA-256 of the canonicalized body, not the raw body, and the b= signature is over the canonicalized signed-headers list, not the raw headers.
• DKIM replay attacks — the security-research deep dive on a cryptographically valid signature being re-used to send the same message to attacker-chosen recipients. DKIM by design does not prevent replay; the mitigation depends on aggressive key rotation.
• How attackers bypass weak DMARC — the DKIM-CRYPTOGRAPHIC-PRIMITIVE- CHOICE-AT-PUBLISHER-DETERMINES-ATTACKER- BYPASS-VECTOR-CEILING companion to this DKIM cryptography primer. Where THIS page documents the UNDERLYING CRYPTOGRAPHIC PRIMITIVES the DKIM-signing operator selects between (the RFC 6376 §3.3 RSA-SHA256 algorithm, the 1024 / 2048 / 4096 RSA key-size matrix, the RFC 8463 Ed25519 elliptic-curve migration with ~128-bit security at 32-byte key size, the RFC 8301 SHA-1 deprecation, the public-key verification chain from p=-tag SubjectPublicKeyInfo DER through SHA-256 body hash to b=-tag signature), the attacker-bypass spoke documents how the ATTACKER USES THE PUBLISHER'S PRIMITIVE CHOICES to compute the bypass-vector ceiling at the cryptographic-perimeter boundary. FOUR structurally-distinct CRYPTOGRAPHIC-PRIMITIVE-VS-ATTACKER- BYPASS-VECTOR-CEILING dimensions emerge from the side-by-side comparison: (1) RSA-1024 key-length-as- attacker-factoring-bypass-vector — the bypass-spoke's catalogue documents the 2009 768-bit RSA factoring milestone AND the projected 2030-deprecation window for RSA-1024 as the cryptographic boundary BELOW WHICH a nation-state- capable adversary can compute the publisher's PRIVATE key from the publisher-published PUBLIC p= tag, after which the attacker forges legitimately-signed DKIM signatures for ARBITRARY message content under the publisher's own d= and selector at will (the cryptographic-key-recovery attacker-bypass vector class). THIS page's RSA-1024 → RSA-2048 → RSA-4096 key-size trade-off matrix is the publisher-side knob that the attacker- bypass spoke proves is the SOLE determinant of bypass-vector ceiling height at the cryptographic-key-recovery boundary. (2) RSA-vs-Ed25519 algorithm-as-attacker-side-channel- and-quantum-resistance-bypass-vector ceiling — the bypass-spoke catalogues two distinct algorithm- boundary attacker-bypass classes: side- channel attacks against RSA key-recovery via cache-timing, power-analysis, Spectre-class transient-execution leakage on shared-tenant signing infrastructure; and post-quantum bypass-vector windows where Shor's algorithm on a sufficiently large quantum computer factors RSA-2048+ in polynomial time but Ed25519's elliptic-curve discrete-log problem retains hardness against known quantum attacks (UNTIL the post-quantum cryptography migration ships). THIS page's RFC 8463 Ed25519 migration recommendation is the publisher-side action whose attacker-bypass-vector- ceiling-elevation effect the bypass-spoke documents at both the current-era side-channel and the projected post-quantum boundary. (3) SHA-256-vs-SHA-1-hash- function-as-attacker-collision-bypass- vector ceiling — the bypass- spoke documents the SHAttered-era SHA-1 collision attack (2017, Google/CWI joint research) and the cascade of RFC 8301's SHA-1 deprecation across DKIM-signing infrastructure as the cryptographic boundary BELOW WHICH an attacker can construct a SECOND message body whose canonical SHA-1 body hash MATCHES a legitimately-signed message's body hash, producing a cryptographically-valid DKIM signature for ATTACKER-CHOSEN content under the publisher's own d= and selector (the hash-collision-payload-substitution attacker-bypass vector class). THIS page's SHA-256-as-canonical-body-hash documentation per RFC 6376 §3.5 is the publisher-side baseline that locks the bypass-vector ceiling against hash-collision substitution attacks whose feasibility the bypass-spoke documents at the SHA-1 boundary. (4) Public-exponent-e=65537 -vs-low-exponent-as-attacker-fault- injection-bypass-vector ceiling — the bypass-spoke catalogues the historical RSA low-public-exponent attack class (Coppersmith small- exponent attacks where e=3 permits cube-root recovery of short plaintexts; Boneh-Joux-Nguyen attacks on e=3 in specific RSA- signing modes) as the cryptographic boundary AT WHICH a publisher's choice of public exponent away from the standard e=65537 (the F4 Fermat prime balancing speed vs security margin) creates structural attacker-bypass windows. THIS page's public-exponent e=65537 canonical recommendation is the publisher-side default that locks the bypass-vector ceiling against low-public-exponent attacks whose cryptographic mechanics the bypass- spoke documents at the Coppersmith / Boneh boundary. Read the attacker-bypass spoke alongside THIS page when sizing the DKIM signing posture against THREAT EXPECTATIONS: this page tells you HOW the cryptographic primitives work mathematically, the bypass- spoke tells you WHAT THE ATTACKER DOES at each primitive's failure boundary AND WHY the publisher's primitive-choice ceiling directly determines the bypass-vector floor.
• DKIM best practices (the 15 deployment rules) — the operational recommendation catalogue whose Rule 2 codifies the cryptographic-primitive choice this page documents in depth. Where THIS page is the signing-math deep dive covering RSA-SHA256 per RFC 6376 §3.3, the 1024 / 2048 / 4096 RSA key-size trade-off matrix, the SHAttered-era SHA-1 deprecation per RFC 8301, the Ed25519 elliptic-curve migration per RFC 8463 with ~128-bit security equivalent to 3072-bit RSA at 32-byte key size, and the public-key verification chain from p=-tag SubjectPublicKeyInfo DER through SHA-256 body hash to b=-tag signature, best-practices Rule 2 is the operator deliverable: RSA ≥ 2048 (NEVER 1024) or Ed25519 as the production algorithm/key-size posture. The 2048-bit floor matches the M3AAWG and NIST 2030-deprecation guidance the cryptography- basics page documents from the academic side (the 2009 768-bit factoring milestone bracketed the gap to 1024-bit security margin). Best-practices also locks in adjacent crypto-touching rules: Rule 4 (annual rotation cadence — bounds the cryptographic-validity window for a compromised key per the threat-model on the replay-attacks page), Rule 9 (the t=y testing-flag burn-in window that lets receivers exercise the verification chain before enforcement), and Rule 11 (multi-signature double-signing with two algorithms — RSA + Ed25519 side-by-side — that hedges against a receiver lacking Ed25519 support while future-proofing against an RSA-2048 deprecation event). Read best-practices alongside this page when sizing the DKIM signing posture: this page tells you HOW the cryptographic primitives work and WHY each algorithm choice has the strength margin it does, best-practices tells you WHICH algorithm + key-size combination to ship in production and WHY that combination balances current-receiver compatibility against the projected deprecation timeline.
• DKIM troubleshooting — the CRYPTOGRAPHIC-PRIMITIVE-CHOICE-TROUBLESHOOTING companion to this DKIM cryptography primer. Where THIS page documents the UNDERLYING PRIMITIVE CHOICES the DKIM-signing operator selects between (the a=rsa-sha256 / a=ed25519-sha256 algorithm choice from RFC 6376 + RFC 8463, the RSA-1024 / RSA-2048 / RSA-4096 key- length decision balancing brute-force resistance against DNS TXT-record 413-byte limits, the SHA-256 vs the deprecated SHA-1 hash choice from RFC 8301, the public-exponent e=65537 standard, the Ed25519 elliptic-curve 256-bit fixed- size signature vs the RSA modulus- length-dependent signature, the public- key TXT-record encoding format v=DKIM1; k=rsa; p=<base64> vs v=DKIM1; k=ed25519; p=<base64>), the troubleshooting spoke documents the OPERATOR DIAGNOSIS PATH for translating a CRYPTO-PRIMITIVE-CAUSED DKIM-failure observation into a concrete remediation. The crypto-primitive failure surface is STRUCTURALLY-PARTITIONED into eight diagnosis classes the troubleshooting spoke catalogues: (i) algorithm-not-supported by receiver (receiver applies RFC 8301 §3.1 sha1-deprecation and emits dkim=fail (algorithm deprecated) for a=rsa-sha1 signatures — remediate by re-signing with a=rsa-sha256), (ii) key-length-too-short (RSA-512 / RSA-768 / RSA-1024 keys increasingly rejected by Gmail / Microsoft 365 / Yahoo with dkim=fail (insufficient key size) verdicts — remediate by re-issuing as RSA-2048 minimum; Ed25519 is fixed at 256 bits and considered equivalent-strength to RSA-3072), (iii) key-not- found at DNS (selector not published or not propagated — the receiver emits dkim=permerror (no key for signature) — remediate by publishing the <s>._domainkey.<d> TXT record or waiting on propagation), (iv) key- marked-revoked (the public key is published with an empty p= value per RFC 6376 §3.6.1 — emits dkim=permerror (key revoked) — remediate by rotating to a new selector with a new key), (v) key-too- large for DNS TXT-record (RSA-4096 produces a base64-encoded modulus exceeding the 413-byte TXT-record default — the receiver retrieves only the truncated key and emits dkim=fail (signature verification failed) — remediate by re-issuing as RSA-2048 or splitting the key across multiple TXT-strings per RFC 6376 §3.6.2.2), (vi) RSA padding-mode mismatch (signer uses PSS padding while verifier expects PKCS#1 v1.5 per RFC 6376 §3.3.1 — emits dkim=fail (cryptographic signature verification failed) — remediate by switching signer to PKCS#1 v1.5), (vii) hash- algorithm-mismatch (signer hashes with SHA-1 while verifier is configured for SHA-256-only per RFC 8301 §3.1 — remediate by switching signer to SHA-256), (viii) Ed25519-not-supported by receiver (legacy verifier software without RFC 8463 support emits dkim=neutral (unsupported algorithm) — remediate by dual-signing with both Ed25519 and RSA-SHA256 in parallel until verifier population adoption is universal). The troubleshooting spoke also documents the canonical openssl rsa -text -noout -pubin / openssl pkey diagnostic 1-liner for inspecting the published public key, the dig <s>._domainkey.<d> TXT +short retrieval verification, and the canonical per-platform remediation (Workspace's RSA-2048 default, M365's RSA-1024-default-with- manual-upgrade-to-RSA-2048, SendGrid's automatic RSA-2048 provisioning). Read the troubleshooting spoke whenever this page's crypto-primitive decision produces a verifier-side rejection — the spoke is the load-bearing crypto-primitive- failure remediation reference.
• DKIM for Microsoft 365 — the M365-TENANT-DKIM-PROVIDER-SPECIFIC DEPLOYMENT companion to this DKIM cryptography deep dive. Where THIS page documents the cryptographic primitives (RSA-2048 vs Ed25519 keypair generation per RFC 6376 §3.3 + RFC 8463 §3, SHA-256 body hashing per FIPS 180-4 §6.2, the RSASSA-PKCS1-v1_5 signature scheme per RFC 8017 §8.2, the BASE64-encoded SubjectPublicKeyInfo wire format, recommended key strengths, the SHAttered-era SHA-1 deprecation per RFC 8301, the per-algorithm key-size / signature-size / computational-cost properties), the DKIM-for- Microsoft-365 spoke is the M365-TENANT-SPECIFIC DEPLOYMENT REFERENCE documenting how each cryptographic primitive THIS page proves materialises inside the M365 tenant DKIM-signer at four structurally-distinct M365-tenant primitive-to-deployment boundaries: (i) RSA-key-size primitive → M365 provider-default-vs-operator-upgrade boundary — the M365 page documents the canonical Exchange-Online-tenant DKIM-signer provider-default at RSA-1024 per Microsoft's historical Exchange Online configuration (mentioned in this page's troubleshooting cross-reference as "M365's RSA- 1024-default-with-manual-upgrade-to-RSA-2048"), the canonical operator-side manual upgrade to RSA-2048 via Exchange admin center / PowerShell Rotate- DkimSigningConfig, and the Microsoft-managed key-publication topology at selector1._domainkey.<tenant-domain> / selector2._domainkey.<tenant- domain>; THIS page's "which RSA key size" decision RESOLVES to the M365-tenant operator's mandatory Exchange-admin-center upgrade-from-default step that the M365-DKIM spoke documents step-by-step; (ii) Ed25519- elliptic-curve primitive → M365-tenant Ed25519-support-status boundary — THIS page documents Ed25519 as the RFC 8463 post- quantum-resistant algorithm with ~128-bit security at 32-byte key size, but the M365-DKIM spoke documents that Exchange Online does NOT currently support Ed25519 signing (RSA-2048 remains the only operator-deployable algorithm on the M365-tenant DKIM-signer); THIS page's "Ed25519 vs RSA migration" decision matrix RESOLVES, for an M365-tenant operator, to a no-op on the M365 platform AND a parallel deployment-decision at any non-M365 sibling signing surfaces (third-party transactional ESPs that DO support Ed25519); (iii) key- rotation primitive → M365 dual-selector zero-downtime rotation discipline boundary — THIS page documents the cryptographic rationale for periodic key rotation (annual cadence per RFC 6376, accelerated to monthly / weekly per high-volume-sender best practice, post-compromise emergency rotation), and the M365-DKIM spoke documents the M365-tenant- specific dual-selector rotation procedure (the selector1-vs-selector2 toggle the Exchange admin center exposes for the Rotate-DkimSigningConfig cmdlet, the 24-48 hour rotation-cadence ceiling the M365 platform enforces, the zero-downtime rotation-window cryptographic-validity overlap), so THIS page's "how to safely rotate keys without breaking in-flight signatures" cryptographic-validity-window discipline RESOLVES to the M365-tenant operator's Exchange-admin-center dual-selector toggle the M365-DKIM spoke documents; (iv) SubjectPublicKeyInfo BASE64-wire-format primitive → M365 DNS-publication boundary with Microsoft-controlled tenant-DNS-zone- delegation — THIS page documents the BASE64-encoded SubjectPublicKeyInfo blob published in the p=-tag value of the selector._domainkey.<domain> TXT record (the ~216-char BASE64 substring for 2048-bit RSA, the byte-syntax constraints, the DNS-TXT 255-octet chunking the byte-syntax- spoke documents), and the M365-DKIM spoke documents the M365-tenant-specific publication topology where Microsoft-managed Exchange Online publishes the public key at selector1._domainkey.<tenant-domain> AND selector2._domainkey.<tenant- domain> via CNAME-delegation from the customer-controlled zone to the Microsoft- controlled <...>.onmicrosoft.com zone — so THIS page's "where exactly does the public key live on the wire" answer RESOLVES, for an M365 tenant, to the Microsoft-CNAME- delegated dual-selector publication discipline the M365-DKIM spoke documents at the customer- DNS-zone-vs-Microsoft-DNS-zone delegation boundary. Read THIS page when authoring the cryptographic-primitive choices the M365 tenant will inherit at provider default and operator upgrade; read the DKIM-for-Microsoft-365 spoke for the M365-tenant-specific deployment reference whose Exchange-admin-center procedure, dual-selector rotation discipline, and Microsoft- CNAME-delegation publication topology operationalise the cryptographic primitives THIS page documents at the M365-tenant deployment layer.
• DMARC alignment explained — DMARC requires a passing DKIM result AND alignment of the DKIM d= value with the From: header domain. Understanding DKIM cryptography is prerequisite to understanding why a DKIM-pass message might still fail DMARC.
• DMARC record tags explained — the DMARC DNS record tags including adkim= (DKIM alignment strictness). Tells the verifier how strictly to require d= equality with From:.
• SPF explained — the sibling authentication mechanism. SPF authenticates the SMTP envelope sender (which DKIM does not sign); the two mechanisms complement each other.
• DMARC aggregate reports (RUA) — the per-receiver aggregate-report format. The dkim_evaluation field in each report row carries the verification result for the cryptographic primitives this page documents.
• DMARC troubleshooting — the operational diagnostic guide. Most dkim=fail symptoms trace back to a canonicalization mismatch, a 255-byte TXT-string splitting error, or a rotation misstep.
• DMARC myths and misconceptions — the DKIM-CRYPTOGRAPHIC-FOUNDATION-AS- PRECONDITION-FOR-MYTH-REFUTATION companion documenting the 18-myth catalogue whose refutation arguments cite the RSA / Ed25519 / SHA-256 cryptographic primitives THIS page documents as the substrate underwriting the refutation. Where THIS page documents the DKIM cryptographic foundation (the RFC 6376 RSA-with- SHA-256 default signing-math, the RFC 8463 Ed25519 addition for elliptic-curve signing, the public-private key-pair mechanics with the DER-encoded SubjectPublicKeyInfo published in the selector's p= tag, the body-hash bh= computation over the canonicalized message body, the signature-bytes b= computation over the canonicalized headers plus body-hash, the 2048-bit-floor key-length recommendation post-2018, and the per-RFC-9103 x= expiration tag for replay-resistance), the myths-and- misconceptions spoke documents the operator-facing 18-myth catalogue whose refutation arguments structurally depend on the cryptographic foundation: Myth #2 "DMARC encrypts email" is refuted by pointing out that the DKIM cryptographic signature THIS page documents proves message-INTEGRITY (the message was not tampered with after the signing MTA) and message- AUTHENTICATION (the signing domain controls the published public key) but provides NO confidentiality — DMARC and its DKIM building-block layer operate on cleartext SMTP, and confidentiality belongs to the orthogonal STARTTLS / MTA-STS / TLS-RPT transport-layer stack. Myth #3 "I have SPF and DKIM so I do not need DMARC" is refuted by pointing out that DKIM signature validation (whose math this page documents) gives an Authentication- Results dkim=pass stamp on the d= signing-domain — but without DMARC alignment, the visible From: header domain (which controls user- facing trust) is completely unconstrained and can be forged by an attacker who has a DKIM-signed mail from ANY domain they control. Myth #15 "DMARC failures always mean an attacker" is refuted by pointing out that legitimate cryptographic-signature-related failures (the operator-side rotation midpoint where the previously-signed mail in the receiver-side spam-filter queue verifies against a selector whose published key has rotated, the operator-side canonicalization-mismatch where the signing-side computed body-hash differs from the verifier-side computed body- hash due to a transit-time content transformation, the operator-side key-format-error where a copy-paste truncation of the 2048-bit base64-encoded public-key produces a DKIM permerror at the verifier) account for a quantifiable long-tail of dkim=fail RUA rows that have nothing to do with an attacker. Read the myths-and-misconceptions catalogue alongside this cryptographic- foundation reference when an operator encounters one of the cited myths — the refutation arguments map directly onto the cryptographic mechanics THIS page documents. Closes the DKIM-cluster ↔ DMARC-pillar myth-refutation bridge whereby the cryptographic foundations this page documents are the STRUCTURAL PRECONDITION for the operator-facing myth-refutation catalogue the myths spoke maintains.
• Email authentication ecosystem — the cluster-intro pillar covering all three pillars (SPF, DKIM, DMARC) plus their relationships to BIMI, ARC, MTA-STS, and TLS-RPT.
• Email authentication glossary — definitions of the vocabulary on this page: private key, public key, RSA, Ed25519, SHA-256, signature, body hash, signed headers, selector, canonicalization.
• DKIM failures explained — the CRYPTOGRAPHIC-FOUNDATION-FAILURE-CLASS companion to this cryptography reference — the CRYPTOGRAPHIC-FOUNDATION-FAILURE- CLASS companion documenting how the cryptographic primitive choices THIS page documents (RSA vs Ed25519, key size 1024 vs 2048 vs 4096, SHA-256 body-hash, simple vs relaxed body-canonicalization, header- canonicalization) DIRECTLY DETERMINE the spectrum of DKIM verification failure modes observable at the receiver. Where THIS page documents the cryptographic FOUNDATION in protocol-precise terms (RFC 6376 §3.3.1 the rsa-sha256 algorithm reference, RFC 8463 §3 the ed25519-sha256 algorithm reference, RFC 8301 the §3.1 weak-key DEPRECATED guidance that receivers SHOULD treat keys under 1024 bits as permerror, the relaxed-vs-simple canonicalization modes that normalise body whitespace before the body-hash is computed), the failures spoke catalogues the receiver-side Authentication-Results stamp signature each cryptographic-foundation choice produces: dkim=permerror weak-key (RSA-1024 deprecated key receivers reject per RFC 8301), dkim=permerror unknown-algorithm (signer is using Ed25519 against a verifier that doesn't support RFC 8463), dkim=fail body-hash-mismatch (relaxed-vs-simple canonicalization decision mismatch where the signer used c=relaxed/simple but a mail-relay-intermediary reformatted whitespace in a way that breaks simple body canonicalization), and dkim=fail signature-verify (the public-key bytes published in the selector's p= tag don't cryptographically verify the b= signature with the chosen algorithm). Read THIS cryptography-basics page WITH the failures reference when evaluating an algorithm-upgrade roadmap or a key-size migration — the failures spoke names the diagnostic Authentication-Results signatures whose appearance in production RUA aggregate reports indicates which receiver populations have not yet adopted which cryptographic-foundation choices.
• BIMI SVG-Tiny-PS image authoring requirements — the CRYPTOGRAPHIC-MATERIAL-EMBEDDED-IN- VMC-CERTIFICATE-CHAIN-COMPANION reference. Where THIS page documents the DKIM cryptographic primitives operating BELOW the message-signing layer (RSA-2048 / RSA- 4096 / Ed25519 signing keys, SHA-256 body- hash digests, c14n canonicalization byte- normalisation, the publisher-private-key isolation discipline this page catalogues), the BIMI-SVG-Tiny-PS-image-authoring spoke documents the PARALLEL CRYPTOGRAPHIC- MATERIAL-AUTHORING-AND-EMBEDDING discipline the publisher follows to bind a verified- trademark SVG-Tiny-PS image into the X.509 VMC (Verified Mark Certificate) chain via the IETF RFC 3709 logotype extension (OID 1.3.6.1.5.5.7.1.12) the CA/Browser- Forum BR §3.2.2.8 prescribes. The byte- syntax authoring constraints the BIMI- SVG-Tiny-PS spoke documents (W3C SVG-Tiny- 1.2 profile compliance, the BIMI Working Group's authoring-rules-draft constraints on viewBox / preserveAspectRatio / fillRule / stroke / fill attributes, the UTF-8 byte-encoding requirement, the gzip-eligibility / 32-KB-after-base64 upper-bound) are STRUCTURALLY-PARALLEL to the byte-level DNS-TXT-record authoring constraints this DKIM-cryptography-basics page documents (RFC 1035 §3.3.14 255-byte character-string limit forcing 2048-bit RSA keys to be split across multiple strings, the RFC 6376 §3.6.1 base64-no- whitespace public-key authoring rule, the RFC 8463 §3.1 raw-Ed25519-key publishing format). Read THIS DKIM-cryptography- basics page WITH the BIMI-SVG-Tiny-PS- image-authoring spoke when designing a publisher-side cryptographic-material deployment discipline that spans BOTH the DKIM signing-key publishing surface AND the BIMI VMC image-embedding surface; each is a distinct cryptographic-material- publishing channel with its own strict- byte-syntax authoring rules whose silent violation defeats end-to-end verification at receiver-side.
• BIMI Verified Mark Certificates (VMC and CMC) — the DKIM-PUBLIC-KEY-PUBLICATION- PRIMITIVE-VS-X509-VMC-TRADEMARK- BINDING-CERTIFICATE-PUBLICATION- PRIMITIVE-AS-PARALLEL-CRYPTOGRAPHIC- MATERIAL-PUBLISHING-CHANNELS companion to this DKIM cryptography reference. Where THIS page documents the cryptographic primitives the DKIM publisher operates the public-key-publication channel with (RSA-1024 / RSA-2048 / RSA-4096 / Ed25519 algorithm + key-length choice, SHA-256 hash function, public-exponent e=65537 convention, the DNS TXT-record at <selector>._domainkey.<domain> publication topology), the BIMI-VMC/CMC spoke documents the PARALLEL cryptographic-material- publication channel the publisher operates ALONGSIDE the DKIM channel to bind a verified-trademark SVG-Tiny-PS image into an X.509 end-entity certificate. Concretely, the spoke documents FOUR cryptographic-material-publication- channel-parallel dimensions: (i) per-publication-channel cryptographic primitive choice — DKIM uses publisher-generated asymmetric key-pairs with publisher- direct DNS TXT-record publication AND publisher-direct private-key custody (the cryptographic-key- custody discipline THIS page documents), while BIMI VMC/CMC uses publisher-generated asymmetric key-pairs (RSA-2048 minimum, ECDSA-P256 supported per BIMI WG BR §6.1.5) PRESENTED to a BIMI-WG-approved Certificate Authority (DigiCert, Entrust) for trademark-binding attestation + X.509 certificate chain issuance, with HTTPS-PUBLICATION at the BIMI-record-referenced a=-tag URL the receiver-side fetches — STRUCTURALLY DIFFERENT publication topology even though the underlying public-key cryptographic primitive family is shared; (ii) per- publication-channel trust-anchor rooting — DKIM trust-rooting is at the publisher's own DNS zone (DNSSEC-optional and the only publisher-attestation primitive is the publisher's authority over the DKIM TXT-record at <selector>._domainkey), while BIMI VMC/CMC trust-rooting is at the BIMI-WG-approved CA's publisher-vetted-attestation chain anchored in the receiver-side BIMI-WG-published CA-allow-list — a fundamentally different trust topology that the BIMI VMC chain EXTENDS beyond the publisher's DNS-authority to a trademark- verification authority class DKIM's pure self-attestation topology STRUCTURALLY CANNOT provide; (iii) per- publication-channel cryptographic- material-lifecycle discipline — DKIM key rotation is publisher- scheduled with publisher-controlled dual-selector publication topology (the per-key-rotation-event discipline THIS page covers at the algorithm-strength upgrade boundary), while BIMI VMC/CMC certificate lifecycle is CA-issuance-cadence- bound (typically 13-month BIMI BR validity period) requiring annual trademark-re-verification + certificate-re-issuance procedure — a STRUCTURALLY DISTINCT cryptographic-material-rotation cadence the publisher coordinates ALONGSIDE the DKIM key rotation cadence; and (iv) per- publication-channel cryptographic- primitive consumed by receiver-side verification stack — DKIM verification consumes the publisher-published public key for per-message DKIM-Signature verification (the receiver-side cryptographic-primitive-consumption path THIS page documents at the receiver-side acceptance boundary), while BIMI VMC/CMC verification consumes the publisher-published VMC certificate chain for receiver- side rendering-time trademark- attestation verification — a STRUCTURALLY DISTINCT receiver-side cryptographic-primitive-consumption path that operates at the receiver-side inbox-rendering layer AFTER the DKIM-cryptographic- primitive-driven DMARC verdict has produced a p=quarantine / p=reject enforcement record. Read the BIMI-VMC/CMC spoke alongside THIS DKIM cryptography reference when the publisher is SCALING the cryptographic-material- publishing discipline from DKIM-only (per-message-signature primitive) to DKIM + BIMI (per-message- signature + per-tenant-trademark- attestation primitives) — the spoke documents the structurally- analogous-but-distinct cryptographic- material-publication channel the publisher operates ALONGSIDE the DKIM channel, with shared-foundation public-key cryptographic-primitive FAMILIES but STRUCTURALLY DIFFERENT publication topology, trust-anchor rooting, lifecycle cadence, and receiver-side verification-stack consumption path.
• DANE for SMTP — the DNSSEC-ANCHORED-PER-MX-TLSA- RECORD-AS-TRANSPORT-LAYER-CRYPTOGRAPHIC- ANCHOR-PUBLICATION-PARALLEL-TO-DKIM- MESSAGE-LAYER-PER-SELECTOR-CRYPTOGRAPHIC- ANCHOR-PUBLICATION companion documenting how the publisher-side per-MX-host RFC 7672 TLSA-RR DNSSEC-anchored TLS- certificate-binding publication discipline this DANE spoke documents is the structurally-analogous transport- layer companion to the per-selector DNS-published cryptographic-public-key binding THIS DKIM cryptography basics page documents at the message layer. Where THIS page documents the DKIM- cryptography foundations (per-message RSA-vs-Ed25519 keypair generation, per- selector p=-tag public-key publication in <selector>._domainkey.<d> TXT-RR, per-message b= signature-bytes vs bh= body-hash binding, per-publisher key- algorithm-strength choice per RFC 8301 deprecation of SHA-1 and 1024-bit RSA), the DANE-for-SMTP spoke is the structurally-analogous-but-distinct cross-layer cryptographic-anchor- publication reference at four cross- layer per-publisher cryptographic-anchor- publication coupling dimensions: (i) per-publisher DNS-RR publication primitive as STRUCTURALLY-IDENTICAL cryptographic-anchor publication surface across both protocols — DKIM publishes per-selector <selector>._domainkey.<d> TXT-RR carrying the public-key binding (the v=DKIM1; k=rsa; p=<b64-pubkey> body); DANE publishes per-MX-host _25._tcp.<mx-host> TLSA-RR carrying the per-cert cryptographic anchor (the <usage> <selector> <match-type> <cert-data> 4-tuple); both protocols use the same per-publisher DNS-publication primitive as the load-bearing per- publisher cryptographic-attestation publication surface; (ii) per- publisher trust-anchor model — self- publisher-rooted DNS for DKIM vs DNSSEC-anchored DNS for DANE — as load-bearing cryptographic-anchor- rooting choice — DKIM's per- selector public-key publication operates WITHOUT requiring DNSSEC on the publishing zone (receivers fetch the TXT-RR and verify per-message signatures against it directly); DANE- for-SMTP STRUCTURALLY REQUIRES DNSSEC validation of the per-MX TLSA-RR per RFC 7672 §1.3.4 (any non-DNSSEC- validated TLSA-RR is treated as absent), making DANE a more demanding cryptographic-anchor-publication discipline than DKIM in terms of zone-publication infrastructure prerequisites the publisher must establish; (iii) per-publisher cryptographic-anchor lifecycle — per-selector DKIM rotation vs per- MX-host TLSA-cert rotation — as parallel cadence-coordination disciplines — DKIM publishers rotate selectors (publish new selector TXT-RR → wait propagation window → switch signing identity → retire old selector after replay- window cap); DANE publishers rotate per-MX TLS certificates (publish new TLSA-RR for incoming cert → wait DNSSEC-anchored propagation → deploy new cert at the receiving MX → retire old TLSA-RR); the same per-publisher publish-then-verify- cycle discipline applies to both, bridging the per-selector DKIM rotation cadence THIS page documents the cryptography foundation of to the per-MX-host DANE TLSA rotation cadence the DANE-explained spoke documents; (iv) per-publisher cross-layer publication stack — message-layer DKIM + transport-layer DANE — as per- publisher complete cryptographic- envelope discipline — every per-publisher per-domain DNS-published cryptographic-anchor publication catalogue (DKIM at message-layer + DANE at transport-layer + MTA-STS at HTTPS-CA-anchored transport-layer + BIMI VMC at display-layer + DNSSEC zone-signing at zone-publication- layer) composes into a per-publisher complete cryptographic-envelope publication discipline; the DANE- explained spoke is the canonical per-publisher transport-layer-DNSSEC- anchored-cryptographic-publication reference DKIM publishers consume alongside this cryptography- foundations page when scoping the per-publisher per-domain cross-layer cryptographic-publication discipline the message-layer DKIM cryptographic- attestation this page documents is one layer of, alongside the transport-layer DANE TLS-anchored cryptographic-publication the DANE spoke documents.
• DNS propagation explained — the DKIM-PUBLIC-KEY-DNS-PUBLICATION- PROPAGATION-WINDOW-AS-LOAD-BEARING- UPSTREAM-GATE-OF-DKIM-CRYPTOGRAPHIC- PRIMITIVE-OBSERVABILITY-AT-RECEIVER-AT- FOUR-PER-CRYPTOGRAPHIC-PRIMITIVE- PROPAGATION-COUPLING-DIMENSIONS companion to this DKIM-cryptography-basics reference. Where THIS page documents the per- publisher per-selector DKIM cryptographic- primitive foundation (RSA-2048 per RFC 8301 + Ed25519 per RFC 8463 keypair generation + per-publisher per-selector SHA-256 hash-function selection per RFC 6376 §3.5 a=-tag + simple-vs- relaxed body-canonicalization per RFC 6376 §3.4 c=-tag + per- publisher per-selector private-key- custody discipline), the DNS-propagation spoke is the canonical propagation-window discipline reference whose per-resolver per-zone-version cache-aging behaviour determines WHEN each per-publisher per- selector DKIM cryptographic-primitive publication becomes globally observable at the receiver's recursive-resolver cache tier — at four per-cryptographic- primitive propagation coupling dimensions: (i) per-publisher per-selector public-key DNS-publication propagation window gate — the per-publisher per-selector <selector>._domainkey. <d-domain> TXT-RR publishing the RSA-2048 / Ed25519 public-key material via the p=<base64-public-key> tag is subject to the recursive-resolver- cache TTL aging behaviour THIS spoke documents; until the per-receiver-cohort recursive-resolver cache has aged the prior-key-version cache-entry and refetched the new key-version from the authoritative server, the per-publisher per-selector public-key publication is NOT YET observable at the receiver-side DKIM-verification boundary; (ii) per-publisher per-selector cryptographic-algorithm rotation (RSA-2048 → Ed25519) propagation window gate — per-publisher per- selector cryptographic-strength upgrade (RSA-1024 → RSA-2048 per RFC 8301 Section 2 or RSA-2048 → Ed25519 per RFC 8463 dual-selector co-publication) is gated by the per-resolver per-zone cache-aging propagation-window THIS spoke quantifies — the per-publisher per-rotation algorithm-upgrade discipline ladder bottoms out on the DNS- propagation-window-discipline reference for the per-receiver-cohort observability gate; (iii) per-publisher per- selector hash-algorithm-tag (h=sha256 / k=rsa / k=ed25519) DNS-publication propagation window gate — when a per-publisher per-selector key- publication updates the h=-tag (SHA-1 → SHA-256 per RFC 8301 §3.3 deprecation) or k=-tag (rsa → ed25519 per RFC 8463 §3) cryptographic-algorithm announcement, the per-resolver per-zone cache-aging behaviour the DNS- propagation spoke documents determines when the receiver-side DKIM-verification algorithm observes the updated cryptographic-algorithm-selection at the per-publisher per-selector key- publication boundary; (iv) per- publisher per-selector key-retirement (p=-empty / NULL-public-key publication) propagation window gate — the per-publisher per- selector key-retirement publication (publishing v=DKIM1; p=; with an empty p=-tag per RFC 6376 §3.6.1 as the canonical key-revocation publication-discipline pattern) is subject to the per-resolver per-zone cache-aging propagation-window THIS spoke documents — meaning per-publisher per-selector key-retirement is NOT uniformly observable at receivers until the per-receiver-cohort recursive- resolver cache has aged the prior-key- version cache-entry. Read the DNS- propagation spoke ALONGSIDE this DKIM- cryptography-basics reference whenever a per-publisher per-selector cryptographic-primitive publication timing question emerges — THIS page gives the per-publisher per-selector DKIM cryptographic-primitive foundation, the DNS-propagation spoke gives the upstream propagation-window discipline reference the per-publisher per- selector cryptographic-primitive observability ladder bottoms out on at the per-receiver-cohort recursive- resolver cache-aging boundary.
• Domain Security Checker — live DNS lookups for SPF, DKIM, DMARC. Verifies the current DKIM public key under any selector, reports the key algorithm (rsa/ed25519), key size, and DNS TTL.
• Email Header Analyzer — paste a received message and inspect the DKIM-Signature header details: algorithm (a= tag), canonicalization (c= tag), signed-headers list (h= tag), body hash (bh= tag), signature (b= tag).
• BIMI explained — the PER-PUBLISHER-PER-DOMAIN-BIMI-LOGO- RENDERING-DISCIPLINE-AS-LOAD-BEARING- DOWNSTREAM-CONSUMER-OF-PER-MESSAGE-DKIM- CRYPTOGRAPHIC-VERIFICATION-INTEGRITY companion to this per-message DKIM cryptographic-fundamentals reference. Where THIS page documents the per-publisher per- domain DKIM cryptographic-fundamentals discipline (the RSA-1024 vs RSA-2048 vs Ed25519 key-strength choice, the SHA-256 body-hash computation, the per-message canonicalization-and-signature-verification algorithm), the BIMI spoke documents the FOUR PER-PUBLISHER-PER-DOMAIN-BIMI-LOGO- RENDERING-DIMENSIONS structurally gated on THIS page's per-message DKIM cryptographic- verification floor: (i) per-publisher per-receiver per-message BIMI-rendering ELIGIBILITY GATED on per-message DKIM- aligned-cryptographic-pass — the receiver-side BIMI-rendering decision requires a per-message DKIM-aligned-pass verdict that THIS page's cryptographic- verification algorithm directly produces; a per-message DKIM-cryptographic-verification FAILURE (signature-b-tag mismatch, body- hash bh-tag mismatch, public-key p-tag retrieval failure) defeats BIMI-rendering eligibility regardless of every other BIMI-precondition surface; (ii) per-publisher per-domain BIMI-VMC certificate publication discipline ANCHORED on per-domain DKIM-key-strength CHOICE — the per-publisher per-domain BIMI VMC (Verified Mark Certificate) chains its per-publisher mark-binding cryptographic attestation through a per-domain l=-tag-published BIMI record whose per-receiver per-message verification is co-gated on the per-domain DKIM key- strength choice THIS page documents — a per-domain RSA-1024 DKIM publication weakens the joint per-message BIMI-VMC-verification + DKIM-aligned-pass cryptographic-attestation stack against per-publisher long-term forgery risk; (iii) per-publisher per-domain BIMI-rendering CONTINUITY across per-selector DKIM-KEY-ROTATION overlap windows — the per-publisher per- domain BIMI-rendering continuity discipline requires the per-selector DKIM-key-rotation cadence THIS page describes to sustain a per-receiver per-day DKIM-aligned-pass-rate floor across the rotation overlap window, because per-receiver per-day DKIM-aligned- pass-rate dips during rotation overlap windows defeat per-publisher per-day per- receiver BIMI-rendering eligibility; (iv) per-publisher per-domain BIMI VMC CERTIFICATE-CHAIN cryptographic-verification cadence COORDINATION with per-selector DKIM-key-rotation cadence — the per-publisher per-domain BIMI VMC certificate- chain renewal cadence (typically annual, per-CA-issuance) MUST be coordinated with the per-selector DKIM-key-rotation cadence THIS page documents so the joint per-receiver per-message BIMI-VMC-verification + DKIM- aligned-pass cryptographic-evidence stream remains coherent across the per-publisher per-domain authentication-and-attestation publication portfolio. Read the BIMI spoke ALONGSIDE this DKIM cryptographic- fundamentals reference whenever the per- publisher per-domain operator EVALUATES the per-domain BIMI-logo-rendering publication investment as a downstream consumer of the per-message DKIM- cryptographic-verification floor THIS page's algorithm directly produces.
• Email deliverability
• RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures — the canonical DKIM specification. Section 3 defines the signing and verification operations; section 5 defines canonicalization; section 6 defines the DNS TXT record format.
• RFC 8301 — Cryptographic Algorithm and Key Usage Update to DKIM — the 2018 update that prohibits SHA-1, requires SHA-256, and sets the 1024-bit floor / 2048-bit recommendation for RSA signing keys.
• RFC 8463 — A New Cryptographic Signature Method for DKIM (Ed25519) — adds Ed25519 as an alternative DKIM signing algorithm. Section 5 documents the dual-algorithm deployment pattern.
• RFC 1035 — Domain Names (Implementation and Specification) — section 3.3.14 defines the TXT record format and the 255-byte character-string limit that forces 2048-bit RSA keys to be split across multiple strings.
• DKIM alignment with DMARC — the DKIM-CRYPTOGRAPHIC-SIGNING-IDENTITY- AS-LOAD-BEARING-INPUT-TO-DMARC-ALIGNMENT- VERDICT companion to this DKIM cryptography- basics reference. Where THIS page documents the RSA/Ed25519 key-pair generation, the body-hash / header-hash signing operation, the selector publication discipline, and the 2048-bit-key TXT-RR split-string encoding, the DKIM-alignment-with-DMARC spoke documents the d= signing-domain identifier emitted by the cryptographic signing operation as the load-bearing input to the DMARC alignment verdict at receivers. Concretely, the spoke documents FOUR per-cryptographic-output-to-DMARC- alignment-coupling dimensions: (i) the d= signing-domain tag emitted by the signer as the DMARC-alignment-candidate identifier dimension — the spoke documents how every signature produced by the cryptographic primitives this page catalogues carries a d= tag identifying the signing organisation domain, and how the receiver-side DMARC evaluator compares this d= identifier against the RFC 5322 From: header domain to compute the dkim-alignment verdict; (ii) the relaxed-vs-strict adkim= alignment- mode publication discipline as the organisational-domain-vs-exact-match decision dimension — the spoke documents how the publisher-side adkim= tag (relaxed by default, strict optional) determines whether the d= identifier produced by the signer must MATCH the From: header domain EXACTLY (strict) or share the same organisational domain (relaxed) — a decision the cryptographic signer-side selector-and-key publication this page documents must coordinate with; (iii) the per-selector- per-d= signing-identity hierarchy as the multi-tenant-author-domain DMARC- alignment dimension — the spoke documents how the per-selector public- key publication discipline this page catalogues maps onto a per-d= signing- identity hierarchy where each tenant / sending sub-organisation publishes its own selector AND its own d= signing- domain, the receiver-side DMARC alignment evaluator consuming each signature's d= tag as an independent alignment-candidate; and (iv) the body-hash bh= integrity tag as the post-signing content-integrity precondition to dkim=pass DMARC-input dimension — the spoke documents how the body-hash integrity primitive this page architectures (the bh= tag emitted by the signer, recomputed by the verifier) is the LOAD-BEARING precondition to the dkim=pass result the DMARC evaluator consumes — bh= mismatch produces dkim=fail and removes the signature from the DMARC alignment candidate set even when the d=/From: domain alignment would otherwise pass. Read the DKIM-alignment-with-DMARC spoke alongside this cryptographic- basics reference when the cryptographic outputs documented here (d= identifier, bh= integrity tag, per-selector public- key publication) need to be sequenced into the receiver-side DMARC-alignment verdict the brand-protection programme depends on.
• CAA records explained — the PER-DOMAIN-CA-ISSUANCE- RESTRICTION-DNS-RR-PUBLICATION- DISCIPLINE companion to this DKIM cryptography deep dive. Where THIS page documents the cryptographic primitives underlying DKIM (RSA / ed25519 key pair generation, public-key / private-key partition, SHA-256 hash function, the BASE64-encoded public-key wire format, recommended key strengths, replay-resistance properties) published in per-selector selector._domainkey.<domain> TXT-RRs at the message-layer cryptographic-anchor publication surface, the CAA-records-explained spoke is the STRUCTURALLY-PARALLEL per-domain PKI-issuance-restriction publication-discipline reference whose RFC 8659 CAA-RR primitive publishes per-publisher per-domain CA-issuance authorisation restrictions at a STRUCTURALLY-DISTINCT cryptographic layer (per-cert PKI- issuance layer rather than per- message DKIM message-layer). The CAA-vs-DKIM cross-layer publication- discipline coupling establishes four specific publisher-side DNS-rooted trust-anchor publication parallels: (i) per-publisher per-domain DNS-RR publication primitive parallel — both DKIM at <selector>._domainkey.<domain> TXT-RR and CAA at <domain> CAA-RR publish per-publisher trust/ authorisation restrictions via the same DNS-RR publication primitive the publisher's per-domain DNS zone already operates; (ii) per- publisher cryptographic-trust-anchor topology parallel — DKIM publishes per-selector public-key- as-cryptographic-anchor for receiver- side per-message signature verification, whereas CAA publishes per-domain CA- issuance-restriction-as-PKI-trust-anchor for CA-side per-cert-issuance authorisation evaluation; both are publisher-controlled DNS-rooted trust-anchors at structurally-distinct cryptographic layers (per-message DKIM message-layer vs per-cert PKI-issuance layer); (iii) per-publisher rotation / lifecycle cadence parallel — DKIM per-selector rotation (RFC 6376 §3.6.1 p=-empty revocation convention, dual-selector zero- downtime rotation procedure) parallels CAA per-CA-list publication-lifecycle (per-CA add/remove via per-publisher issue / issuewild tag-list publication, per-CA-migration sequencing requirement); both publication-disciplines impose per- publisher operational cadence that must be coordinated with downstream consumer caches and validation windows; (iv) per-publisher cross-layer publication-discipline stack composition — DKIM message-layer cryptographic-anchor publication + CAA per-domain PKI- issuance-restriction publication + transport-layer DANE per-MX-host TLSA-RR cryptographic-anchor publication + transport-layer MTA-STS HTTPS-policy publication compose into the publisher's complete per-domain cryptographic-anchor and PKI-trust- anchor publication-discipline stack the receiver evaluates at every message-layer + transport-layer + PKI-issuance-layer boundary. Read the CAA spoke alongside this DKIM- cryptography reference when the per-publisher per-domain DNS-RR publication-discipline documented here at the message-layer per- selector public-key surface needs to be composed with the per-publisher per-domain PKI-issuance-restriction publication-discipline at the PKI- issuance layer to constitute the complete per-publisher cross-layer cryptographic-anchor and PKI-trust- anchor publication-discipline stack.
• DKIM for Google Workspace — the GOOGLE-WORKSPACE-TENANT-DKIM-AT- google-DOMAINKEY-DIRECT-TXT-RR-PUBLICATION- CONSUMER-OF-RSA-2048-VS-ED25519-KEYPAIR-AND- SHA-256-HASH-AND-CANONICALIZATION- CRYPTOGRAPHIC-FOUNDATION companion to this DKIM cryptography deep dive. Where THIS page documents the publisher-side cryptographic primitives underlying DKIM (RSA / ed25519 key pair generation, public- key / private-key partition, SHA-256 hash function, the BASE64-encoded public-key wire format, recommended key strengths, replay-resistance properties), the dkim- for-google-workspace spoke is the WORKSPACE-TENANT-CANONICAL-PUBLICATION reference documenting the FOUR Google- Workspace-tenant-specific DKIM-publication- vs-cryptographic-foundation-input coupling dimensions every Workspace-tenant DKIM deployment depends on: (i) google._domainkey.<d> direct TXT-RR primitive publication discipline — Workspace publishes DKIM keys DIRECTLY at the publisher's own per-domain DNS zone as a TXT record at google._domainkey.<d> (structurally distinct from M365's per-tenant CNAME-pointer primitive at selector1/selector2), and the per-message DKIM-Signature d=-tag materialises as the per-tenant primary domain at the Gmail outbound DKIM-signer at signing time — the cryptographic primitives THIS page documents (RSA-2048 public key Base64-encoded in the p= tag, SHA-256 hash via h=sha256 default, simple-vs- relaxed canonicalization choice) materialise verbatim in the publisher's own DNS zone TXT-RR rather than at the Microsoft-managed onmicrosoft.com hostname M365's CNAME chain dereferences to; (ii) Workspace Admin Console 1024-bit- default RSA emission vs operator-side 2048-bit upgrade discipline — the Workspace Admin Console's "Generate new record" workflow still emits a 1024-bit RSA keypair by default (deprecated per RFC 8301 §3, which THIS page documents as the canonical reason 1024-bit MUST NOT be deployed); the operator MUST explicitly select the 2048-bit option before the modern receiver-side DKIM-verifier-and- DMARC-aligner produces meaningful per- message DKIM-aligned-pass verdicts that the cryptographic-strength discipline THIS page documents requires; (iii) Workspace per-publisher per-domain SHA-256 hash-algorithm publication consistency — the Gmail outbound DKIM-signer publishes h=sha256 consistently across every per-customer per-domain signing path (no SHA-1 emission fallback per RFC 8301 §2.2 deprecation), and the cryptographic-hash discipline THIS page documents (collision-resistance of SHA-256 vs SHA-1 deprecation) is the upstream cryptographic-foundation input Workspace's per-message signing-pipeline consumes; (iv) Workspace per- publisher per-selector private-key custody-and-rotation discipline via the Admin Console "Generate new record" workflow — the Workspace operator manages the per-domain DKIM private-key custody entirely within the Google- managed Admin Console (the operator never directly handles the private-key bytes, which Google retains in the signing infrastructure), and the per-selector rotation cadence (selector-namespace change from google to google2 / google3 etc.) maps to the dual-selector zero- downtime rotation discipline THIS page documents as the canonical per-publisher per-selector key-rotation primitive. Read the dkim-for-google-workspace spoke as the Workspace-tenant-specific cryptographic- foundation-publication reference whenever the protected domain is hosted on the Google Workspace cloud tenant and the cryptographic-foundation primitives THIS page documents need a Workspace-tenant- publication-vs-cryptographic-foundation- input baseline.
• Why SPF alone is insufficient — the DKIM-PUBLISHER-SIDE-CRYPTOGRAPHIC- FOUNDATION-AS-LOAD-BEARING-MESSAGE-LAYER- AUTHENTICATION-COMPLEMENT-TO-SPF-IP- AUTHORIZATION-LIST-PUBLICATION-DISCIPLINE companion to this DKIM cryptography deep dive. Where THIS page documents the per- publisher per-selector cryptographic primitives underlying DKIM (RSA / ed25519 key pair generation, public-key / private- key partition, SHA-256 hash function, the BASE64-encoded public-key wire format, simple-vs-relaxed canonicalization choice, private-key custody-and-rotation discipline), the why-spf-alone-is-insufficient spoke is the SPF-PROTOCOL-LEVEL-INSUFFICIENCY- TAXONOMY canonical reference documenting how SPF's structurally inadequate per- publisher per-domain IP-authorization-list publication primitive collapses at multiple per-receiver per-message verdict boundaries that the cryptographic-foundation primitives THIS page documents structurally remedy at four cross-mechanism message-layer- authentication-complement coupling dimensions: (i) Per-forwarder-hop cryptographic-signature survival vs SPF per-forwarder-hop IP-authorization-list invalidation — the canonical forwarder-relay (mailing-list mediator, corporate gateway, vacation-autoresponder, ESP-relay) rewrites the SMTP envelope MAIL FROM source-IP to its OWN sending IP, which defeats the SPF authorization-check at the receiver-side (the receiver's SPF-evaluator sees an IP NOT in the per-publisher SPF- record's ip4: / include: / a: / mx: mechanism list); the DKIM cryptographic- signature this page documents survives the per-forwarder-hop boundary BECAUSE the signature is per-message-content cryptographic (the RSA-PKCS#1-v1_5 OR Ed25519 signature over the canonicalized message body + signed- headers-list per RFC 6376 §3.5) NOT per- sender-IP authorization; the per-publisher DKIM-publication discipline this page documents is the load-bearing message-layer- authentication-survival primitive that defeats SPF's per-forwarder-hop structural insufficiency; (ii) RFC 8301-and- RFC 8463 cryptographic-strength-publication discipline vs SPF's no-cryptographic- primitive publication — the per- publisher per-selector RSA-2048 vs Ed25519 keypair choice + SHA-256 hash-algorithm choice + simple-vs-relaxed canonicalization choice this page documents at the publisher- side cryptographic-foundation publication boundary provides per-publisher per-message cryptographic-integrity guarantees that SPF's IP-authorization-list publication primitive structurally CANNOT provide (SPF has no per-message cryptographic primitive — it's purely a per-publisher per-domain IP-authorization decision evaluated at the receiver-side at per-message receive time against the envelope MAIL FROM source-IP); (iii) Per-publisher per-selector cryptographic-anchor-publication discipline as load-bearing per-publisher DMARC-aligned- pass-via-DKIM-only-path — when the per-message SPF-aligned-pass path is defeated (per-forwarder-hop IP-rewrite, SPF-PermError lookup-limit overflow, SPF- TempError per-receiver DNS-resolution failure), the DMARC-disjunction at RFC 7489 §6.6 FALLS BACK to the per-message DKIM- aligned-pass path — which structurally REQUIRES the per-publisher per-selector DKIM publication discipline THIS page documents at the cryptographic-foundation publication boundary; without the cryptographic-foundation primitives THIS page documents, SPF's per-forwarder per- receiver per-message structural insufficiency propagates upward to per-publisher per- message DMARC-fail; (iv) Per- publisher per-tenant complete-message-layer- authentication-publication-discipline-stack composition as SPF-insufficiency-remedy completeness — the per-publisher per-tenant complete message-layer- authentication-publication-discipline-stack composes per-publisher per-domain SPF publication + per-publisher per-selector DKIM-cryptographic-foundation publication (THIS page) + per-publisher per-domain DMARC-disjunction-evaluation-publication + per-forwarder-class per-hop ARC-Message- Signature publication — without the DKIM- cryptographic-foundation primitives THIS page documents, the per-publisher SPF-only publication discipline is structurally insufficient at every per-forwarder-hop and per-receiver-DNS-failure boundary. Read the why-spf-alone-is-insufficient spoke ALONGSIDE this DKIM-cryptography-foundation reference whenever the per-publisher per- domain message-layer-authentication- publication-discipline architecture must coordinate per-publisher SPF-insufficiency remediation via per-selector DKIM- cryptographic-foundation publication.
• DMARC deployment checklist — the PHASE-1-PUBLISHER-SIDE-CRYPTOGRAPHIC- FOUNDATION-PUBLICATION-DISCIPLINE-STEP-AS- LOAD-BEARING-CONSUMER-OF-DKIM-RSA-VS- ED25519-KEYPAIR-AND-SHA-256-HASH-AND- CANONICALIZATION-AND-PRIVATE-KEY-CUSTODY- PRIMITIVE companion to this DKIM- cryptography-basics reference. Where THIS page documents the per-publisher per- selector RFC-6376 + RFC-8301 + RFC-8463 publisher-side cryptographic-foundation primitive (RSA-2048-vs-Ed25519 keypair- generation + SHA-256 body-hash-and- signature-hash discipline + simple-vs- relaxed canonicalization algorithm-pair publication-choice + per-publisher per- selector private-key custody-and-rotation discipline), the DMARC-deployment-checklist spoke is the canonical 5-phase deployment- discipline reference whose Phase 1 publisher-side cryptographic-foundation- publication-discipline step structurally consumes THIS page's cryptographic primitives at four DKIM-cryptography-to- deployment-phase coupling dimensions: (i) per-publisher per-selector RSA-2048-or-Ed25519 keypair-generation as load-bearing Phase 1 baseline- publication primitive — the deployment-checklist's Phase 1 per- publisher per-selector public-key TXT- record publication step at <selector>._domainkey.<d> structurally requires the per-publisher per-selector RSA-2048-or-Ed25519 keypair- generation discipline THIS page documents as the upstream cryptographic primitive the per-selector public-key TXT-record publication then exposes; (ii) per- publisher per-message SHA-256 hash discipline as load-bearing Phase 1 cryptographic-strength-baseline primitive — the deployment-checklist's Phase 1 per- publisher per-message DKIM-Signature baseline-publication step structurally requires the per-message SHA-256 body- hash-and-signature-hash discipline THIS page documents per RFC 8301's deprecation of SHA-1 and RSA-1024 as the per-message message-layer-authentication cryptographic-strength-baseline-floor primitive every Phase 1 baseline publication step floors on; (iii) per-publisher per-message simple- vs-relaxed canonicalization algorithm- pair publication-choice as load-bearing Phase 1 per-forwarder-survival-baseline primitive — the deployment- checklist's Phase 1 per-publisher per- message DKIM-Signature canonicalization- choice publication step structurally requires the per-message simple-vs- relaxed canonicalization algorithm-pair publication-choice discipline THIS page documents as the per-forwarder-class per-hop message-survival-determinant primitive every Phase 2 observability- baseline + Phase 3 pct=-ramp + Phase 4 full-quarantine + Phase 5 full-reject enforcement progression then structurally consumes at the per-forwarder per-message DKIM-aligned-pass-survival boundary; (iv) per-publisher per-selector private-key custody-and-rotation discipline as load-bearing Phase 1-5 ongoing- operational-discipline primitive — the deployment-checklist's per-publisher per-selector private-key custody discipline + per-publisher per-rotation key-rotation discipline + per-publisher per-rotation cryptographic-strength-upgrade discipline (per Phase 1 baseline + Phase 4/Phase 5 ongoing-operational-discipline checklist steps) structurally requires the per- publisher per-selector private-key custody-and-rotation discipline THIS page documents as the upstream operational- discipline primitive every Phase 1-5 per-publisher per-selector public-key TXT-record publication-discipline-stack ongoing-discipline composition consumes. Read the DMARC-deployment-checklist spoke ALONGSIDE this DKIM-cryptography- basics reference whenever a per-publisher per-domain DMARC-deployment programme needs the canonical 5-phase deployment- discipline reference whose Phase 1 publisher-side cryptographic-foundation- publication-discipline step structurally consumes THIS page's per-publisher per- selector cryptographic primitives as the load-bearing Phase 1 baseline-publication primitive every per-phase checklist-step prerequisite gates on.
• Business Email Compromise (BEC) — the FINANCIAL-IMPACT THREAT-MODEL downstream consumer of the per-publisher per-selector cryptographic primitives THIS page architectures (RSA-2048-vs- Ed25519 keypair-generation, SHA-256 hash, simple-vs-relaxed canonicalization, private-key custody discipline). Where THIS page documents the per-selector cryptographic foundation that makes DKIM signatures unforgeable, the BEC spoke documents the FBI-IC3-tracked financial-fraud attack class whose exact-domain From-header impersonation stage the private-key-secrecy property of that cryptographic foundation is the load-bearing defence against. Read THIS page when ARCHITECTING the per-publisher per-selector cryptographic publication discipline; read the BEC spoke when JUSTIFYING the private-key custody and rotation discipline against the financial-fraud threat surface it closes.
• TLS-RPT explained — the PER-RECEIVER-PER-SESSION- TRANSPORT-LAYER-ENCRYPTION-FAILURE- TELEMETRY-AS-LOAD-BEARING-PEER-LAYER- CRYPTOGRAPHIC-DEFENCE-COMPLEMENT companion to this DKIM-cryptography- basics foundational reference. Where THIS page documents the per-message application-layer DKIM cryptographic- authenticity foundation (RSA-2048 / Ed25519 key pairs, rsa-sha256 / ed25519- sha256 signing algorithms, per-message body-hash binding, per-publisher per- selector public-key publication discipline), the TLS-RPT-explained spoke is the per-receiver per-session per-MX hop transport-layer-encryption failure-mode telemetry whose RFC 8460 publication discipline complements the per-message application-layer DKIM cryptographic-authenticity foundation at FOUR per-cryptographic-layer- coverage coupling dimensions: (i) per-cryptographic-layer coverage parallelism — application-layer per-message authenticity vs transport-layer per- session confidentiality — per-message DKIM cryptography secures the per-message body-and- header authenticity at the application layer end-to-end, transport-layer TLS secures the per-session per-MX hop plaintext confidentiality between sending and receiving MTAs, and the per-publisher per-domain complete cryptographic-email-security posture REQUIRES BOTH layers because per- message DKIM authenticity without per- session TLS confidentiality exposes the per-message content to passive per-hop interception, and per-session TLS confidentiality without per- message DKIM authenticity ships encrypted-but-unauthenticated messages the receiver cannot bind to the publishing per-publisher per-selector cryptographic trust anchor; (ii) per-receiver-side cryptographic- failure-telemetry-pillar parallelism — the per-publisher per-domain DKIM-failure verdict aggregation stream surfaces per-message application-layer cryptographic-authentication-failure (signature-verification-failure, key- absence, key-revoked, body-hash- mismatch), the per-publisher per-domain TLS-RPT failure-details aggregation stream surfaces per-receiver per- session per-MX hop transport-layer- encryption-failure (starttls-not- supported, certificate-host-mismatch, certificate-expired, validation- failure), and the per-publisher per- domain operator-side cross-layer cryptographic-failure observability REQUIRES BOTH telemetry streams to distinguish per-message application- layer cryptographic-failure (DKIM leg) from per-session transport-layer cryptographic-failure (TLS leg) at attribution time; (iii) per- publisher per-domain Bulk-Sender- Requirements-2024 cross-layer cryptographic-deliverability-floor composition — the per- publisher per-domain Feb-2024 Gmail/ Yahoo Bulk Sender Requirements deliverability-floor composition REQUIRES BOTH per-message application- layer DKIM cryptographic-signing discipline (rsa-sha256 minimum, 2048-bit RSA or Ed25519 keys, per- selector rotation cadence) AND per- receiver per-session transport-layer TLS-RPT publication discipline as peer-layer cryptographic-defence components of the complete per- publisher per-domain cryptographic- email-security posture; (iv) per-publisher per-domain cryptographic-trust-anchor publication- discipline parallelism — per-message DKIM cryptography anchors at the per-publisher per- selector public-key publication at the <selector>._domainkey.<domain> DNS leaf, transport-layer TLS-RPT anchors at the per-publisher per- domain _smtp._tls.<domain> DNS leaf, and the per-publisher per- domain DNS-publication discipline whose per-record per-leaf publication cadence, monitoring, and rollback operational baseline governs the per- publisher per-domain cryptographic trust-anchor authority for BOTH layers simultaneously. Read THIS page when ARCHITECTING the per- message application-layer DKIM cryptographic publication discipline; read the TLS-RPT-explained spoke when ARCHITECTING the per-session transport-layer encryption-failure telemetry publication discipline that completes the per-publisher per- domain cross-layer cryptographic- email-security posture.
• DMARC forensic reports — the per-publisher per-selector cryptographic-primitive failure forensic- evidence companion to this DKIM- cryptography-basics operator-reference. Where THIS page documents the per- publisher per-selector RSA-2048 key- generation + per-message SHA-256 body- hash and header-hash signature math + per-selector public-key DNS publication + per-selector cryptographic-algorithm choice + per-selector key-rotation overlap-window discipline, the DMARC- forensic-reports spoke is the PER- MESSAGE-FORENSIC-EVIDENCE REFERENCE documenting the RFC 6591 AFRF MIME per- message failure-report envelope whose per-message DKIM-fail attribution payload (the per-message DKIM-Signature header dump revealing a=rsa-sha256-vs- a=ed25519-sha256 algorithm choice, the per-message body-hash bh=-vs-recomputed-body-hash mismatch evidence, the per-receiver verifier-side dkim=fail (bodyhash) vs dkim=fail (signature) failure-reason attribution, the per-selector s=<selector>-vs-DNS- TXT-record p=-tag evidence) the per-publisher per- selector operator MUST examine to distinguish per-message cryptographic- failure attribution between (i) per- selector RSA-1024 weak-key cryptographic regression below the Bulk-Sender- Requirements-2024 floor, (ii) per- selector key-rotation-overlap-window misstep emitting per-day per-receiver signature-validation-failure cliffs, (iii) per-message body-mutation intermediary-attribution emitting per-receiver bodyhash-mismatch evidence, and (iv) genuine per-message DKIM- spoofing cryptographic-attribution. Pair this page (the per-publisher per- selector DKIM-cryptographic-publication reference) with the DMARC-forensic- reports spoke (the per-message RFC 6591 AFRF MIME failure-report payload reference) when designing the per- publisher per-domain per-message DKIM- cryptographic-failure-root-cause forensic-investigation discipline.
• MX records — the per-receiver per-MX-host MAIL- DELIVERY-ROUTING companion to this per- publisher per-selector DKIM cryptographic- publication reference. Where THIS page documents the per-publisher per-selector DKIM cryptographic primitives — RFC 6376 §3.5 RSA / Ed25519 keypair generation, the per-selector public-key publication under <selector>._domainkey.<domain>, the per-message canonicalisation grammar (simple/simple / relaxed/relaxed), the per- message signature-value (b=) and body-hash (bh=) computation, and the per-receiver per-message signature- verification algorithm against the published per-selector public key — the MX-records spoke documents the per- publisher per-domain mail-exchanger-host routing topology that determines WHICH per-receiver-MX host actually executes the per-message DKIM-signature verification at message-receipt. The composition operates through three per- publisher per-domain MX-records-and-DKIM- verifier dependencies the per-receiver per-message DKIM-verdict materially relies on: (i) per-publisher per-domain MX-record-published per-receiver-MX-host priority cascade determines which per- receiver-MX host receives the per- message envelope and therefore which per-receiver-MX-host's DKIM-verifier implementation (per-vendor differences: Exchange Online, Google Workspace, Postfix-OpenDKIM, Sendmail-DKIMSIGN, etc.) executes the per-message b= signature verification — different per- receiver-MX-host vendors handle edge-case body-hash mutation (header folding, CRLF normalisation, MIME-encoding round-trip) asymmetrically, producing per-receiver-MX- host per-message DKIM-verdict divergence; (ii) per-publisher per-domain MX-record null-MX semantics (RFC 7505 0 .) explicitly forbid per- message DKIM-signature delivery to the per-publisher per-domain — a misconfigured null-MX combined with a per-publisher per-selector DKIM-key publication produces a per-publisher per-domain DNS-publication-discipline contradiction that surfaces as per- sender SMTP per-message 5.1.10 bounce regression; (iii) per-publisher per-domain MX-record TTL determines the per-sender per- message MX-host-selection observability window for per-publisher per-domain MX- infrastructure migration, which the per- publisher per-selector DKIM-key publication discipline must respect when per-publisher per-domain MX migration crosses per-receiver-MX-host vendor boundaries with asymmetric DKIM-verifier edge-case handling. Read THIS page when AUTHORING the per-publisher per-selector DKIM cryptographic-publication discipline; read the MX-records spoke when DIAGNOSING per-receiver-MX-host per- message DKIM-verdict divergence at the per-receiver-MX-host DKIM-verifier- boundary tier whose per-vendor-asymmetric edge-case handling the per-publisher per- selector cryptographic-publication discipline must accommodate.
• DMARC policy rollout — the PER-PUBLISHER-PER-DOMAIN-DKIM- CRYPTOGRAPHIC-SIGNING-COVERAGE-FLOOR-AS- LOAD-BEARING-PRE-FLIGHT-CHECKLIST-GATE-FOR- DMARC-POLICY-MODE-RAMP-COMMITMENT companion to this DKIM cryptography fundamentals reference. Where THIS page documents the per-publisher per-selector DKIM cryptographic primitives at the protocol layer (the RSA-2048-vs-Ed25519 keypair generation discipline per RFC 6376 §3.3 + RFC 8301 §3 + RFC 8463 §3, the per-message SHA-256 body-hash + canonicalized-header- hash signature math, the simple-vs-relaxed canonicalization choice per RFC 6376 §3.4, the per-publisher per-selector private-key custody discipline at the HSM-vs-software- keystore-vs-cloud-KMS boundary, the per- stream selector-segmentation discipline, the per-selector key-rotation overlap- window cadence), the DMARC-policy-rollout spoke is the PER-PUBLISHER-PER-DOMAIN- DKIM-CRYPTOGRAPHIC-SIGNING-COVERAGE-AS- PRE-FLIGHT-CHECKLIST-GATE companion documenting the per-publisher per-domain canonical DMARC policy-mode-ramp progression (p=none 30+ days monitoring → p=quarantine pct=10 7-14 days → pct=25 7-14 days → pct=50 7-14 days → pct=100 7-14 days → p=reject pct=100) whose per-phase commitment-readiness gate consumes the per-publisher per-domain DKIM-signing-coverage floor THIS page's cryptographic-primitives ensure. Four DKIM-cryptography-vs-DMARC-rollout coupling dimensions matter at the per- publisher per-domain ramp-readiness boundary: (i) per-publisher per-domain DKIM-signing-universality floor — the per-publisher per-domain DMARC p= none-to-p=quarantine transition gate consumes per-publisher per-domain DKIM-signed-mail-flow universality evidence from the RUA aggregate-XML-report's per-receiver per-source-IP per-day DKIM-aligned-pass rate — the per-publisher per-selector cryptographic-key-strength + signing- coverage discipline THIS page documents IS the load-bearing precondition that coverage floor depends on; (ii) per- publisher per-domain DKIM-key-rotation cadence during ramp — when the per- publisher per-domain is mid-ramp (p=quarantine pct=25-style partial enforcement), per-selector key- rotation must use the per-publisher per- selector overlap-window discipline THIS page documents so per-receiver per- resolver per-DKIM-record TTL-cache coherence is preserved AND the per- publisher per-domain DKIM-aligned-pass rate does not transiently dip below the ramp-gate threshold; (iii) per-publisher per-domain DKIM-signing-coverage gap attacker-bypass — at p=reject pct=100 commitment, ANY per- publisher per-domain mail-flow gap THAT IS NOT DKIM-signed becomes per-receiver- rejected because per-message DMARC- composite-pass requires AT LEAST ONE aligned-pass leg; the per-publisher per- selector cryptographic-publication discipline THIS page documents ensures per-publisher per-domain DKIM signing coverage is universal across EVERY sending stream BEFORE the per-publisher per-domain DMARC policy-rollout commits to strict-mode reject; (iv) per-publisher per-domain DKIM-cryptographic-strength deprecation risk during ramp — the per- publisher per-domain DMARC policy- rollout discipline's per-phase enforcement commitment depends on per-publisher per- selector RSA-2048-or-Ed25519 cryptographic strength remaining above the per-receiver per-message DKIM-verifier accepting floor per RFC 8301 §3; the per-publisher per- selector cryptographic-key-strength discipline THIS page documents IS the load-bearing precondition the per- publisher per-domain DMARC policy- rollout commitment-readiness gate consumes. Read THIS page when AUTHORING the per-publisher per-selector DKIM cryptographic-key-generation + per- message signature-math discipline; read the DMARC-policy-rollout spoke when SEQUENCING the per-publisher per-domain DMARC policy-mode-ramp progression whose per-phase commitment-readiness gate consumes the per-publisher per-domain DKIM-signing-coverage floor THIS page's per-publisher per-selector cryptographic- publication discipline produces.
• SPF forwarding issues
• Email security & privacy glossary — the cross-protocol security-and- privacy threat-and-defense vocabulary registry consumed at four DKIM cryptographic-primitive vs threat- catalogue coupling dimensions.
• DMARC for SaaS senders — the PER-SAAS-TENANT-PER-CUSTOMER- DOMAIN-DKIM-KEY-GENERATION-DEFAULT-AS-LOAD- BEARING-MULTI-TENANT-CRYPTOGRAPHIC-PRIMITIVE- CHOICE companion to this DKIM cryptography basics reference. Where THIS page documents the per-publisher per-selector application- layer DKIM-signing cryptographic-primitive choice (RSA-2048 default per RFC 8301 §3 vs Ed25519 per RFC 8463 vs deprecated RSA-1024, EDNS0 4096-byte TXT-RR payload survival window, per-selector key-rotation cadence), the SaaS-senders spoke is the PER-SAAS- TENANT-PER-CUSTOMER-DOMAIN MULTI-TENANT cryptographic-primitive-default reference the per-customer-domain operator consults when verifying the per-SaaS-tenant-generated signing-key satisfies the per-customer- domain cryptographic-strength floor. Four per-SaaS-tenant cryptographic-coordination dimensions: (i) PER-SAAS-TENANT-DEFAULT- KEY-SIZE-VS-PER-CUSTOMER-DOMAIN-CRYPTOGRAPHIC- FLOOR (per-SaaS-tenant key-pair generation default determines per-customer-domain DKIM cryptographic posture without per-customer- operator visibility — misaligned defaults silently fragment per-publisher per-customer-domain cryptographic-strength compliance); (ii) PER-SAAS-TENANT-PER-CUSTOMER- DOMAIN-CNAME-DELEGATED-KEY-CUSTODY-TRUST- PERIMETER (per-SaaS-tenant HSM/KMS infrastructure custody of per-customer- domain DKIM-signing keys IS the load-bearing trust-perimeter the per-customer operator cannot independently audit — the underlying cryptographic-primitive choice is gated by the SaaS-tenant's default- configuration); (iii) PER-SAAS-TENANT-PER- CUSTOMER-DOMAIN-KEY-ROTATION-CADENCE- UNIFORMITY (per-SaaS-tenant uniform per- customer-domain rotation cadence avoids per-customer-domain key-age dispersion that fragments per-publisher per-customer-domain DKIM-aligned-pass-rate cohort comparability); (iv) PER-SAAS-TENANT-PER-CUSTOMER-DOMAIN- ED25519-VS-RSA-2048-MIGRATION-COORDINATION (per-SaaS-tenant unilateral Ed25519 adoption requires per-customer-domain receiver- compatibility-window measurement — the per-SaaS-tenant cryptographic-primitive upgrade IS structurally coupled to per- customer-domain receiver-population compatibility distribution). Read the SaaS- senders spoke alongside this DKIM cryptography basics guide when AUDITING per-SaaS-tenant per-customer-domain DKIM- signing cryptographic-primitive default against per-customer-domain cryptographic- strength compliance floors, when MIGRATING between SaaS-tenant DKIM-signing providers across cryptographic-primitive defaults, or when PLANNING per-SaaS-tenant per-customer- domain Ed25519 adoption rollouts.
• SPF DNS record syntax explained
• DMARC policy modes
• Phishing protection
• MTA-STS vs DANE — the per-publisher per-domain transport-layer cryptographic-trust-chain protocol-choice decision-matrix companion at four per-publisher per-selector DKIM-cryptography-vs-MTA-STS-vs-DANE coupling dimensions: (i) per-publisher per-selector DKIM RSA-2048 vs Ed25519 application-layer cryptographic-primitive choice per RFC 8301 + RFC 8463 IS structurally parallel cryptographic-primitive-strength-floor publication-decision to per-publisher per-domain MTA-STS Web-PKI RSA-2048/ECDSA-P256 X.509-cert cryptographic-trust-chain choice vs per-publisher per-domain DANE DNSSEC-signed TLSA-RR cryptographic-trust-chain choice — both per-publisher per-domain cryptographic-primitive choices coordinate at the per-publisher per-domain composite cross-layer application-and-transport-layer cryptographic-primitive-strength-floor publication-discipline coordination boundary; (ii) per-publisher per-selector DKIM SHA-256 hash floor + rsa-sha1 deprecation post-SHAttered IS structurally parallel cryptographic-hash-algorithm-floor publication-decision to per-publisher per-domain MTA-STS HTTPS X.509 SHA-256 fingerprint floor vs per-publisher per-domain DANE TLSA-RR DANE-EE(3) + SHA2-256(1) + Full(0) certificate-association-data SHA-256 floor — both per-publisher per-domain cryptographic-hash-algorithm choices coordinate at the per-publisher per-domain composite cross-layer cryptographic-hash-algorithm-floor publication-discipline coordination boundary; (iii) per-publisher per-selector DKIM TXT-RR p=<base64-pubkey> application-layer cryptographic-public-key DNS-publication-discipline IS structurally parallel DNS-published-cryptographic-trust-anchor primitive to per-publisher per-domain DANE TLSA-RR DNSSEC-signed transport-layer cryptographic-trust-anchor publication-discipline — both per-publisher per-domain DNS-published cryptographic-trust-anchor primitives coordinate at the per-publisher per-domain composite DNS-cryptographic-publication-discipline boundary; (iv) per-publisher per-selector DKIM dual-selector overlap-rollover key-rotation cadence IS structurally parallel cryptographic-publication-rotation-cadence operational-discipline to per-publisher per-domain MTA-STS policy-file id: rotation cadence + per-publisher per-domain DANE TLSA-RR rollover cadence — all three per-publisher per-domain cryptographic-rotation cadences coordinate at the per-publisher per-domain composite cross-layer cryptographic-rotation-cadence operational-discipline boundary the DKIM cryptography basics primer THIS page documents the per-publisher per-selector application-layer cryptographic-primitive vocabulary of structurally underpins.
• TLS-RPT TXT-RR record-syntax
• ARC (Authenticated Received Chain) explained — the PER-PUBLISHER-PER-SELECTOR-DKIM- CRYPTOGRAPHIC-PRIMITIVE-RSA-2048-OR-ED25519- DIGITAL-SIGNATURE-PUBLICATION-DISCIPLINE- AS-LOAD-BEARING-CRYPTOGRAPHIC-PRIMITIVE- REUSED-BY-PER-FORWARDER-PER-HOP-ARC-MESSAGE- SIGNATURE-AND-ARC-SEAL-CRYPTOGRAPHIC-CHAIN- OF-CUSTODY-PRESERVATION-DISCIPLINE companion at four per-publisher per-selector DKIM- cryptographic-primitive-vs-ARC-chain-of- custody coupling dimensions: (i) per- publisher per-selector DKIM signing- cryptography primitive (RSA-2048 per RFC 8301 vs Ed25519 per RFC 8463) THIS page documents the per-publisher per-selector byte-grammar publication-discipline of IS the same load-bearing cryptographic- primitive reused by per-forwarder per-hop ARC-Message-Signature + ARC-Seal cryptographic attestation per RFC 8617 §5 — the per-forwarder per-hop ARC-chain cryptographic infrastructure shares the same RSA-2048/ Ed25519 key generation + SHA-256 hashing + base64 public-key publication discipline at a per-forwarder-domain <selector>._domainkey.<forwarder-domain> TXT-RR publication boundary structurally parallel to per-publisher per-selector DKIM publication-discipline THIS page documents; (ii) per-publisher per-selector DKIM cryptographic-primitive-strength floor (RSA-2048 minimum per RFC 8301 sunsetting RSA-1024 / Ed25519 preferred per RFC 8463) IS the load-bearing per-publisher per- selector application-layer cryptographic- integrity floor preserved across forwarder boundaries by per-forwarder per-hop ARC- chain cryptographic-attestation discipline that the ARC explained spoke documents the per-forwarder per-hop sealing protocol of — without per-forwarder per-hop ARC chain-of-custody preservation, per-publisher per-selector DKIM cryptographic-primitive- strength floor THIS page documents the per- publisher per-selector cryptographic-primitive publication-discipline of is structurally invalidated at forwarder body-rewrite boundaries cascading into per-receiver per- message DKIM-aligned-pass-rate floor regression; (iii) per-publisher per-selector DKIM dual-selector overlap-rollover key- rotation cadence IS structurally parallel cryptographic-publication-rotation cadence to per-forwarder per-hop ARC-signing-key rotation cadence the ARC explained spoke documents the per-forwarder per-hop cryptographic-publication-rotation discipline of; (iv) per-publisher per- selector DKIM cryptographic-primitive publication-discipline drift (RSA-1024 unrotated / base64-public-key truncation / missing TXT-RR resolution) IS structurally parallel cryptographic-primitive-publication- discipline-drift class to per-forwarder per- hop ARC-Message-Signature cryptographic- attestation publication-discipline drift (missing AAR header / invalid AMS signature / broken AS chain) the ARC explained spoke documents the per-forwarder per-hop diagnostic-and-remediation discipline of. Read the ARC explained spoke when AUTHORING per-publisher per-selector DKIM cryptographic- primitive publication discipline coordinated with per-forwarder per-hop ARC chain-of- custody preservation discipline at the per- publisher per-selector composite cross- protocol application-layer cryptographic- primitive-and-forwarder-survival publication-discipline coordination boundary.
• DMARC for transactional email
• MTA-STS for Google Workspace — the transport-layer counterpart to the message-layer DKIM cryptography this page documents. Where DKIM binds a per-message RSA-2048/Ed25519 signature attesting to message integrity at the application layer, the Workspace-tenant MTA-STS policy (DNS TXT-RR at _mta-sts.<workspace-domain> + HTTPS policy file with the mx: *.google.com allow-list per RFC 8461 §3.2) attests to TLS-secured transport between sending MTA and the Workspace inbound MX. Both rest on public-key cryptography — DKIM on the DNS-published signing key, MTA-STS on the policy file's public-PKI-chain certificate validation — and a Workspace operator deploying defense-in-depth publishes both: the per-selector DKIM key for message-layer authentication and the MTA-STS policy for transport-layer confidentiality, each an operator-owned cryptographic-publication discipline the receiver validates independently.
• Email spoofing explained — the threat-class reference whose seven-technique taxonomy is exactly what the per-message RSA-2048/Ed25519 DKIM signature this page documents is built to defeat: a cryptographic signature an attacker cannot forge without the private key is what lets a receiver tell a genuinely-signed message apart from a direct-domain spoof, so the spoofing techniques are the motivation behind every DKIM cryptographic primitive covered here.
• MTA-STS explained — the transport-layer counterpart to the message-layer DKIM cryptography on this page. Where the DKIM signature binds a per-message RSA-2048/Ed25519 proof of message integrity, MTA-STS commits a receiver's MX to accepting mail only over authenticated TLS — both operator-published, public-key-anchored disciplines a defense-in-depth domain deploys together; read the MTA-STS primer for the transport half of the same cryptographic story.
• TLS-RPT report format — the TRANSPORT-LAYER-CRYPTOGRAPHIC-VERIFICATION-FAILURE-CATALOGUE companion to this DKIM cryptography primer: the public-key signature verification this page explains (the rsa-sha256 / ed25519-sha256 validation of the b= tag against the published p= key) and the TLS certificate-and-cipher verification the report-format spoke enumerates are two cryptographic-verification disciplines at two layers — one authenticates the message body, the other authenticates the transport peer’s certificate chain — and the TLS-RPT report’s result-type field is the structured catalogue of how the transport-layer crypto verification fails, exactly parallel to how DKIM verification fails. Read the TLS-RPT-report-format spoke to see cryptographic-verification failure classification carried from the application-signing layer into the transport-encryption layer.
• Microsoft SNDS + JMRP monitoring — a valid DKIM signature does not outrank a bad IP reputation at Outlook.com: SNDS shows how Microsoft's consumer network actually graded each sending IP (GREEN/YELLOW/RED) and JMRP surfaces the Junk clicks behind a degraded verdict.

15. Audit your DKIM cryptography now

DMARC Analyzer's Domain Security Checker performs a live recursive lookup of any published DKIM public key under a given selector (via includes/DnsChecker.php), reporting the key algorithm (k=rsa or k=ed25519), the inferred key size, the published hash declaration (h=sha256 or default), the service-type scope (s=email), and the DNS TTL of the TXT record. Use it to audit your current DKIM selector and confirm your published key is at least 2048 bits with SHA-256 declared. The Email Header Analyzer parses the DKIM-Signature header from any captured message (via includes/EmailHeaderParser.php) and surfaces the signer's algorithm (a=rsa-sha256 or a=ed25519-sha256), the canonicalization pair (c=relaxed/relaxed), the signed-headers list, the body hash, and the signature — exactly the cryptographic fields documented on this page.

Check my DKIM public key Sign up — Free plan