Apply recipient allow and block lists at the correct scope

Choose the policy direction deliberately

Email lists distinguish send, receive and reply directions, each with allow and block types. A policy about who may send work into an inbox is different from a policy about whom an agent may contact. Use the direction that matches the actual boundary and review the runtime path used by your action. Do not assume adding a receive allowance automatically authorizes an outbound response. Key permissions, signup-recipient gates and provider readiness remain separate checks, so a list entry is only one part of a message’s admission decision.

Understand hierarchical evaluation

Lists exist at organization, project and inbox scope. Enforcement walks the relevant hierarchy; a block hit rejects the address, and a non-empty allow list rejects addresses outside its permitted set. An inbox-specific allowance should not be presented as a way to bypass a broader organizational restriction. Build a policy explanation that identifies the effective scopes rather than showing only the nearest inbox setting. For a multi-tenant service, this allows an organization-wide safety rule to coexist with a project’s customer-specific audience and an individual inbox’s operational needs.

Use addresses and domains intentionally

List entries can be email addresses or domains, with entry_type derived from the value. Be explicit about whether the intended grant covers one person or everyone at a domain. A domain allowance can include an audience much broader than the named reviewer who requested it. Keep a reason field for operator understanding and maintain your own change history if your governance requires one. Do not use display names or body text as list keys. Those values are sender-controlled and do not identify the routing address the server actually evaluates.

{"entry":"reviewer@example.com","reason":"Named reviewer for approved case responses"}

Read the rejection in its stage

A send-list rejection returns 403 rejected and emits email.rejected. A receive block can preserve the message with a blocked label rather than make it disappear as though nothing arrived. Protected-label permissions then affect which workers can see that message. Platform-managed read-only entries return 403 on deletion. Keep these outcomes distinct from a missing credential or an unverified workspace recipient gate. An agent that sees a blocked message for investigation still lacks permission to act on its instructions or reply outside the configured audience.

Change policy without a test-send loop

Use the scoped list endpoints to inspect and modify entries, then evaluate a fixture matrix before allowing real external actions. For example, compare an explicitly allowed reviewer, an unknown address at the same domain and a blocked address that also matches a broad allowance. Show the operator which rule needs review rather than trying new recipients until a send succeeds. Your next step is to inventory all applicable scopes for one inbox and write down the smallest policy that supports its actual communication workflow.

Keep an emergency path reviewable

If legitimate mail is blocked, preserve the draft or case and ask an authorized owner to review the specific rule. Do not delete the organization’s allow list as a shortcut. After a deliberate change, recheck the final recipient set because cc and bcc addresses can still fall outside the approved audience.

Sources & verification

Reviewed against checked-in Lupin API handlers and documentation. Example requests were not executed against live providers.

• Lupin allow and block lists ↗Checked 2026-11-05
• Lupin message policy behavior ↗Checked 2026-11-05
• Lupin protected label visibility ↗Checked 2026-11-05

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.