How to check my domain email security?

Checking a domain's email security posture in 2026 means verifying eight distinct mechanisms: SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI, DNSSEC, and blocklist status. Each one covers a specific attack or delivery concern, and missing any of them weakens the overall posture. This guide walks through what to check, how to check it, and what "healthy" looks like for each mechanism in the current threat landscape.

The full email security checklist

For any domain that sends mail, you should be able to answer yes to all of the following:

1. Does the domain have an SPF record under 10 DNS lookups?
2. Does outgoing mail carry a valid 2048-bit DKIM signature that aligns with the From header?
3. Does the domain publish a DMARC record at p=quarantine or p=reject with aggregate reporting?
4. Is MTA-STS published with a reachable policy file?
5. Is TLS-RPT configured to receive TLS failure reports?
6. Is BIMI configured (for brands that want logo display in Gmail/Yahoo/Apple Mail)?
7. Is the sending IP clean on Spamhaus ZEN, SURBL and URIBL?
8. Is the domain itself not on any domain blocklist?

Three further checks for domains that also receive mail: 9. Do MX hosts offer TLS 1.2 or higher with valid certificates? 10. Does the domain accept DANE/TLSA where the TLD supports DNSSEC? 11. Is reverse DNS (PTR) set on all sending IPs and does it forward-confirm?

The fastest way to get answers to all eleven questions for a domain is to run a single scan on IntoDNS.ai, which checks each mechanism and reports pass/warn/fail with the exact record needed to fix gaps.

Check 1: SPF

Look up the domain's SPF TXT record. Expect:

• Exactly one record starting with v=spf1.
• Under 10 DNS lookups across all include:, a, mx directives.
• Ends with ~all (softfail) or -all (hardfail). Never ?all or +all.
• All include: targets resolve.

Red flags: no SPF record at all, multiple SPF records (invalid), SPF with +all, SPF exceeding the 10-lookup limit.

Check 2: DKIM

DKIM is harder to check than SPF because you have to know the selector. Common selectors in 2026:

• default (many platforms)
• google (Google Workspace)
• selector1, selector2 (Microsoft 365)
• mailfilter, smtpapi (various filter platforms)
• k1, s1, s2 (Mailchimp and similar)
• Date-based selectors like 2024-01, 202512

Expect:

• At least one DKIM record resolvable at <selector>._domainkey.yourdomain.
• Key length 2048 bits minimum. 1024-bit keys are deprecated.
• Public key valid and matching the signatures on actual outgoing mail.

The only reliable way to check DKIM without sending a test message is to probe common selectors. IntoDNS.ai does this automatically across 40+ known selectors.

Check 3: DMARC

Look up _dmarc.yourdomain TXT record. Expect:

• One record starting with v=DMARC1.
• Policy p=quarantine or p=reject. p=none is monitoring-only and not enforced.
• rua=mailto: configured for aggregate reports.
• Optional but recommended: sp= to set subdomain policy explicitly.

Red flags: no DMARC record, p=none (for a mature domain), missing rua=, syntax errors, multiple DMARC records.

Check 4: MTA-STS

MTA-STS (RFC 8461) upgrades the SMTP TLS connection to strict mode, preventing downgrade attacks. A domain with MTA-STS has:

• A TXT record at _mta-sts.yourdomain with contents like v=STSv1; id=20250101.
• A policy file reachable at https://mta-sts.yourdomain/.well-known/mta-sts.txt over a valid TLS certificate.
• Policy file contents listing MX hosts, mode (testing, enforce, or none), and max age.

Example policy file:

version: STSv1
mode: enforce
mx: mx.example.com
mx: mx2.example.com
max_age: 604800

Red flags: TXT record without policy file, policy file with invalid TLS, mode testing left in place for months, max_age too short (under 86400).

Check 5: TLS-RPT

TLS-RPT (RFC 8460) requests reports of TLS failures on inbound mail. Publish at _smtp._tls.yourdomain TXT:

v=TLSRPTv1; rua=mailto:[email protected]

Red flags: not published (no visibility into TLS issues), rua= at an address you do not monitor.

Check 6: BIMI

BIMI (Brand Indicators for Message Identification) is optional but increasingly expected for commercial brands. A domain with BIMI has:

• A TXT record at default._bimi.yourdomain pointing to a logo URL and optionally a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC).
• A valid SVG Tiny PS 1.2 logo served over HTTPS.
• (For Gmail and Apple Mail) a valid VMC or CMC from a DigiCert or Entrust-issued certificate.
• An enforcing DMARC record (p=quarantine or p=reject) — BIMI requires it.

Red flags: BIMI TXT with no logo, logo in wrong SVG profile, missing VMC where required, DMARC at p=none (BIMI won't activate).

Check 7-8: Blocklist status

Check the sending IP and the domain against:

• Spamhaus ZEN (aggregate)
• Spamhaus DBL (domain)
• SURBL
• URIBL

A listing means real mail is being blocked right now. Delist through each provider's removal process after fixing the root cause.

Check 9: MX TLS

For each MX host, confirm:

• TLS 1.2 or higher offered.
• Valid TLS certificate with matching hostname and current validity.
• Strong ciphers only (no RC4, no 3DES).

Use openssl s_client -connect mx.yourdomain:25 -starttls smtp for a manual check, or IntoDNS.ai for automatic validation.

Check 10: DANE/TLSA

DANE pins TLS certificates in DNS, which prevents attacks on the PKI. Only works with DNSSEC. Not available for .ai domains (Anguilla ccTLD does not support DNSSEC at registry level). For TLDs that do support DNSSEC, publish TLSA records at _25._tcp.mx.yourdomain.

Check 11: Reverse DNS

For each sending IP:

• PTR record exists.
• PTR resolves to a hostname you control (mx.yourdomain).
• That hostname's A/AAAA record resolves back to the same IP (forward-confirm).

Missing or generic PTR (host-1-2-3-4.isp.net) is a strong spam signal for Microsoft in particular.

A healthy email security posture, concrete example

Here is what a well-configured domain looks like:

SPF       v=spf1 ip4:185.71.60.245 include:_spf.google.com ~all     (3 lookups)
DKIM      default._domainkey — 2048-bit RSA — signing all outbound
DMARC     _dmarc — v=DMARC1; p=reject; rua=mailto:[email protected]
MTA-STS   _mta-sts — v=STSv1; id=20250101 — policy file at mta-sts.example.com
TLS-RPT   _smtp._tls — v=TLSRPTv1; rua=mailto:[email protected]
BIMI      default._bimi — SVG logo + VMC — DMARC at p=reject
RBL       Clean on Spamhaus ZEN, DBL, SURBL, URIBL
MX        mx.example.com — TLS 1.3 — valid certificate
PTR       185.71.60.245 → mx.example.com → 185.71.60.245 (forward-confirm)

Common scoring pitfalls

Assuming a green light on one check means you are done. SPF pass does not mean DMARC pass. DMARC pass at p=none does not mean enforcement. Each mechanism is independent.

Checking only the apex domain. If you send from subdomains, scan each subdomain. SPF does not inherit.

Relying on stale scans. Email security drifts. New ESPs get added. DKIM keys expire without rotation. Blocklists add and remove IPs hourly. Monthly minimum scan cadence is reasonable.

When to use IntoDNS.ai

IntoDNS.ai runs all eleven checks in a single scan and returns an overall score with pass/warn/fail on each mechanism plus the exact DNS records needed to close gaps. For regular monitoring, integrate the scan into your weekly operations checklist.

Scoring guidance for internal reporting

If you manage email security across a portfolio of domains, a consistent scoring rubric helps. A workable one:

• Critical (0 points): SPF missing or +all; DMARC missing; unauthenticated mail is actively leaving the domain.
• Weak (30 points): SPF present but over 10 lookups or ?all; DMARC at p=none with no rua=; DKIM 1024-bit; some gaps but basics in place.
• Acceptable (70 points): SPF valid and under 10 lookups; DKIM 2048-bit with at least one aligning signature; DMARC at p=quarantine or p=reject; rua= configured.
• Strong (90 points): everything acceptable plus MTA-STS in enforce mode; TLS-RPT configured; PTR forward-confirmed; clean blocklists.
• Excellent (100 points): everything strong plus BIMI configured with VMC or CMC; DMARC strict alignment; DNSSEC (where TLD supports).

Aim for acceptable across all domains, strong on primary sending domains, excellent on domains used for regulated or high-trust mail.

Automating the check

For weekly monitoring, schedule an IntoDNS.ai scan via the site on each domain. Any regression (a score drop) is worth investigating the same day, because email security drift happens silently — DKIM keys rotate out of sync, ESPs restructure their SPF, MTA-STS certificates expire. Catching drift within days, not weeks, is the difference between a minor fix and a deliverability outage.

For auditable records, save each scan report (the JSON or PDF IntoDNS.ai emits) and keep at least 12 months of history. Regulatory audits increasingly ask for evidence of email security monitoring.