Feature

Email Authentication Checks

Validate SPF, DKIM, and DMARC at the DNS layer — continuously — so reputation and deliverability stay healthy after every change.

Start free

Why it matters

Customers expect receipts, password resets, and notifications to arrive instantly. A small DNS tweak can undo that: SPF records that exceed lookup limits, a rotated DKIM selector that never got published, or a DMARC policy set to p=none on your primary domain. endpnts.io watches these controls continuously so regressions don’t slip past a deploy.

What we check

  • SPF (TXT at apex or sender domain) — presence, single-record rule, syntax, include/redirect chains, and an estimate of DNS lookups vs. best-practice limits.
  • DKIM (TXT at <selector>._domainkey.<domain>) — selector presence (you provide selectors), key syntax, and recommended key length checks.
  • DMARC (TXT at _dmarc.<domain>) — presence, policy (p=none/quarantine/reject), alignment modes, pct, and rua/ruf URI formatting.
  • Optional MX & STARTTLS — MX presence and STARTTLS availability from multiple regions to catch cutover mistakes.

We perform DNS-level validation and network reachability tests; we don’t inspect live message headers or impersonate mail flow.

Issues we help you avoid

  • Multiple or malformed SPF records that cause receivers to hard-fail your domain.
  • DKIM rotations where the new selector wasn’t published or uses an invalid key.
  • DMARC weakened to p=none on production domains, or broken reporting URIs that hide problems.
  • MX migrations that accidentally drop STARTTLS in one region, hurting reputation and security.

Signals at a glance

What’s validated and the practical impact if it breaks.

Record Validation Impact if broken Typical alert
SPF Presence, single-record rule, syntax, include/redirect expansion, lookup estimate Receivers may reject or spam-folder outbound mail “SPF lookups exceed safe limit after provider change”
DKIM Selector exists, TXT syntax, recommended key length Signatures fail; authentication and reputation drop “DKIM selector s1 missing / key invalid”
DMARC Presence, p= policy, alignment, pct, rua/ruf formatting Impersonation risk; reduced visibility via reports “DMARC policy relaxed to p=none on apex domain”
MX & STARTTLS MX presence and STARTTLS availability across regions Deliverability and security regress during cutovers “STARTTLS not available on mx1.example.net (EU West)”

Best-practice guardrails for SMBs

  • Keep SPF simple: prefer provider-supplied include: entries over copying raw IPs; avoid multiple SPF TXT records.
  • Rotate DKIM safely: publish new selector (e.g., s2) before retiring the old (e.g., s1) to prevent gaps.
  • Strengthen DMARC gradually: move from p=none → quarantine → reject once authenticated traffic is stable.
  • Plan MX cutovers: lower TTLs in advance, verify STARTTLS from two regions, then raise TTLs post-cutover.

Alert routing that fits your team

Route email-auth incidents to the right owners with Notification Policies. Use severity to choose channels (chat/email vs. SMS) and apply maintenance windows during planned DNS work.

Configure alerts Set notification policy Pair with DNS Safety

Quick setup

You’ll be checking the right records in minutes.

  1. Add your domain (e.g., example.com).
  2. Enter known DKIM selectors (e.g., s1, s2) — you can add more later.
  3. Enable optional MX/STARTTLS checks if you manage your own mail exchange.
  4. Pick who gets notified and on which channels using Notification Policies.

Per-plan limits may apply (e.g., number of domains or selectors monitored).

Keep your domain’s email reputation intact

Catch risky DNS changes before customers miss critical emails.

Start free