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.** Create one in the dashboard, over the API, or by uploading a CSV, and SendOps writes it to your SES contact list as part of the same operation.
- **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.