Deliverability

How deliverability checks work

External probes that mirror what receiving mail servers see: MX, SMTP handshakes, ports, DNS auth records, and TLS.

Not enabled by default. Deliverability monitoring is opt-in per asset. Open the asset → Deliverability tab → Start monitoring. Your plan must include deliverability (SMTP monitoring).

Why enable deliverability?

Blacklists tell you if you are listed. Deliverability tells you if your mail infrastructure is configured correctly. That covers MX records, SMTP responses, SPF/DKIM/DMARC alignment, and TLS negotiation before recipients reject or spam-folder your messages.

What we check (domains)

Each deliverability run performs real network probes from SenderSignal infrastructure (not simulated):

1. MX (Mail Exchange)

  • DNS lookup for MX records and priority order
  • Reachability of each MX host (A/AAAA resolution)
  • Identification of mailbox provider patterns (Google, Microsoft, custom)

2. SMTP handshake

  • TCP connection to standard mail ports where reachable
  • Port 25: inbound SMTP (may be blocked by some providers from external probes; we note probe-restricted hosts)
  • Port 587: submission with STARTTLS
  • Port 465: SMTPS (implicit TLS) where advertised
  • EHLO/HELO banner capture, STARTTLS upgrade, AUTH capability discovery
  • Connection timeouts are configurable in monitor rules for slow hosts

3. Transport / TLS

  • TLS version negotiated (e.g. TLS 1.2, TLS 1.3)
  • Cipher suite (e.g. TLS_AES_256_GCM_SHA384)
  • Certificate validity where TLS is offered

4. DNS authentication records

  • SPF: TXT at root; terminal mechanism (-all, ~all, ?all) and include chain depth
  • DMARC: _dmarc TXT; policy (p=none|quarantine|reject), alignment mode, reporting addresses
  • DKIM: probe common selectors (and custom selectors from monitor rules); fetch public key, key length, algorithm
  • BIMI / MTA-STS / TLS-RPT: advanced signals when published

5. Inbound mail flow simulation

  • Where ports allow, validate SMTP conversation through MAIL FROM / RCPT TO stages
  • Detect open relay misconfigurations and greeting anomalies

6. Blacklist cross-check

Deliverability runs incorporate recent blacklist context for the domain's sending path so the score reflects both infrastructure and listing state.

What we check (IP assets)

IP deliverability monitors focus on sending-IP identity:

  • Reverse DNS (PTR) and forward-confirmed reverse DNS (FCrDNS)
  • SMTP banner vs PTR hostname consistency (HELO identity)
  • TLS on submission ports
  • DNSBL status for the IP
  • Provider detection (ESP/shared pool vs dedicated)

See Domain & IP identity for detail.

Scan lifecycle in the UI

  1. Click Start monitoring: first run queues immediately.
  2. UI shows Syncing… / probing state with live timer.
  3. Results populate MX, SMTP, Transport, SPF, DMARC, DKIM cards.
  4. Subsequent runs follow your deliverability monitor interval.
  5. Use Rescan deliverability after DNS or mail server changes.

Warnings you may see

  • Some MX hosts unreachable: e.g. Google may refuse external port-25 probes; we score using the best reachable host and explain the restriction.
  • DNS unverified: if domain ownership verification is pending, some signals may be limited until DNS verification completes.

Accuracy philosophy

SenderSignal uses the same DNS and SMTP protocols remote MTAs use. We do not guess from WHOIS or passive databases. When a check cannot complete (timeout, REFUSED, NXDOMAIN), the UI states that explicitly rather than assuming success.

Mailbox providers may behave differently for probe IP ranges vs your production volume: we surface confidence levels where inference is involved (see scoring guide).

Related