@Mail Domain Check

Dedicated sender · DNS evidence · warmup

Separate sending domain launch checklist

A new outreach, notification, or product-mail domain needs more than SPF, DKIM, and DMARC records. Prove the exact sending path, start with low-risk recipients, monitor real receiver evidence, and keep rollback ready.

What belongs on the separate domain

Use a separate sending identity when a stream can create reputation risk for the primary domain: outreach, newsletters, product updates, high-volume notifications, experiments, or any flow with changing recipient expectations. Keep password reset, security alerts, billing, and account-critical mail on a path whose reputation and failure handling are protected.

Do not launch by copying a DNS recipe from another project. First name the exact business stream, visible From: domain, provider, envelope domain, DKIM signing domain, DKIM selector, sending IP ownership, bounce path, complaint path, and rollback owner.

A dedicated domain protects only when traffic is actually separated. Sharing the same IP pool, DKIM domain, Return-Path, content, list source, or complaint handling can still couple reputation.

1. Publish the minimum public controls

  1. SPF: publish exactly one SPF record for the envelope or Return-Path domain used by the provider. Count include and redirect chains before production traffic.
  2. DKIM: enable provider signing for the visible sending domain or an aligned subdomain, then verify the real d= and s= values from a delivered message.
  3. DMARC: start with a valid record and aggregate reporting. p=none is acceptable while collecting evidence, but it is not an enforcement endpoint.
  4. PTR: verify every actual outbound IP has reverse DNS and forward-confirmed A or AAAA records. Domain-only DNS checks cannot prove this.
  5. TLS and message format: send through a path that supports TLS and produces valid RFC 5322 headers, including a stable Message-ID.

The free scanner can check the visible From domain's public MX, SPF, DKIM selector, DMARC, MTA-STS, TLS-RPT, CAA, and optional sending-IP DNS. It does not require mailbox access, recipient addresses, DNS credentials, provider tokens, or a wallet connection.

2. Prove DMARC alignment with receiver evidence

Provider setup screens often say that SPF and DKIM are configured before the first real message proves alignment. Send a controlled message to test inboxes, download the original message source, and read the receiver's Authentication-Results. Record which passing identity aligns with the visible From domain.

SPF pass
Useful only for DMARC when the authenticated envelope identity aligns with the visible From domain.
DKIM pass
Useful only for DMARC when the signing d= domain aligns with the visible From domain.
DMARC pass
Requires at least one aligned SPF or DKIM pass. A provider-side "delivered" event does not prove inbox placement.
Forwarding path
May break SPF; preserve ARC and DKIM evidence separately instead of assuming the original direct-delivery result still applies.

Use the browser-local header analyzer for test headers that you are allowed to inspect. Do not paste real customer addresses, codes, links, credentials, tokens, or private message bodies into public systems.

3. Warm up from evidence, not a fixed magic number

Start with low volume to recipients who expect the mail and are likely to engage. Increase gradually only while SMTP responses, bounces, complaint feedback, authentication, and domain or IP reputation stay healthy. If deferrals or bounces rise, pause the ramp, reduce volume, and fix the first failed boundary before adding more recipients.

  • Keep one schedule per domain and per IP or provider pool. Shared IP reputation and dedicated IP reputation behave differently.
  • Do not mix message categories during warmup. A receipt, a security alert, and a promotional message should not train receivers as one stream.
  • Keep cadence consistent. Sudden bursts and day-to-day swings are stronger warning signs than a slower launch.
  • Track retries separately from new mail. Replaying a failed queue can create a hidden volume spike.
  • Document the decision rule for pausing: for example, authentication failure, SMTP 4xx rate, hard bounce rate, complaint signal, block-list event, or reputation drop.

4. Separate acceptance from inbox placement

SMTP acceptance, provider delivered events, and a green DNS setup screen are not inbox placement. For each target receiver family, preserve at least one controlled test that distinguishes submission, provider processing, recipient-server acceptance, spam-folder placement, inbox placement, link safety scanning, and user-visible completion.

For Gmail-bound traffic, monitor Postmaster Tools once volume and verification are sufficient. For Yahoo-bound traffic, follow Sender Hub requirements, including authentication, complaints, forward and reverse DNS, list-unsubscribe for bulk senders, and timely unsubscribe handling. For Microsoft consumer mail, preserve exact SMTP or NDR responses and the sending IP that received the rejection.

5. Wire bounces and complaints before ramping

  1. Use a stable envelope sender or provider message ID so every deferred, bounced, suppressed, or complained message maps back to one original send.
  2. Classify synchronous SMTP failures separately from asynchronous DSNs and provider webhooks. A 250 response can still be followed by a later bounce.
  3. Process hard bounces, inactive recipients, and complaints before the next ramp step. Warmup volume built on invalid recipients trains the wrong signal.
  4. Keep unsubscribe headers and body links working for marketing or subscribed mail. Handle opt-outs quickly and do not require login just to unsubscribe.
  5. Keep support, engineering, and provider owners able to read the same bounded evidence packet without exposing message secrets.

Use the SMTP 250 and async-bounce model when a provider accepted a submission but a recipient later rejected or suppressed it.

6. Move DMARC enforcement only after a full cycle

Keep aggregate reports enabled and reconcile every recurring source with the sender inventory. Move from p=none to quarantine or reject only after normal, low-frequency, failover, and incident paths have aligned receiver evidence and a tested rollback path.

Do not rely on the historic DMARC pct tag for staged rollout; RFC 9989 removed it because receiver behavior was inconsistent. If a partial rollout is needed, isolate streams by controlled subdomain or provider path and verify receiver behavior directly.

Preflight checklist

  • Dedicated domain, Return-Path, DKIM identity, provider, and owner are named.
  • SPF, DKIM, DMARC, PTR, TLS, unsubscribe, bounce, and complaint handling are verified before the first campaign or production notification batch.
  • At least one real receiver header proves aligned DMARC for each message stream.
  • Warmup pause criteria and rollback owners are written down.
  • DNS checks, provider events, receiver acceptance, inbox placement, and user-visible completion are not treated as the same metric.

Primary references