Skip to main content
InstantCampaign checks a campaign before it goes out and keeps watching while it’s being delivered. This page explains what each safeguard does and what to do when one stops a send.

Who never receives a campaign

Every marketing send automatically leaves out:
  • contacts who have unsubscribed, from the list or from all email
  • addresses that bounced or sent a spam complaint
  • contacts still pending double opt-in confirmation
  • contacts whose data has been erased
The audience count in the send wizard already excludes these contacts, so the number you see is the number that gets sent. Transactional send policies follow different rules for unsubscribed contacts.

Pre-send deliverability checks

Before a send starts, and again when a scheduled send is delivered, InstantCampaign checks the domain you’re sending from: Checks can only block on evidence. A check that couldn’t run, or a domain that has never been checked, shows as a warning and doesn’t stop the send. When a send is blocked, you’ll see Blocked by deliverability checks along with the reason. Fix the issue on the Deliverability page, or under Settings → Domain Authentication for DNS problems, then send again.
Warm-up: if a new domain has a warm-up plan, a campaign that’s bigger than today’s allowance sends what the cap allows. The rest waits until the next day (00:00 UTC) and then continues automatically.

Plan readiness and content checks

For campaigns generated with AI, the plan page shows a Ready to send card before you approve. It lists:
  • the deliverability checks above
  • your monthly email allowance compared with what the plan will send
  • content checks for every email in the sequence
The content checks flag a missing subject or one over 60 characters, subjects in all capitals, with repeated punctuation or with typical bulk-mail phrases, an empty or image-only body, no links or more than ten links, and HTML large enough for Gmail to clip. Content checks are warnings only. You can still approve. Approval is blocked only by a failed deliverability check, email 1 having no subject, an audience too large for your remaining monthly allowance (audience size times the number of emails in the plan), an empty audience, or a campaign that isn’t active.

Automatic pause on provider failures

If your email provider rejects five messages in a row while a campaign is being delivered, InstantCampaign pauses the send instead of working through the rest of the audience. A run of rejections usually means a problem on the sending side, such as expired credentials, an unverified sender or a blocked account. Carrying on would only harm your reputation. The paused send shows PAUSED in Send History, together with the reason, for example Paused after 5 consecutive provider failures: …. Fix the cause, usually under Integrations or Settings → Sender Information, then click Resume.

Pause, resume and cancel a send

On the campaign page, each send in Send History has these controls while it’s queued or sending: You need permission to send campaigns to use these controls.

Automatic UTM tagging

Go to Settings → General and turn on Automatic UTM tagging to add utm_source=instantcampaign, utm_medium=email, utm_campaign (the campaign or automation name) and utm_content (the send) to every tracked link. Email traffic then shows up in Google Analytics and similar tools.
  • Links that already have UTM parameters aren’t changed.
  • mailto:, tel:, anchor and unsubscribe links are never rewritten.
  • It applies to campaign and automation sends from the moment you turn it on.
  • In the send wizard, the Tracking step starts switched on and lets you override the values for a single send.
Only workspace owners and admins can change this setting.

Troubleshooting

The automatic pause kicked in. Read the reason on the send row, fix the provider or sender problem, and click Resume. Contacts who already received the email won’t get it again.
The checks run again at delivery time. If the domain’s state changed in between, for example it was added to a blocklist, the send is stopped at that point.
The background worker that delivers sends hasn’t run recently. Queued sends aren’t lost. They go out when the worker runs again.