Deliverability Guardrails

Launch clean. Stay clean.

ForgeSend checks DNS, inbox readiness, list quality, and sending capacity before every campaign launch. If a guardrail fails, the campaign is blocked — not warned. None of the platforms audited on the ForgeSend compare hub show an equivalent mandatory launch-blocking checklist.

See it in action

Campaign PreflightBLOCKED
✓SPF record foundpass
✓DKIM signature configuredpass
✗DMARC policy missingfail
✓Inbox warmed (14 days)pass
✓List verified (96.1%)pass
✗Bounce rate unsafe (8.4%)fail
2 blockers must be resolved before launch
Domain DNS Status
DomainSPFDKIMDMARC
outreach.acmecorp.io
hello.pivotal.dev
send.meridian.co
Checked live before every campaign

How it works

01

Live DNS probing

Before any campaign starts, ForgeSend queries your sending domain’s DNS records live. SPF, DKIM, DMARC, and MX are all checked. Results come back in seconds. Missing or misconfigured records become a hard blocker — not an advisory warning.

SPFv=spf1 include:_spf.google.com ~allpass
DKIMselector1._domainkey → foundpass
DMARCNo DMARC policy foundfail
MX10 aspmx.l.google.compass
02

Pre-send guardrail checklist

A full readiness sweep runs automatically the moment you launch a campaign, across five areas: DNS records, inbox readiness, list quality, campaign content and safety, and sending capacity. It scales with your setup — every sending domain and every connected inbox is checked individually, so a larger workspace gets a deeper sweep. That covers SPF, DKIM, DMARC and MX, token health and capacity, list verification and duplicate detection, unsubscribe language, and semantic content checks: repeated pitch detection compares non-adjacent sequence steps using real embeddings, and spintax variant similarity compares each spintax block's own options against each other. Every check reports PASS, WARNING, or FAIL, and your campaign goes live the moment the FAIL items are resolved.

✓DNS configurationpass
✓Inbox capacitypass
!List verificationwarn
✗Token healthfail
03

Backend launch enforcement

The campaign BLOCKED verdict is enforced server-side, not just in the UI. A POST to /sending/campaigns/:id/start returns 403 if any guardrail check is failing. There is no way to bypass the checklist by calling the API directly — the backend evaluates the preflight independently before starting the scheduler.

POST /sending/campaigns/start
HTTP 403 Forbidden
{ "error": "Campaign is BLOCKED. Resolve all failing guardrail checks." }
04

Inbox health monitoring

ForgeSend tracks send failures per inbox in real time. If the recent failure rate spikes above the safe threshold, the inbox is automatically flagged as ERROR and removed from the rotation. Pending send jobs for that inbox are skipped. The scheduler checks this before dispatching every batch.

outreach-02 rested automatically — failure rate above 5%
0
DNS checks per domain
MX, SPF, DKIM, DMARC — every time
0
Guardrail areas checked before launch
DNS records, inbox readiness, list quality, campaign content, sending capacity
0
Campaigns launched with blockers
Backend enforcement, not just a UI warning

Common questions

Which DNS records does ForgeSend check?

SPF, DKIM, DMARC, and MX. All four are checked live against DNS on every preflight request. Results are not cached — you always see the current state of your domain.

What happens when a campaign is BLOCKED?

The campaign cannot be started. The backend returns 403. The UI surfaces the specific failing checks with suggested fix actions. Once all failing checks are resolved, the campaign moves to READY and can be launched.

Can I override a BLOCKED verdict?

No. The enforcement is backend-side. There is no bypass flag or override mechanism. This is intentional — the guardrail exists to prevent domain burns, not to provide a warning you can click past.

What triggers an inbox to be auto-paused?

Two layers look after every inbox, and both run on their own. The first watches the failure rate across an inbox's recent sending history: once that rate climbs past 5%, ForgeSend rests the inbox automatically and routes new sends elsewhere, so your domain reputation stays protected the moment it matters. The second is a live 0–100 health score per inbox, starting at 100 and moving with real sending performance and capacity — inboxes at 70 and above keep picking up new leads, and any inbox below that rests until its score recovers. Together they mean an inbox that needs a breather takes one early, and a healthy one keeps sending at full speed.

Does deliverability checking work for all inbox types?

DNS checks run against the sending domain for all inbox types — Gmail OAuth, Microsoft OAuth, and SMTP/IMAP. Inbox warmup and health checks apply per-inbox regardless of provider.

Stop burning domains. Start clean.

Pre-send guardrails. Live DNS checks. Backend enforcement. All included.