Docs

Domain reputation monitoring for DNS, blocklists, and provider drift.

Monitor sending domains for SPF, DKIM, DMARC, MX, PTR, DNSBL, transport security, Google Postmaster, Microsoft SNDS, and reputation-risk changes.

Monitor a domain Run deliverability test

What domain monitoring watches

Domain monitoring is built for the slow failures that rarely announce themselves: DNS edits, provider migrations, old SPF includes, missing DKIM selectors, and blocklist changes.

Authentication health: SPF, DKIM, DMARC, BIMI, policy strength, selectors.
Infrastructure health: MX, PTR, DNSBL, domain age, MTA-STS, TLS-RPT, MX TLS.
Provider reputation: optional read-only Google Postmaster snapshots, compliance status, and Gmail-side reputation signals.
Ownership verification with a TXT token before scans are attached to an account.

Domain verification and DKIM selectors

A monitored domain belongs to an account only after the owner publishes the generated TXT token. The optional selector field tells WillItInbox which custom DKIM records to inspect in addition to common provider selectors.

Add the generated TXT record exactly as shown by WillItInbox, then run verification.
For DKIM selectors, enter values such as selector1, selector2, google, or the selector shown by your ESP.
For SMTP2GO and similar ESPs, find the selector in the provider's DKIM or sender-domain DNS setup screen and paste only the selector label, not the full ._domainkey hostname.
Leave selectors blank when you do not know them; WillItInbox still checks common selectors and other domain health signals.

Provider reputation with Google Postmaster

Google Postmaster evidence appears inside domain monitoring after a user connects Google, WillItInbox lists verified Postmaster domains, and a provider domain is linked to a monitored WillItInbox domain.

WillItInbox uses Google's stable v2 Postmaster API for domain list, stats, and compliance status.
Stats can be empty when Google has not exposed enough Gmail traffic for that domain yet.
Per-domain unavailable data is shown as provider evidence, not as a whole-account failure.
WillItInbox reads evidence only; it does not warm up, whitelist, repair, simulate engagement, or guarantee inbox placement.

Who should use it

Teams with multiple ESPs, CRMs, support tools, billing systems, or client domains need a periodic view of whether each sending domain is still healthy.

SaaS teams

Protect signup, password reset, lifecycle, billing, and notification domains.

Agencies

Monitor client domains after implementation and show ongoing health.

IT teams

Catch DNS and provider drift before mail flow breaks.

Reputation owner

Monitor the signals that explain why receivers start blocking mail

A domain can look healthy during setup and still drift later: an ESP changes a DKIM selector, a stale SPF include remains authorized, a shared IP hits a DNSBL, or Gmail and Outlook start showing reputation warnings. WillItInbox treats domain monitoring as the operating surface for those slow reputation failures.

DNSBL status

Track blocklist evidence as a risk signal, then confirm the exact IP, list operator, and likely cause before delisting.

Provider evidence

Use Google Postmaster and Microsoft SNDS as provider-specific evidence, not as universal placement guarantees.

DNS and auth drift

Watch SPF, DKIM, DMARC, MX, PTR, MTA-STS, and TLS-RPT after ESP, DNS, or routing changes.

Reputation signal matrix

Separate one bad lookup from a pattern worth escalating

The practical question is not whether one signal is imperfect. It is whether multiple independent surfaces point to the same failure class.

Signal	What it can indicate	Next action
DNSBL listing	IP abuse, compromised sender, bad shared pool, or old listing state.	Confirm on the operator site, fix cause, then request delisting.
Postmaster reputation drop	Gmail-side complaints, bad engagement, auth failures, or volume shock.	Inspect spam rate, auth dashboard, compliance, and recent campaigns.
SNDS YELLOW or RED	Outlook IP reputation, complaints, trap hits, or HELO/rDNS mismatch.	Pause risky volume and compare SNDS with list and infrastructure evidence.
PTR or HELO mismatch	Self-hosted or dedicated-IP routing identity problem.	Fix forward-confirmed rDNS and retest the exact sender path.
DMARC source drift	Unknown SaaS sender, ESP migration, spoofing, or alignment break.	Label the source, fix alignment, and monitor before enforcement changes.

Incident workflow

Use reputation evidence to decide whether to pause, fix, or monitor

Reputation incidents need a short loop: identify the impacted stream, collect evidence, fix the root cause, retest, and watch recovery. Do not request delisting or resume volume until the cause is addressed.

Step	Evidence to collect	WillItInbox path
Baseline	Domain scan, DNSBL state, SPF/DKIM/DMARC, PTR, provider dashboard state.	/docs/domain-monitoring
Message check	Real-message report for authentication, routing, headers, content, and links.	/tools/email-deliverability-tester
Sender inventory	Known and unknown DMARC sources, aligned volume, and failed streams.	/tools/dmarc-monitoring
List quality	Invalid, risky, role, disposable, unknown, and catch-all recipient evidence.	/tools/email-validator

Ongoing risk

Deliverability breaks after launch too

DNS records drift, providers rotate infrastructure, new SaaS tools start sending mail, and old senders remain in SPF longer than anyone remembers. Monitoring turns those changes into visible events before they become support tickets or provider blocks.

Domain monitoring

Track SPF, DKIM, DMARC, MX, TLS, PTR, blocklist drift, ramp guidance, and provider reputation evidence in /domains.

DMARC visibility

Use /dmarc to label sources, find unknown senders, and move toward enforcement safely.

Placement diagnostics

Use /placement for diagnostic seed testing when placement needs a sample beyond technical scoring.

Review rhythm

What to review weekly or monthly

Review domain scans, DMARC source labels, failed alignment volume, unknown senders, blocklist signals, provider reputation snapshots, compliance status, and recent deliverability reports.

Investigate new unknown DMARC sources before changing enforcement.
Connect Google Postmaster when the domain has enough Gmail traffic to expose useful provider data.
Retest templates after sender, link, or header changes.
Use webhooks when monitoring events need to reach internal systems.

Plan model

Pricing uses clear usage quotas plus feature access

WillItInbox plans are easiest to understand when the metered usage stays simple: deliverability tests, email validations, API calls, and bulk CSV rows. Monitoring, webhooks, workspaces, branded reports, placement diagnostics, and trust-layer APIs are shown as feature access until those surfaces need explicit capacity counters.

Tests measure generated deliverability reports and placement diagnostics.
Validations measure single, batch, API, and bulk recipient checks.
API calls cover authenticated automation, including trust-layer ingestion endpoints.
Bulk rows cap CSV validation job size and recurring list-hygiene volume.

Newer surfaces

Feature pages carry the detail pricing should not

The pricing page should stay scannable. The docs and feature pages should explain what the newer surfaces do, what evidence they produce, and where they fit in a sender's workflow.

DMARC intelligence

The DMARC docs explain DMARC aggregate/RUF/TLS-RPT separation, mailbox ingestion, source labels, forensic-report handling, and alerts.

Provider reputation

Connect Google Postmaster for read-only domain evidence, compliance status, and latest Gmail-side reputation snapshots.

Inbox placement diagnostics

Diagnostic seed tests, schedules, user-authorized SMTP sends, and provider heatmaps are documented as evidence, not a placement guarantee.

Trust-layer APIs

DSN bounce ingestion, ARF complaint ingestion, and suppression-aware validation are API-backed workflows for operational hygiene.

Deliverability tester

Send the exact message and separate reputation risk from authentication, content, and routing failures.

DMARC monitoring

Find legitimate and unknown senders before policy changes amplify a reputation issue.

Pricing

Compare monitoring, report, validation, and workspace limits.

DMARC Rollout None To Reject guide

Read the supporting guide for practical context around dmarc monitoring and sender authentication.

Authentication diagnosis example

See how SPF, DKIM, DMARC, BIMI, MTA-STS, and TLS-RPT evidence becomes a remediation checklist.

DMARC monitoring docs

Connect aggregate reports, source attribution, policy status, and alerts to the sender authentication dashboard.

FAQ

Can domain monitoring guarantee inbox placement?

No. It surfaces DNS, authentication, transport, blocklist, and provider evidence so teams can investigate risk. Inbox placement also depends on engagement, recipient history, provider behavior, and campaign context.

Should every blocklist hit trigger an emergency?

No. Confirm the list, impacted IP or domain, receiver relevance, first-seen time, and cause. Spamhaus-class listings are urgent; obscure one-off hits may be informational unless a pattern appears.

How often should domains be monitored?

Critical production domains should be checked at least weekly and after any ESP, DNS, or security change. High-volume senders often benefit from daily checks.

Does Google Postmaster data always appear after connecting?

No. Google can return empty or unavailable domain stats until the verified domain has enough Gmail traffic. WillItInbox treats that as a no-data state rather than a deliverability guarantee or failure.

Does every newer feature have its own public rate limit?

No. WillItInbox exposes four clear usage quotas today: tests, validations, API calls, and bulk rows. Other workflows are handled as feature access or beta access unless a concrete capacity limit is added later.

Why keep placement and trust-layer language careful?

Placement tests provide diagnostic seed evidence, and trust-layer APIs provide operational ingestion and suppression evidence. Neither should be described as a guarantee of inbox placement or compliance certification.