2026 RFC 9979 $maskedemail: How Do Email Clients Stay Compatible?

What $maskedemail means

RFC 9979 defines $maskedemail as a hint that a message was received through a masked address intended for a particular contact. The standard registers the marker; it does not make the marker a universal property of every message, mailbox, or email service. See the RFC 9979 definition and registration and the corresponding IANA registration.

That distinction should guide both implementation and product language. When a client reads the marker, it can present a cautious clue about the route used for that message. It cannot conclude that the sender was verified, that the user’s identity is hidden from every party, or that the address is unsafe. Nor does the marker create a masked address or configure mail forwarding.

A marker also does not replace the message’s addresses or other mail metadata. Treat it as one piece of message-level information. If the client displays it, the explanation should stay close to the claim the standard supports: the message appears to have arrived through an address masked for a particular contact.

For users managing an IMAP email alias or a JMAP email alias, the marker may help make a message’s address role more visible. It does not prove how the alias was created, who controls it, or whether it remains active.

Client developers: choose how the hint appears

The RFC defines the marker, but it does not require every client to show it using the same label, badge, or layout. A client may recognize and present the information, but teams should not mistake an optional interface choice for a requirement that applies uniformly across products.

Start by checking how the client reads keywords for each supported protocol. IMAP represents message keywords through its flags and keyword mechanisms, described in RFC 9051. JMAP exposes message keywords through its Email model, described in RFC 8621. Do not assume that a value observed through one protocol is automatically available, stored, or displayed the same way through the other. Verify each path in the actual client and server combination.

Then make the display decision explicit:

• If the marker is present and the client recognizes it, show a restrained cue that describes the message as having arrived via a masked address.
• If the marker is absent, do not infer that the message used a normal address or that the alias has stopped working.
• If the client does not recognize the marker, preserve ordinary message behavior. Avoid turning an unfamiliar keyword into an error unless the product has a separate, documented reason to do so.

A small, contextual label is usually safer than a warning. A warning can imply that the message is dangerous or that the address has leaked, neither of which follows from the marker alone. If your client includes an explanation, place it where users can connect it to the message without confusing it with sender authentication or a privacy guarantee.

Product and UX teams: describe only the supported signal

The interface should tell users what the marker indicates without turning a hint into a verdict. Copy such as “Received via a masked address” stays closer to the standard than claims like “Sender verified,” “Anonymous email,” or “This address is compromised.” The marker itself does not establish any of those conclusions.

Keep the user’s next action separate from the message label. A product might let users manage or deactivate an alias, but that capability belongs to the product’s alias-management system—not to $maskedemail. If the interface offers a control to disable an address, test that control independently and make clear which address it affects. Do not make the marker itself a switch or imply that removing the marker disables the route.

This separation matters for long-term inbox management. A user may want to identify which address a service used, but still need the alias for account recovery, receipts, or ongoing correspondence. The marker can help explain a message; it cannot decide whether the user should keep the address.

For a broader comparison of address choices, see our guide to temporary email versus an email alias. The key difference is functional: a message hint is not an address-management feature.

Server maintainers: verify the generation boundary

RFC 9979 defines the marker and describes its role in messages received through a masked address. That does not establish that every server implements it, emits it in every applicable case, or exposes it through every client-facing protocol. Confirm the behavior in the specific server and test environment before documenting support.

Record the source of each test message and the server path that handled it. If the environment supports the marker, inspect whether it is present in the protocol representation the client consumes. If the environment does not provide it, record that as an implementation or test-environment limitation rather than as evidence that the RFC has no effect.

For IMAP, check how the server exposes the keyword and how the client retrieves it. RFC 9051 describes IMAP flags and keywords, while the IANA registry provides the registered keyword information. For JMAP, inspect the message’s keyword data using the model defined in RFC 8621. These references describe protocol behavior; they do not certify a particular vendor’s support.

Avoid a common inference error: a test that shows the marker in one environment demonstrates that environment’s behavior, not universal server support. Likewise, a test that does not show the marker may indicate missing server support, a different delivery path, an unsupported protocol exposure, or a client parsing issue. Separate those possibilities in the test record.

QA teams: cover marker presence and absence

A useful test plan exercises both the message signal and the address context. Do not test only a single marked message and then label the client “compatible.” A result is meaningful only when the team records what the server supplied, which protocol carried it, and what the interface rendered.

Use a controlled set of cases:

• Marker present: Deliver a message through a test address intended for a specific contact, using an environment known to provide $maskedemail. Confirm that the client reads the marker and that any label matches the original message and the test address.
• Marker absent: Use an otherwise comparable message without the marker. Confirm that the client does not invent an alias-related status or treat the message as failed.
• Ordinary address: Test a message received through a non-masked address. Confirm that the client does not show the masked-address cue simply because the message contains other keywords or because the sender is unfamiliar.
• Protocol variation: Run the relevant cases over IMAP and JMAP when both are supported. Record the protocol representation and the user-visible result separately.
• Unknown or unrendered keyword: Check how the client behaves when it encounters a keyword it does not use for a dedicated interface cue. Ordinary reading and handling should remain understandable; any special behavior should be deliberate and documented.

The comparison below helps teams keep standards behavior, implementation behavior, and user-facing behavior from collapsing into one pass/fail label.

For each case, preserve the original message or a reproducible test fixture, the address role used, the server and client build identifiers, protocol, raw marker observation, and rendered result. That record lets a later reviewer distinguish a server change from a parser regression or a deliberate UI change.

Release owners: keep a compatibility record

Before release, record which client build and protocol you tested, which server environment supplied the message, whether the marker was present, and what the interface showed. Add the test fixture or a safe reproduction method so another team member can repeat the observation. If the server cannot supply a marked message, say so directly; do not describe that environment as having passed marker-display testing.

Separate three statements in release notes and internal documentation:

• Standard: What RFC 9979 defines and what the relevant protocol specifications describe.
• Product behavior: What your client, server, or alias-management feature actually does.
• Recommendation: What your team advises users to do when the marker is absent or visible.

This separation prevents a product-specific choice from being mistaken for an RFC requirement. It also makes maintenance easier: if an implementation changes, the team can rerun the relevant cases without revisiting every claim about the standard.

Recheck compatibility when a client changes how it parses keywords, when a server changes its delivery or protocol behavior, or when the product alters its message labels. The RFC 5788 document record is useful background on IMAP keyword registration; it does not establish support for $maskedemail in any particular deployment. Use the current RFC and registry entry for the marker itself.

Long-term email users: treat the marker as a clue

If you see $maskedemail in a client, read it as an indication about how that message arrived—not as a security score. Check the actual address associated with the account and decide whether it should remain active based on your need for future mail, account recovery, and replies. A marker alone cannot tell you whether an address is safe to close. If you are reviewing an alias before retiring it, our alias exit checklist can help you consider dependencies separately from the marker.

If the marker is missing, the same caution applies. The absence may reflect server support or the way the client obtains message data. It does not establish that the underlying address is broken. When a message matters, verify the address and delivery route through the account or service that owns them rather than treating the missing keyword as a delivery diagnosis.

InboxCloak’s temporary email can be an option when you only need an address for a short-lived registration or one-time verification and do not want to give that service your primary address. For an address you expect to keep using, first check the service’s actual long-term receiving and forwarding capabilities; do not infer them from RFC 9979 or from the presence of $maskedemail.