What happens when organisations try to secure email without publishing public keys or supporting directory lookup?

Without public key publication or directory lookup, senders may not be able to encrypt the first message to a recipient. That creates friction, delays secure communication, and pushes users toward insecure workarounds. A usable encryption model must let communication partners discover the public key quickly while keeping the private key under the certificate owner’s control.

Why secure email needs a discoverable public key

Secure email works best when the sender can locate a recipient’s public key before the first protected message leaves the mailbox. If the key is not published somewhere trustworthy, the sender cannot complete end-to-end encryption on first contact. That usually forces a fallback to plaintext, delayed delivery, or a manual exchange step that many users will skip under pressure.

The practical issue is not the cryptography itself, but discoverability. Email security depends on a usable way to bind an address to the correct key, so the sender can encrypt to the intended recipient without guessing. If that binding is missing, the system may still support secure mail later, but the first interaction becomes the failure point.

What directory lookup changes in day-to-day email use

Directory lookup removes the need for every sender to already possess the recipient’s key. Instead, the sender can query a directory, certificate service, or equivalent lookup mechanism and retrieve the public key on demand. That reduces friction, makes encryption more repeatable, and avoids the common pattern where secure mail only works after an out-of-band exchange has already happened.

Without lookup, users often rely on cached keys, prior correspondence, or side channels to find a usable certificate. Those workarounds are fragile. They are especially weak in large organisations, where people exchange mail with new contacts, contractors, or shared mailboxes every day. A secure design must therefore assume first-contact messaging is normal, not exceptional.

Why insecure workarounds appear when first-message encryption fails

When the first secure message cannot be sent automatically, users tend to optimize for speed rather than assurance. They may send the initial email unencrypted, ask the recipient to respond first, copy a key from an unverified source, or disable encryption for convenience. Each of those choices weakens the security model because the system has made the safe path slower than the unsafe one.

A usable public key model should minimise manual steps, preserve the private key under the owner’s control, and make it obvious which key is current. That is the core design trade-off: more lookup and publication support usually means less user friction and fewer security regressions. When organisations omit that support, they often create a policy that looks strong on paper but collapses in real workflows.

Risk and Threat Considerations

When public keys are not published or discoverable, the main risk is not just inconvenience, but predictable bypass. Users and support teams may resort to plaintext, ad hoc key exchange, or unverified attachments, which increases exposure to interception, misdelivery, and impersonation during the first sensitive conversation.

Failure mechanism: The sender cannot reliably obtain the recipient’s correct public key at the moment encryption is needed, so secure delivery fails at the point of use and users substitute weaker communication paths.

Impact: Confidential messages may be sent without encryption, security adoption drops, and attackers gain a larger opportunity window to read, alter, or impersonate mail before a trusted key path is established.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	Email key discovery depends on reliable user-to-key binding for trusted communication.
	IA-5 — Authenticator Management	Published keys and lookup services support usable credential and key lifecycle control.
	IA-8 — Identification and Authentication (Non-Organizational Users)	External recipients also need trustworthy key discovery for first-contact secure mail.
Recommendation — Require reliable identity binding before allowing secure message exchange. Manage key lifecycle so users can find current keys without manual workarounds. Verify external-user identity and key binding before encrypting to them.
ISO/IEC 27001:2022	A.5.15 — Access control	Key publication and lookup are access-enabling controls for protected email exchange.
	A.8.24 — Use of cryptography	The question concerns practical use of cryptography for email confidentiality.
Recommendation — Define how recipients are discovered and authorized for protected messaging. Ensure cryptography is usable in the real mail flow, including key discovery.

Practitioner Guidance

What to verify: Test the first-contact flow, not just steady-state mail. A usable design should allow a sender to find the current public key quickly, confirm it is tied to the intended address, and encrypt without asking the recipient for a manual setup step.

Common mistake: Treating “we support encryption” as equivalent to “users can actually use encryption on their first message.” If lookup is missing, the control is often bypassed in practice even when the policy is formally enabled.

Practitioner takeaway: The real test of secure email is whether it works before a relationship exists, because that is where usability, trust, and cryptographic control either reinforce each other or fail together.