A **contact** is a person: one email address, plus whatever [attributes](/audience/attributes) you know about them and whatever they've consented to receive. Contacts are the raw population SendOps works from — [Lists](/audience/lists) and [Segments](/audience/segments) are ways of *grouping* them.

Contacts live under **Infrastructure › Contacts** in the dashboard, next to [Topics](/audience/topics). That placement is deliberate, and it's the thing most worth understanding on this page: **contacts are not really yours — they're your AWS account's.**

## Contacts are not lists

This is the distinction that trips people up, so here it is plainly:

| | **Contacts** | **[Lists](/audience/lists)** |
|---|---|---|
| What it is | Every person SendOps knows about | A group *you* build to send to |
| Where it lives | Your AWS account's SES contact list | SendOps only — AWS never sees it |
| How many | Exactly one set, per AWS account | As many as you like |
| Who puts people in it | SES and SendOps, by syncing | You, the API, or a connected repo |
| Do you send to it? | **No** | **Yes** |

The short version: **you browse contacts; you send to lists and [segments](/audience/segments).** If you're reaching for the contact browser to pick who gets an email, reach for a list instead.


  Adding someone to a List doesn't create a second copy of them, and removing them from a List doesn't delete them. There is one contact per email address, and Lists are just labels on top of it. Removing a contact from a List also does **not** unsubscribe them — see [Consent & lifecycle mail](/sending-email/consent-and-lifecycle).


## Where contacts come from

AWS SES gives an account exactly **one** contact list — not one per SendOps workspace, one per *AWS account*. SendOps uses whatever list your account already has, or creates one named `sendops-contacts` the first time it needs to. Your contacts and your [topics](/audience/topics) both live on it.

That has three consequences worth knowing:

- **Contacts arrive on their own.** SendOps syncs the SES contact list roughly hourly. Anyone already in it — including contacts added to SES outside SendOps entirely — shows up in your Contacts page without you importing anything.
- **Adding a contact in SendOps adds it to SES — but not instantly.** Create one in the dashboard, over the API, or by uploading a CSV, and SendOps stores it straight away, then mirrors it to your SES contact list in the background. AWS caps contact writes at roughly **one per second per account**, so a large import can be finished in SendOps while the AWS console is still catching up. Nothing here waits on that: segments, sends, exports and the Contacts page all read SendOps' own copy. The delay is only visible if you're watching the contact list in the AWS console, or another system reads SES directly.
- **Removing a contact from SES removes it here.** If a contact disappears from the SES contact list, the next sync detaches it from your workspace.


  Because the contact list belongs to the AWS *account*, two SendOps workspaces connected to the **same** AWS account converge on the **same contacts and the same topics**. Your [Lists](/audience/lists) are still your own, so you can share an account and keep your audiences apart — but everyone on the account can *see* the whole contact pool. See [Shared AWS accounts](/aws-setup/shared-accounts).


## What SendOps keeps, and what SES keeps

Not everything about a contact goes to AWS. The split matters when you're reasoning about what a sync can and can't overwrite:

- **Email address and subscription state** — mirrored to the SES contact list.
- **[Attributes](/audience/attributes)** — SendOps only. SES never stores them, and a sync can never clobber them.
- **[Activities](/audience/activities)** — SendOps only.
- **[List](/audience/lists) and [Segment](/audience/segments) membership** — SendOps only. These have no AWS representation at all.

## Browsing contacts

The **Contacts** page is a browser, not a targeting tool. Search by address, and filter by topic, subscription status, global unsubscribe, or whether the address is currently [undeliverable](/reports/undeliverable-list). You can export the filtered set, and — with the manage permission — add a contact, import a CSV, or act on a selection in bulk.



Open a contact to see everything SendOps knows about that one person: their attributes, their topic subscriptions and global unsubscribe state, the Lists they're on, and their recent activity.


  Streaming an [activity](/audience/activities) for an unknown address creates a *stub* contact so the event has somewhere to land. That contact is real and browsable, but it hasn't consented to anything — being in your contacts has never meant being mailable. See [Consent & lifecycle mail](/sending-email/consent-and-lifecycle#membership-is-not-mailability).


## What's next?

- [Lists](/audience/lists) — the groups you actually send to.
- [Segments](/audience/segments) — groups defined by a rule instead of by hand.
- [Topics](/audience/topics) — the consent streams that live on the same SES contact list.
- [Consent & lifecycle mail](/sending-email/consent-and-lifecycle) — what decides whether a contact actually receives a message.
- [Contacts API](https://developers.sendops.dev/api-reference/contacts) — read and write contacts programmatically.