> This page is part of the [Customer.io documentation](https://docs-customerio.netlify.app). For the complete index, see [llms.txt](https://docs-customerio.netlify.app/llms.txt).
> Last updated: May 27, 2026

# Set up anonymized email relay addresses

If you have data residency or PII compliance requirements that prevent you from storing real email addresses outside a specific jurisdiction, you can use synthetic email addresses with an email relay. Customer.io sends messages to the synthetic addresses, and your relay forwards them to the real recipients. This keeps real email addresses out of Customer.io entirely.

 Deliverability trade-offs

When you use anonymized relay addresses, Customer.io can’t see real recipients’ domains. This limits our ability to help with deliverability issues. Before you set up this pattern, read the [deliverability trade-offs](#deliverability-trade-offs) section to understand what you’re taking on.

## How it works[](#how-it-works)

When you identify people, you’ll generate anonymized, RFC-valid email addresses—like `usr_abc123@relay.example.com`—and store them on Customer.io profiles in place of real `email` [attributesA key-value pair that you associate with a person or an object—like a person’s name, the date they were created in your workspace, or a company’s billing date etc. Use attributes to target people and personalize messages.](/journeys/attributes/). You’ll also set up and control a relay domain like `relay.example.com` where you store and relay messages to the real recipients.

When you send an email through Customer.io, the message goes to the synthetic address. Your relay server receives the message, looks up the real recipient in your internal identity vault, and forwards the message to the real email address.

## Set up anonymized addresses[](#set-up-anonymized-addresses)

Your anonymized addresses need to meet a few requirements:

*   **Set on the `email` attribute.** The anonymized address must be set on the `email` attribute of the profile. This is how we send emails.
*   **RFC-valid format.** Each address must be a standard email address (for example, `usr_abc123@relay.example.com`).
*   **Dedicated relay domain.** Use a domain your organization controls, like `relay.example.com`. This is where you’ll store and relay messages to the real recipients.
*   **One-to-one mapping.** Each anonymized address maps to exactly one real recipient in your internal identity system.

## Set up your email relay[](#set-up-your-email-relay)

To support anonymized addresses, you’ll set up a relay server that sits between Customer.io and your real recipients. Here’s what you need to do:

1.  **Configure MX records.** Point MX records for your relay domain to your relay server so it receives messages sent to anonymized addresses.
    
2.  **Accept and enqueue messages.** Your relay should accept incoming SMTP connections and enqueue messages for asynchronous processing. Don’t forward synchronously—we send messages in high-volume, and synchronous forwarding could cause timeouts or overwhelm downstream servers.
    
3.  **Look up real recipients.** When processing a queued message, query your internal identity vault to resolve the anonymized address to the real recipient.
    
4.  **Rewrite and forward.** Replace the envelope recipient with the real email address and forward the message to the real recipient.
    
5.  **Scale for your volume.** Size your relay infrastructure to handle your peak sending volume with headroom for bursts. Customer.io can deliver messages in high-volume bursts. If your relay forwards synchronously, slow downstream servers cause SMTP timeouts. Accept and enqueue first, then process the queue at a rate your infrastructure can handle.
    

## Report delivery metrics back to Customer.io[](#report-delivery-metrics-back-to-customerio)

By default, Customer.io sees delivery metrics for the relay domain, not the real recipients. If you want bounce rates, delivery confirmations, and other metrics to appear in Customer.io, you can forward them from your downstream email provider.

1.  **Proxy webhook callbacks.** If you use a provider like SendGrid for final delivery, configure it to send delivery webhooks to your infrastructure.
    
2.  **Strip PII.** Remove real email addresses from the webhook payloads and replace them with your Customer.io identifiers (the synthetic addresses or profile IDs).
    
3.  **Forward to Customer.io.** Send the sanitized payloads to Customer.io’s provider-specific metric endpoints, or use the [Track API](/api/) generic metric submission endpoint to report delivery events.
    

This gives you visibility into delivery performance in Customer.io without exposing real recipient data.

## Deliverability trade-offs[](#deliverability-trade-offs)

Using anonymized relay addresses adds a layer between Customer.io and your real recipients which means you take on full responsibility for deliverability to the real recipients. This means that we can’t provide support for delivery issues to the real recipients.

*   **No inbox placement support.** Customer.io can’t troubleshoot delivery issues for the real recipients because we don’t know who they are.
*   **No DKIM/SPF alignment verification.** We can’t verify that authentication aligns for the final destination domain—only for the relay domain.
*   **Limited bounce management.** Customer.io sees bounces from the relay domain, not from real recipient mailboxes. Bounces at the real destination don’t automatically suppress email addresses in Customer.io—which you should do to maintain your domain reputation.
*   **Limited reputation monitoring.** We can only monitor sender reputation for the relay domain, not for the domains your recipients actually use.
*   **Additional opacity with custom SMTP.** If you already use a custom SMTP provider, deliverability visibility is more limited than with Customer.io’s built-in sending. Adding a relay creates another layer of opacity on top of that.