> ## Documentation Index
> Fetch the complete documentation index at: https://docs.politicalcomms.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Campaigns and Deliverability
> Sender identities, the campaign builder, test sends, the warm-up ramp, deliverability breakers, frequency caps, DMARC progression, tracking, and reporting.
## Sender identities
A verified domain cannot send on its own. The thing that sends is a **sender
identity**: the From address, plus the compliance information that goes in every
footer. Create them under **Email > Senders**.
| Field | What it is |
| -------------------- | --------------------------------------------------------------------------------------- |
| **From name** | The display name recipients see, such as the candidate or committee name. |
| **From address** | The mailbox part, on one of your active sending domains. |
| **Reply-to** | Where replies land. This is a mailbox you already own and read; there is no inbox here. |
| **Physical address** | The postal address CAN-SPAM requires in every message. |
| **Disclaimer** | The paid-for-by attribution, plus whether the message is authorized by the candidate. |
An identity activates only when **both** conditions hold: its domain is active,
and the compliance fields are filled in. Try to activate one on a domain that is
still verifying and you get a plain error saying so rather than a silent
failure.
If you later edit an active identity in a way that removes a required address or
disclaimer, the identity is **paused rather than left sending non-compliant
mail**. The save succeeds and sending stops, which is the safe direction: a
paused identity is a problem you notice today, while non-compliant mail is one
you find out about from a regulator.
### Each sender is isolated
Every sender identity gets its own isolated reputation on our sending
infrastructure.
Practically, this means a committee that sends both a high-volume fundraising
program and a careful volunteer-coordination program can keep them apart: if the
fundraising sender runs into trouble, the volunteer sender is not dragged down
with it.
It is the reason to create a second identity rather than reuse one, whenever two
programs have genuinely different audiences or risk profiles.
### When sending is paused for you
Our sending infrastructure can disable an individual sender on its own
judgment, usually for a complaint rate it considers unacceptable. When that
happens the platform does not let campaigns keep failing message by message.
**Every in-flight campaign on that identity is paused automatically**, the
reason is recorded on the identity, and your organization is notified.
Because identities are isolated, this stops at the one sender. Your other
identities keep sending.
## Building a campaign
A campaign is one message, from one sender identity, to one or more lists. Pick
the audience, write the subject and body, and the platform deduplicates
recipients across lists and removes anyone suppressed before it counts your
audience.
**Recipient policy** decides which subscribed contacts on those lists actually
get the send. `max_reach` (the default) sends to everyone subscribed.
`max_deliverability` narrows the send to contacts whose current validation
verdict is deliverable, skipping anyone who has never been validated. This is
`recipient_policy` on the campaign, settable on create or update.
The builder is organized in five groups:
| Group | What you set |
| --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| **Sender** | Which sender identity sends it. |
| **Recipients** | The lists to send to, and any suppression lists to hold out. |
| **Content** | The campaign name, a saved template, the subject, and the preview text. |
| **Delivery** | Time zone, the send window (send after, stop by), pacing, how long to keep retrying, the schedule, and whether the campaign requires approval. |
| **Attribution** | Refcode, source code, link domain, whether to append UTM parameters, and whether this is a re-permission campaign. |
**The send window and pacing** are worth setting deliberately. A window keeps a
large send inside civilized hours in the recipient's time zone rather than
arriving at 3 AM, and pacing spreads it out instead of dropping the whole thing
on a mailbox provider in one burst, which is itself a spam signal.
**Templates are built separately**, under **Email > Templates**, and the builder
picks from your saved ones. That is where the document editor, **Import HTML**,
and **Draft with Lincoln** live. See [Templates](#templates) below.
**Link domain.** Every link in a campaign is rewritten to a tracked URL, the
open pixel is added for you, and pasted bare URLs become links too, so click
metrics are never optional. Choose which host those URLs use under **Link
domain** in the builder: any active tracking domain the organization owns or
shares (the `links.` host created with your sending domain under Admin >
Domains), or the platform host. Branding the host keeps link reputation with
your domain and matches what recipients see. If the chosen domain is not active
yet the checklist says so and the send falls back to the platform host.
### No A/B testing, and what to do instead
There is no A/B split test. One campaign is one message to one audience.
The supported equivalent is **Duplicate campaign** plus **Compare campaigns**:
duplicate a campaign, change the one thing you want to test, send both to
comparable segments, and then compare up to four campaigns side by side on the
report page. It takes one more step than a split test and gives you a result you
can read a week later, rather than a winner picked automatically on an hour of
early opens.
## Templates
Templates live under **Email > Templates** and are reusable across campaigns.
There are three ways to make one:
* **The document editor.** Write the email like a document. Type `/` for a menu
of blocks (text, headings, lists, buttons, donate buttons, images, columns,
sections, dividers, spacers, quotes, footer text, a compliance footer, and a
raw HTML block), and `@` to insert a merge tag as an editable pill. Paste from
Google Docs or Notion and the formatting carries over. A Design rail sets the
background, card color, font, and heading, text, link, and button colors, and
a Checks panel shows live compliance checks, server lint, and the size against
Gmail's 102 KB clip, alongside a desktop and mobile preview.
* **Import HTML.** Paste HTML or upload a file, for a design your team already
has or one exported from another tool. An HTML template is edited as text,
and a document template can be converted to one, one way, with confirmation.
* **Draft with Lincoln.** Describe the email and the platform's AI agent writes
it, returning editable blocks in the document editor. See below.
Every save returns a **lint** result. Read it: a template with lint errors will
save, but a campaign built on it will not schedule.
## Draft with Lincoln
Lincoln, the AI agent already drafting your text replies, writes email designs
too. The **Draft with Lincoln** button sits in the template editor's toolbar and
on the templates page. Describe the email you want, optionally pick up to six
images and your brand colors, and Lincoln returns a finished design: a subject,
a preheader, and editable blocks that load straight into the document editor
for you to edit.
Four things worth knowing before you use it:
* **It costs \$3.00 per draft**, at your organization's own price, and you are
charged **only when a draft comes back ready**. A draft that fails, or that
comes back invalid, is never billed.
* **It is not instant.** Generation runs in the background and usually finishes
in under two minutes. Leaving the page does not lose the draft.
* **Images must already be in your email library.** Add them on the Upload tab
of the image picker, or at **Assets > File Uploads** with the **Email images**
kind. Picking a texting image copies it into the email library for you.
* **It replaces the document.** If the template already has content, you are
asked to confirm before the draft overwrites it.
Every draft is a starting point, not a send. It lands in the editor, and the
same checklist, test send, and approval rules below apply to whatever you do
with it.
### Drafting in the dashboard
Drafting runs in the dashboard, not over the API. It is paid, asynchronous, and
non-deterministic, so it stays a product feature rather than a versioned API
contract: **Email > Templates > Draft with Lincoln**.
If the wallet cannot cover the draft, generation does not start. If the balance
runs out mid-generation the draft finishes failed and is not billed.
## The checklist
A campaign will not schedule until its checklist is clear. The single-campaign
API read returns a `blocked` array naming exactly what is unresolved, so an
integration never has to guess:
| Blocker | What to fix |
| ------------------------- | ------------------------------------------------------------------------------------------------------------ |
| `sender` | No sender identity chosen, or the one chosen is not active. |
| `sender_compliance` | The identity is missing its physical address or disclaimer. |
| `lists` | No lists selected. |
| `list_validated_` | An acquired list has not completed validation. |
| `sendable` | Zero recipients remain after deduplication and suppression. |
| `subject` | The subject line is empty. |
| `body` | The message body is empty. |
| `lint` | The content has lint errors. Warnings do not block. |
| `test_send` | Every campaign requires a successful test send before it can be submitted or scheduled, and none is on file. |
| `balance` | The estimated cost exceeds your available wallet balance. |
Some items appear as warnings rather than blockers, including sunset holds,
frequency-cap holds, and warm-up ceilings. They tell you the send will reach
fewer people than the list total, without stopping it.
## Test sends
Send a real message to up to 10 addresses before committing. Test sends use
sample merge data so you see what a recipient sees.
**Every campaign requires a successful test send before it can be submitted or
scheduled.** There is no setting to turn this off.
If you edit a campaign after its test, the test is invalidated and you need to
send another one before you can submit or schedule. "Editing," for this
purpose, means changing the body or content, the subject or preheader, the
sender identity, the lists, the suppression lists, or the template. Changing
the name, schedule, timezone, send window, pacing, or TTL does not invalidate
the test.
Two more things to know: test sends are **real sends and are billed** at the
normal per-recipient rate, and they are **excluded from campaign statistics and
never fire webhooks**, because they are your traffic rather than your
audience's. They are also exempt from the warm-up ceiling, so a test never
consumes your daily allowance.
## Approval
A campaign can require a sign-off before it sends. Turn on **Require approval
before sending** in the campaign builder, which sets `require_approval` on the
campaign (`false` by default). This is a per-campaign choice, not an
organization-wide setting: some campaigns can require approval while others
send as soon as their test is clear.
When it's on, the campaign needs both a current test send and an approval
before it can be submitted or scheduled. Editing the campaign after approval
invalidates the approval the same way it invalidates the test, using the same
definition of "editing" above.
## Warm-up
A brand-new domain that sends 200,000 messages on its first day gets filtered,
not delivered. Mailbox providers build reputation from a sending history, and no
history plus sudden volume looks exactly like a compromised account.
New domains ramp through a daily ceiling:
| Step | Daily ceiling |
| ---- | ------------- |
| 1 | 500 |
| 2 | 1,000 |
| 3 | 2,500 |
| 4 | 5,000 |
| 5 | 10,000 |
| 6 | 25,000 |
| 7 | 50,000 |
| 8 | 100,000 |
| 9 | 250,000 |
| 10 | No ceiling |
The ramp advances one step per **sending** day, **but only if yesterday went
well**. The step-up is checked each night against your own numbers, and it is
held if the previous day's bounce rate was 2% or higher or the complaint rate
was 0.05% or higher. You are notified when a step is held. This is the point of
a ramp: a schedule that climbs regardless of results is a countdown, not a
warm-up.
A day on which the domain sent nothing does not count in either direction: it
neither advances the ramp nor holds it. Reputation is built from a sending
history, so a day with no history is no evidence. In practice this means the ten
steps are ten days of sending, not ten days on the calendar: a domain that mails
twice a week takes about five weeks to reach the top step.
Two further adjustments:
* **Acquired lists ramp on half steps.** Every ceiling above is halved.
* **A new identity on an already-warm domain starts at step 3** (2,500) rather
than at the beginning, because the reputation belongs to the domain.
A campaign larger than today's ceiling is not rejected. It rolls over: today's
ceiling goes out today, the remainder follows on subsequent days as the ramp
climbs. The builder shows today's ceiling, how much of it you have used, the
full ramp schedule, and the estimated number of days the send will take, before
you schedule it.
## Deliverability breakers
If a send is going badly, continuing makes it worse. Two breakers pause a
campaign automatically:
| Breaker | Threshold |
| -------------- | --------- |
| Bounce rate | **3%** |
| Complaint rate | **0.08%** |
Both are measured cumulatively across the campaign's life, and neither is judged
until at least **500 messages** have been sent, so a handful of early bounces on
a small send cannot trip them. Rates are re-evaluated on a rolling sweep. For
reference, our sending infrastructure begins suspending senders near 5% bounce
and 0.1% complaint; these thresholds sit deliberately below that.
When a breaker trips, the campaign pauses and `pause_reason` records which one.
Fix the underlying problem, which is usually list quality, then resume.
**A campaign that has been auto-paused twice cannot be resumed over the API.**
It returns `409 EMAIL_CAMPAIGN_RESUME_REQUIRES_SUPPORT` and needs a person to
look at it. There is no override, because the breaker exists precisely to stop an
integration retrying through a real deliverability problem.
For what happens to the individual addresses behind those rates, see
[Bounces, complaints, and suppressions](/help/email/bounces-complaints-and-suppressions).
## Frequency cap
An optional organization-level cap limits how often any one person is mailed
**across all your campaigns**, with separate 24-hour and 7-day limits. It is
**off by default**; turning it on suggests one message per 24 hours and three
per 7 days, which you can change.
When enabled, recipients already over the limit are **held out of the send**
rather than the send being rejected, and the campaign reports how many were
held. It is the cheapest protection against the most common self-inflicted
deliverability wound: three committees, one shared list, one bad week.
A [re-permission campaign](/help/email/bounces-complaints-and-suppressions#winning-people-back-before-the-drop)
is exempt, since a message asking whether someone still wants your mail is
useless if the frequency cap stops it from arriving.
## Sender requirements scorecard
Gmail and Yahoo publish bulk-sender requirements. The scorecard, on the **sender
identity** page, checks your domain against them continuously so you find out
before a mailbox provider tells you:
* SPF passes, DKIM signs every message, and both pass together
* A DMARC policy is published, and messages align with it
* Messages are properly formatted
* Valid forward and reverse DNS, and mail sent over TLS
* Spam complaints under 0.10%
* Bounce rate under 2%
* A physical mailing address is present
* Acquired lists have been validated within the last 90 days
Where [Google Postmaster Tools](/help/email/google-postmaster-tools) is verified
for your domain, Gmail's own verdicts take precedence over our measurements for
the categories it covers, since Gmail's opinion of your mail is the one that
decides where it lands.
## DMARC progression
DMARC tells mailbox providers what to do with mail that fails authentication.
Starting at enforcement would bounce your own legitimate mail from any sending
service you had forgotten about, so the policy moves in stages:
`p=none` → `p=quarantine` at 10% → `p=quarantine` at 100% → `p=reject`
Leaving `p=none` requires all of the following over a 30-day window:
* **98%** or better aligned pass rate
* At least **1,000** reported messages
* At least **2** independent reporting sources
Every later step additionally requires **14 consecutive clean days** at the
current setting. If a new unaligned sending source appears at 1% or more of your
volume, the policy backs off one step rather than dropping straight to `none`.
We generate the record; you publish it. If your root domain already has a DMARC
record we do not manage, we will not stage an edit to it and the API returns
`DMARC_ROOT_DOMAIN_NOT_MANAGED`. Make that change yourself.
## Dedicated sending
Most senders should use shared sending, where reputation is pooled and warm from
day one. A dedicated managed sending pool is worth it only at sustained high
volume, where your own reputation is an asset rather than a liability.
The add-on is **\$15.00 per month**, and it needs **45 days of warm-up** before it
carries full volume. Plan it well ahead of an election deadline, not during one.
Two conditions you may hit: `POOL_ALREADY_ACTIVE` means your organization already
has one and the request did nothing, and `POOL_CAPACITY_EXHAUSTED` means the
capacity cap has been reached and you should contact support.
## Tracking
Tracking is not optional and does not need configuring. On every send:
* **Every link is rewritten** to a tracked URL on your link domain. That
includes bare URLs you pasted into the text without making them links.
* **An open pixel is added**, an invisible one-pixel image that loads when the
message is displayed.
* **A view-in-browser link** is available, which renders the message as a web
page for recipients whose client mangles it. The browser version does not
count as an open, though its links are still tracked.
### Opens are approximate
Take open rates as a trend, not a count. Two things distort them in opposite
directions, and neither is fixable by any sender:
* **Apple Mail Privacy Protection loads the pixel for every message**, whether
or not the recipient looked at it, which inflates opens.
* **Recipients who never load images never register an open**, even after
reading and acting on the message, which deflates them.
The platform filters what it can identify: known privacy proxies including
Apple's and Gmail's image proxy, known bots, prefetching clients, and opens that
arrive implausibly fast after the send. Filtered opens are **marked, not
deleted**, so the figures separate machine traffic from human traffic rather
than quietly discarding data.
**Clicks are the number to trust.** A click is a deliberate act that no proxy
performs on the recipient's behalf. Where open rate and click rate disagree,
believe the click rate, and use **click-to-open** with the same caution you would
apply to any ratio with a soft denominator.
## Reporting
The campaign report opens on tiles covering **sent, delivered, opened, clicked,
click-to-open, bounced, complaints, unsubscribed, and cost**, with the
corresponding rates. Below them:
| Section | What it shows |
| ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| **Hourly chart** | Sends and engagement over time, which is how you see a send being throttled or a spike of complaints. |
| **ISP breakdown** | Performance split by mailbox provider. Gmail behaving very differently from everyone else is the classic early warning. |
| **Device breakdown** | Derived from clicks, so it reflects people who acted rather than everyone who was mailed. |
| **Link clicks** | Per-link click totals, so you can see which call to action actually worked. |
| **Bounce and error reasons** | Grouped by type and reason, which is where an authentication problem or a blocklisting shows up as a pattern rather than a mystery. |
| **Recipients** | A per-recipient drill-down, filterable by status, for answering "did this specific person get it". |
**CSV export** builds the full recipient-level file in the background and gives
you a download link valid for seven days. Figures on the page are cached for 60
seconds.
Test sends and seed addresses are excluded from every number, though they are
still billed, because they are your traffic rather than your audience's.
**Compare campaigns** puts up to four campaigns side by side, which is the
supported way to evaluate a change in subject line, sender, or creative.