Public key cryptography in email is a security model that uses two mathematically related keys: a private key that stays secret and a public key that can be shared. Email services use it primarily to sign messages with DKIM and secure mail-server connections with TLS, helping receivers verify that a message is authentic and has not been altered in transit. (mailgun.com)

What public key cryptography means in email

Public key cryptography, also called asymmetric cryptography, is built around a key pair. The two keys are related, but they serve different purposes and must be treated very differently:

The private key is confidential. A sending system uses it to create a digital signature or establish secure cryptographic operations.
The public key is designed to be distributed. A receiving system uses it to verify a signature or validate the identity of the system it is connecting to.

The useful property is not that a public key is hidden—it is explicitly meant to be visible. The security comes from keeping the corresponding private key protected. A receiver can validate something produced by the private key without learning the private key itself.

That model solves a central email problem: an inbox provider needs evidence that a message claiming to be from a domain was authorized by that domain. Email is a distributed system. The sender’s infrastructure, outbound provider, relays, recipient provider, and recipient client may all be operated by different organizations. Public key cryptography gives those organizations a way to verify a claim without having to share a secret credential with every mailbox provider in advance.

In email, the two most important applications are:

DKIM signatures, which let a domain sign messages and publish the verification key in DNS.
TLS, which encrypts SMTP connections between systems and helps a connecting server validate the server it reached.

These jobs are related but different. DKIM is mostly about message-level authentication and integrity. TLS is mostly about protecting the connection while mail is transmitted. Neither is a substitute for the other.

Why public key cryptography matters for deliverability

Public key cryptography is not a deliverability metric like open rate, complaint rate, or bounce rate. You do not improve it by changing a numerator or denominator. Instead, it is foundational infrastructure that affects the authentication signals mailbox providers use when deciding whether a message appears trustworthy.

A message with a valid, aligned DKIM signature gives a receiving provider evidence that the signing domain took responsibility for the message and that signed parts of the message remained intact after signing. DKIM was designed around this exact model: the receiver retrieves the signer’s public key and validates the cryptographic signature. (rfc-editor.org)

That evidence is valuable because spoofed mail is common. If anyone can put billing@example.com in a visible From address with no meaningful authentication, recipients and mailbox providers have little basis for separating legitimate mail from impersonation. SPF, DKIM, and DMARC work together to make those claims testable.

The deliverability effect is indirect but important

A valid key pair does not guarantee inbox placement. Mailbox providers also assess recipient engagement, complaint rates, sending patterns, list quality, content, historical reputation, and other signals. But broken cryptography can remove a basic trust signal before those other factors are even considered.

For example, if a domain has a DMARC policy and all of its messages fail both SPF alignment and DKIM alignment, receivers can apply that policy. Depending on the policy, that can result in quarantine treatment or rejection. Even before an explicit rejection, failed authentication can increase spam-folder placement or complicate reputation building.

For high-volume campaigns, this matters at scale. A minor DNS or key-rotation mistake can affect every message signed with a selector. A campaign with compelling copy and a healthy audience can still underperform if messages do not authenticate consistently.

Authentication supports recognizable sender identity

Recipients see a visible From address, but receiving systems evaluate more than that address. They examine technical identities such as the DKIM signing domain in the d= tag and the envelope sender used by SPF. DMARC connects those authentication results to the domain in the visible From header through alignment.

That means public key cryptography is not just an encryption detail buried in a mail server. It is part of how a sender establishes a reliable domain identity. If a brand sends receipts, password resets, invoices, product announcements, and newsletters from the same domain family, consistent authentication lets receiving systems associate those streams with a controlled identity rather than a collection of unverifiable claims.

How DKIM uses public and private keys

DomainKeys Identified Mail, or DKIM, is the most visible public-key cryptography implementation for email senders. The basic flow is straightforward:

The sender’s email infrastructure has a private DKIM key.
When sending a message, it calculates hashes over selected headers and the message body according to the signing configuration.
It creates a DKIM signature using the private key and adds a DKIM-Signature header.
The receiver reads the selector and signing domain from that header.
The receiver looks up the corresponding public key in DNS.
The receiver uses the public key to verify the signature.

If the verification succeeds, the receiver has evidence that the signer controlled the private key and that the protected message components did not change in a way that breaks the signature.

A DKIM signature does not mean that every recipient wants the message, that the content is safe, or that the sender has a good reputation. It also does not encrypt the email body. It is an authentication and integrity mechanism, not a universal anti-spam or confidentiality guarantee.

The DKIM-Signature header

A DKIM-signed message includes a header that contains several tags. A simplified illustrative example looks like this:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026;
 h=from:to:subject:date:message-id; bh=<body-hash>; b=<signature-data>

The syntax above demonstrates the roles of common tags rather than providing a deployable signature. The values are generated uniquely for a specific message.

v=1 identifies the DKIM version.
a=rsa-sha256 identifies the signing algorithm.
d=example.com identifies the signing domain.
s=mail2026 identifies the selector.
h= lists headers covered by the signature.
bh= contains the body hash.
b= contains the cryptographic signature.

The selector is especially useful operationally. It lets one domain publish multiple keys at the same time. Instead of placing a single public key at a fixed DNS name, DKIM uses a selector-specific hostname. That enables a sender to migrate keys, separate systems, and rotate credentials without immediately invalidating messages signed with an older active key.

Where the public key lives

For a traditional TXT-record deployment, a receiver queries a hostname in this form:

<selector>._domainkey.<signing-domain>

For the example signature above, the DNS name would be:

mail2026._domainkey.example.com

A DKIM public-key record uses the v=DKIM1 version tag and commonly uses a p= tag containing the encoded public key. A structural example is:

mail2026._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=<base64-encoded-public-key>"

Do not publish the literal placeholder shown above. Your sending provider or mail-transfer software must generate the real key material. A malformed, incomplete, copied-with-spaces, or truncated p= value will fail verification.

The DKIM standard uses DNS TXT records to distribute public keys, with the signing domain and selector controlling the lookup name. (rfc-editor.org)

Public key cryptography in TLS for SMTP

DKIM is not the only place email relies on asymmetric cryptography. TLS also uses public-key mechanisms when mail servers negotiate encrypted connections.

SMTP was originally designed without mandatory encryption. STARTTLS later provided a way for SMTP servers to negotiate a TLS-protected connection. During TLS setup, the receiving server presents a certificate containing a public key and identity information. The sending server can validate the certificate chain and determine whether it is communicating with the intended server, subject to the TLS configuration and policy in use.

In practical terms, TLS protects the connection between mail servers while it is active. It helps prevent passive observers from reading message contents while messages move from one system to another. It also reduces the risk that an attacker can impersonate a receiving server during the SMTP session.

TLS protects a route; DKIM protects a signed message

The distinction matters:

TLS encrypts a connection between two servers. A message can travel through multiple SMTP hops, each with its own connection.
DKIM travels with the message as a signature header. A recipient can verify the signature later by looking up the signer’s public key.

A message can have valid TLS on a hop but no valid DKIM. It can also have valid DKIM but arrive over a connection where TLS was unavailable or not enforced. Strong email operations use both where possible, because they mitigate different risks.

MTA-STS is a related transport-security standard. It allows a domain to publish a policy that tells compatible senders to require TLS and validate certificates when delivering mail to that domain’s MX hosts. It is concerned with secure SMTP transport, not with signing outbound mail. (rfc-editor.org)

Public key cryptography and DMARC alignment

DKIM verification alone is useful, but DMARC asks a more specific question: does a successful authentication result correspond to the domain the recipient sees in the From header?

Imagine a message has this visible identity:

From: Updates <news@example.com>

Now imagine it is signed with:

d=mailer-vendor.invalid

The DKIM signature might technically pass, because the vendor’s public key validates the vendor’s signature. But a successful signature from mailer-vendor.invalid does not automatically prove that example.com authorized use of the visible From address.

DMARC addresses that gap through alignment. A DKIM result can support DMARC when the domain in DKIM’s d= value aligns with the domain in the visible RFC 5322 From header. A message can also pass DMARC through aligned SPF. One aligned authentication path is sufficient for a DMARC pass. (rfc-editor.org)

Relaxed and strict alignment

DMARC can evaluate DKIM alignment in relaxed or strict mode.

Relaxed alignment generally permits related subdomains under the same organizational domain.
Strict alignment requires an exact domain match.

For example, mail.example.com may align with example.com under relaxed alignment but not under strict alignment. The correct choice depends on how a sender structures domains, subdomains, and third-party services.

The key operational lesson is simple: configure your email platform to DKIM-sign using a domain that aligns with the domain recipients see in the From address. If campaign mail comes from news.example.com, a signing domain of example.com or news.example.com will generally make alignment easier than a completely unrelated provider domain.

Why aligned DKIM is resilient in common sending flows

SPF checks the sending infrastructure and envelope identity. When messages are forwarded, the forwarding server may not be included in the original sender’s SPF authorization, which can cause SPF to fail. DKIM is often more durable because the signature is attached to the message rather than tied to the forwarding IP address.

That durability depends on preserving signed content. A forwarding system, mailing list, or security gateway can modify headers or the body enough to invalidate the DKIM signature. Still, properly configured aligned DKIM provides an important independent authentication path for many normal mail flows.

Is public key cryptography a metric?

No. Public key cryptography is not a rate, score, or campaign KPI, so there is no meaningful calculation such as “public-key-cryptography rate.” It is a technical security model implemented through protocols, keys, certificates, signatures, and verification results.

What you can measure are outcomes related to it. These include:

DKIM pass rate: the share of observed messages that receivers report as DKIM-authenticated successfully.
DMARC pass rate: the share of messages that pass DMARC through aligned SPF or DKIM.
Authentication failure volume: the number of messages associated with DKIM failures, alignment failures, or missing signatures.
Key-rotation coverage: whether all intended outbound systems are signing with an active, published selector.
TLS delivery coverage: the share of SMTP deliveries completed with TLS, where your provider exposes that information.

These measurements come from message headers, provider event logs, DMARC aggregate reports, and deliverability monitoring—not from the cryptographic model itself.

A practical way to read authentication results

A received message often includes an Authentication-Results header added by the receiving environment or an intermediary. The exact formatting varies, but a healthy outcome may resemble this:

Authentication-Results: mx.recipient.example;
 dkim=pass header.d=example.com;
 spf=pass smtp.mailfrom=bounces.example.com;
 dmarc=pass header.from=example.com

The valuable details are the result and the identity that was authenticated. dkim=pass tells you signature verification worked. header.d=example.com tells you the signing domain. dmarc=pass indicates that the visible From domain passed DMARC through an aligned mechanism.

If you monitor only whether a message was accepted by your sending API, you can miss this distinction. API acceptance says the platform accepted the message for processing. It does not necessarily prove that the message was signed correctly, that the receiver could resolve the public key, or that the signature aligned with the From domain.

Common public-key cryptography problems in email

Public-key failures in email usually come from configuration, DNS, key management, or message handling—not from someone breaking the underlying mathematics. The most common issues are operational.

Missing or incorrect DKIM DNS records

A receiver cannot verify DKIM if the selector referenced in the message does not resolve to a valid public key. Common causes include:

The DNS record was never published.
The record was created under the wrong hostname.
The selector in the DNS record does not match s= in the signature.
The d= domain and published record do not match.
The record value was truncated or incorrectly split by the DNS provider.
A TXT record was pasted with extra quotation marks, escaped characters, or whitespace in the wrong place.

The exact DNS hostname matters. A record at _domainkey.example.com is not the same as a record at selector._domainkey.example.com. Similarly, a record at the root domain may not help if the signer uses a subdomain in d=.

A private key and public key no longer match

A DKIM signature is valid only when the signing private key corresponds to the published public key. Problems arise when a team replaces one side but not the other.

For example, a provider may begin signing with a new private key while DNS still publishes the old public key. The receiver finds a key, but it cannot validate the new signatures. The opposite problem is also possible: DNS is changed first, while an old sending server continues using the old private key.

This is why safe rotation uses overlapping selectors or carefully coordinated transitions. Keep the old key available while mail signed before or during the transition can still be verified, then retire it only after the sending estate and DNS caches have moved to the replacement.

Incorrect DNS delegation with CNAME records

Some email platforms use CNAME delegation rather than asking customers to publish a raw DKIM TXT record. The customer publishes selector hostnames that point to the provider’s key-hosting infrastructure. The provider can then manage active keys and rotation behind those aliases.

Mailgun documents a model that uses two CNAME records for DKIM key management, allowing a new key to be introduced while the prior key remains active. Its examples use selector hostnames such as pdk1._domainkey and pdk2._domainkey; the dual-key design helps account for DNS caching during rotation. (documentation.mailgun.com)

CNAME delegation can reduce manual key-management mistakes, but it still must be set up exactly as instructed. A common failure is creating the CNAME at a doubled domain name because a DNS interface automatically appends the zone name. Another is adding a conflicting TXT record at the same hostname.

Signature-breaking message modifications

DKIM is intentionally sensitive to changes in the fields and body content that were signed. This is a feature: it allows receivers to detect tampering. But legitimate systems can make modifications too.

Potential signature-breaking changes include:

A mailing list adding text to the message body.
A gateway rewriting the Subject line or other signed headers.
A security product modifying links in the HTML body.
A CRM, relay, or custom MTA adding or changing headers after signing.
Incorrect canonicalization choices combined with formatting changes.

The answer is not to avoid signing meaningful parts of a message. Instead, sign at the final stage of outbound processing whenever possible. Link rewriting, footer insertion, open tracking, and personalization should happen before DKIM signing. If a downstream system must transform the message, test whether it preserves your intended authentication results.

DMARC alignment failures

It is possible to see dkim=pass and still see dmarc=fail. That happens when the signing domain does not align with the visible From domain and SPF does not provide an aligned pass either.

This is especially common when a marketing platform signs only with its own domain, while the customer uses a branded From address. The repair is usually to authenticate a custom sending domain or subdomain in the platform and configure the From address accordingly.

For example, a sender using offers@example.com should prefer DKIM signing with example.com or a suitable subdomain such as mail.example.com, depending on the DMARC alignment mode and architecture. Signing only as vendor-mail.example leaves an alignment gap.

How to improve public key cryptography for email sending

The goal is not to make cryptography more complicated. The goal is to make authentication reliable, observable, and maintainable across every system that sends as your domain.

1. Inventory every outbound sender

Start with the systems that can send mail using your organization’s domain:

Transactional email APIs and SMTP relays.
Marketing automation platforms.
Customer-support tools.
Billing and invoicing systems.
Product-notification services.
Recruiting, survey, and event platforms.
Internal applications and custom mail servers.

For each one, identify the visible From domain, envelope sender domain, DKIM d= domain, selector, and the team responsible for DNS. Many authentication failures happen because only the main marketing platform was configured while transactional or support mail was left on a provider-owned signing domain.

2. Authenticate a sending domain you control

Use a domain or subdomain under your organization’s control for the mail stream. A subdomain is often useful for separating mail categories, such as notify.example.com for application notices or news.example.com for marketing.

Separation can help operationally. Different mail types have different audience expectations, volumes, sending patterns, and reputation risks. A password reset and a daily promotional campaign should not necessarily share every identity and reputation surface.

Set up the records the provider supplies, then verify that the actual sending configuration uses the authenticated identity. Publishing records alone is not enough if an application still sends using a default provider domain.

For implementation guidance on configuring an API or SMTP sending domain, review the email API setup guides before changing DNS or production credentials.

3. Use a selector strategy, not a permanent one-key assumption

Selectors allow multiple DKIM keys to coexist. Treat them as an operational control plane.

A useful selector naming scheme can encode the system and rotation period, such as app1, mktg1, or mail2026a. Do not include secrets in selector names; selectors are public DNS labels. Their purpose is identification and key lookup, not access control.

When you rotate, publish the new selector, update the signing system, verify the new signature on real delivered messages, and retain the old public key for a transition window. Only then retire the old selector according to your documented process.

4. Protect private keys as production secrets

The private DKIM key must never be placed in public DNS, source control, browser code, support tickets, or client-side logs. Anyone who obtains it can potentially sign messages that appear to come from the associated domain until you replace the key and update DNS.

Use your provider’s managed signing service when appropriate, or store self-managed keys in a restricted secret-management system. Limit access to the systems that need to sign mail. Track who can change the key, DNS records, and sender configuration.

Key rotation should be scheduled as part of routine credential hygiene and performed immediately if compromise is suspected. Mailgun’s DKIM security guidance recommends rotating keys at least every six months and immediately after a suspected compromise. (documentation.mailgun.com)

5. Confirm alignment with the From domain

After sending a test message to a mailbox you control, inspect the raw headers. Do not stop at a green “DKIM pass” indicator. Check these questions:

Did DKIM pass?
What is the value of header.d or the d= tag?
Does that domain align with the visible From domain?
Did DMARC pass?
Is the intended selector being used?
Is another application still signing with a legacy or unaligned domain?

This test should be repeated after a provider migration, DNS change, new sending stream, key rotation, or email-template change that introduces downstream processing.

6. Monitor failures before they become campaign incidents

Authentication failures can be intermittent. One region, legacy host, fallback provider, or automated workflow may still sign with an old key while most traffic looks healthy. Monitor by stream and selector where your provider reporting allows it.

DMARC aggregate reporting can also reveal sources claiming to send for your domain and show whether SPF and DKIM are passing and aligned. Use that information to find unapproved senders, forgotten platforms, or configuration drift.

For campaign operations, add an authentication preflight to launch checklists. Verify the From domain, return-path configuration, DKIM selector, DMARC outcome, unsubscribe behavior, and production template rendering before sending the full audience.

RSA, Ed25519, and algorithm choices

DKIM originally standardized RSA-based signatures, commonly represented in message headers with values such as rsa-sha256. RFC 8463 added Ed25519-SHA256 as another DKIM signing algorithm and defines k=ed25519 for the corresponding DNS public-key record. (rfc-editor.org)

For most senders using a managed email platform, the platform determines the available algorithm and key-management approach. The practical question is not “which algorithm sounds newest?” It is whether the platform’s configuration is supported by the receivers that matter to your audience and whether the provider manages key rotation safely.

Why key size and DNS behavior matter

RSA public keys can be comparatively large. DNS TXT-record limits and DNS provider interfaces can make large values awkward, especially when a provider splits a long TXT value into quoted chunks. Properly formed DNS systems can join those chunks, but manual editing increases the chance of mistakes.

Ed25519 keys are more compact, which can simplify key publication. However, compatibility and platform support should be validated in your actual sending environment. If your provider offers a managed configuration, follow its current documentation rather than manually switching algorithms based only on a generic example.

The cryptographic algorithm is important, but it is rarely the first deliverability bottleneck. A valid RSA DKIM deployment with good alignment, careful key rotation, and consistent sender behavior is far better than an unsupported or poorly implemented algorithm change.

Public key cryptography does not solve every email security problem

It is tempting to treat signed mail as inherently safe. That would be a mistake.

A malicious sender can operate its own domain, publish its own public key, sign its own messages, and still send phishing or spam. DKIM proves that a domain took responsibility for a message; it does not certify that the sender is reputable or that the content is benign.

Similarly, TLS can encrypt a server-to-server connection, but it does not provide end-to-end encryption between the human sender and recipient. Each system that legitimately processes the message may be able to access its contents.

Public key cryptography should therefore be viewed as one layer in a broader email program that includes:

SPF and DMARC configuration.
Permission-based list building.
Clear sender identity and accurate From addresses.
Consent records and easy unsubscribe handling.
Suppression of hard bounces and complaints.
Content and link security.
Access control for sending APIs and SMTP credentials.
Monitoring of reputation and authentication outcomes.

For deliverability, this layered view matters. Authentication opens the door to trust, but recipient experience determines whether that trust grows or erodes over time.

A practical troubleshooting workflow

When an email platform reports a DKIM, DMARC, or public-key-related problem, avoid guessing. Work from the actual message and DNS data.

Step 1: Capture an original delivered message

Send to a mailbox you control at a major provider and download or inspect the full original source. Do not rely solely on what the email client displays in its normal reading view.

Locate the DKIM-Signature header and record the d= and s= values. Find the Authentication-Results header and note the result for DKIM, SPF, and DMARC.

Step 2: Build the expected key lookup name

Combine the selector and signing domain:

<selector>._domainkey.<d-domain>

If the signature includes s=mail2026 and d=example.com, the receiver should be able to resolve:

mail2026._domainkey.example.com

Check that exact name in DNS. If it is absent, points somewhere unexpected, or returns malformed data, fix the DNS record or sending configuration.

Step 3: Check whether DNS uses TXT or CNAME delegation

A platform may provide a TXT record containing a public key or CNAME records that delegate the selector hostnames to the provider. Follow the platform’s supplied record type precisely. Do not replace a requested CNAME with a TXT record or vice versa unless the provider’s documentation explicitly supports that architecture.

Step 4: Check for a rotation mismatch

Compare the active selector used in the live message with the selectors currently published. If the message is signed with an older selector, confirm that the old public key still exists. If it is signed with a new selector, confirm that DNS propagation has completed and the target public key matches the active private key.

Step 5: Test the final production path

A message signed in a staging environment may pass but fail after a production relay adds tracking, headers, or compliance content. Test the actual route used by live mail. The signing step should occur after changes that modify signed content.

Conclusion: trust depends on operational discipline

Public key cryptography in email is the mechanism that lets a sending domain make verifiable claims without exposing its secret signing key. Through DKIM, a domain can sign messages and let recipients validate those signatures using a public key in DNS. Through TLS, mail servers can protect SMTP connections and validate server identities during transport. (mailgun.com)

For deliverability, the biggest win is dependable authentication: publish the right records, sign every intended stream, align DKIM with the visible From domain, protect private keys, and rotate them without breaking verification. Cryptography is only one part of inbox placement, but it is a prerequisite for a modern, defensible sender identity.

FAQ

What is public key cryptography in email?

Public key cryptography in email uses a public/private key pair to verify sender-controlled signatures and secure server connections. Its most common email uses are DKIM, which signs messages, and TLS, which protects SMTP connections during transmission.

Is DKIM encryption?

No. DKIM is primarily a digital-signature system. It helps verify that signed message content was not altered and that the signing domain controlled the relevant private key. It does not hide the message contents from recipients or mail systems processing the message.

Where is a DKIM public key published?

The public key is normally published in DNS at a selector-specific hostname such as selector._domainkey.example.com. Some providers use CNAME delegation, where that hostname points to provider-managed DKIM key infrastructure.

Why does DKIM pass but DMARC fail?

DKIM can pass for a signing domain that does not align with the visible From domain. DMARC requires an aligned SPF or DKIM pass. Configure the sending platform to sign with your domain or an aligned subdomain, and confirm the final result in message headers.

How often should DKIM keys be rotated?

Use your provider’s documented rotation process and rotate immediately after suspected compromise. Managed providers may support overlapping selectors or automated rotation so the new public key can be introduced without interrupting verification for mail signed with the previous key.

Public Key Cryptography in Email: DKIM, TLS, and Trust