Email Security Analyzer
Complete email security audit for any domain — SPF, DKIM, DMARC, MTA-STS, TLS-RPT, MX records, and BIMI checked simultaneously. Get an overall score, letter grade, and prioritised action plan. Built for IT admins, MSPs, and security teams.
Analyzing …
How the Email Security Analyzer works
Enter any domain and the analyzer performs five parallel checks simultaneously, then runs a quick PTR lookup for the primary mail server:
- Email Authentication — Queries the SPF record (including DNS lookup count), probes common DKIM selectors, and retrieves the DMARC record with full policy analysis.
- Transport Security — Validates the MTA-STS DNS TXT record and fetches the policy file to check mode, MX patterns, and max_age. Checks TLS-RPT for SMTP failure reporting configuration.
- Mail Infrastructure — Retrieves MX records, detects the email provider, checks redundancy, and performs a lightweight PTR reverse-DNS check on the primary MX host.
- Brand Protection — Checks the BIMI TXT record, validates the SVG logo URL, and verifies VMC authority certificate availability. Shown as an optional enhancement — does not affect the main score.
The overall score uses a weighted model: Email Authentication (50%), MTA-STS (20%), Mail Infrastructure (20%), TLS-RPT (10%). BIMI is shown separately and not included in the composite score.
Common uses
The Email Security Analyzer is designed for IT admins, MSPs, and security professionals who need a fast, structured view of a domain's email security posture:
- MSP client onboarding — run before a meeting to identify email security gaps and generate a plain-text report for the client
- Email deliverability troubleshooting — instantly verify SPF, DKIM, and DMARC are correctly configured
- Phishing risk assessment — check whether a domain is protected against spoofing before it appears in a security incident
- Post-migration validation — confirm all email authentication records survived a provider change or domain migration
- Compliance gap analysis — email authentication maps directly to CIS Control 9 and NIST CSF requirements
- Competitive research — assess vendor or competitor domains for email security maturity
Email Security Guidance
Frequently Asked Questions
Everything you need to know about email authentication, transport security, and protecting your domain from phishing and spoofing attacks.
What does the Email Security Analyzer check?
The analyzer runs five parallel checks — Email Authentication (SPF, DKIM, DMARC), Transport Security (MTA-STS, TLS-RPT), Mail Infrastructure (MX records, provider, PTR), Brand Protection (BIMI) — then performs a lightweight PTR check for the primary MX host. Results are scored using a weighted model and combined into an overall A+–F grade with consolidated findings and prioritised recommendations.
What is SPF and why does it matter?
SPF (Sender Policy Framework) is a DNS TXT record listing which mail servers are authorised to send email for your domain. Without SPF, any server can send email claiming to be from your domain. A strong record ends with -all to reject unauthorised senders. SPF must be combined with DMARC to actually enforce protection — SPF alone does not prevent spoofing of the visible From address.
Why is DMARC p=reject so important?
DMARC tells receiving mail servers what to do with email that fails SPF and DKIM checks. Without DMARC at p=reject or p=quarantine, attackers can send phishing email appearing to come from your domain and it will reach recipients' inboxes. p=reject is the only configuration that fully prevents domain spoofing. Even with SPF and DKIM in place, a missing or p=none DMARC record provides zero enforcement.
What is MTA-STS and should I enable it?
MTA-STS (RFC 8461) allows a domain to declare that inbound SMTP delivery must use verified TLS. Without MTA-STS, the SMTP connection between sending and receiving mail servers uses opportunistic TLS — which can be downgraded by an attacker. Deploy MTA-STS in testing mode first alongside TLS-RPT, review failure reports for 2–4 weeks, then switch to enforce mode once all delivery is confirmed working.
What is TLS-RPT and why do I need it?
TLS-RPT (RFC 8460) is a DNS TXT record at _smtp._tls.yourdomain.com that instructs sending servers to submit daily JSON reports about SMTP TLS failures. It is especially important when deploying MTA-STS — without TLS-RPT you have no visibility into certificate errors or delivery failures during the testing phase. Always enable TLS-RPT before or alongside MTA-STS.
Does BIMI affect my email security score?
No. BIMI is an optional brand enhancement that displays a logo next to emails in supporting inboxes. Its absence does not reduce your email security score and has no impact on email delivery, authentication, or anti-spoofing protection. It is shown separately under Brand Protection as an informational section. A domain without BIMI can still achieve a perfect email security score.
Why does DKIM sometimes show as not found?
DKIM keys are published at selector-specific subdomains like selector1._domainkey.yourdomain.com. There is no DNS standard for discovering all selectors. The analyzer probes common selector names (google, selector1, selector2, default, dkim, k1, mail, and others). If your provider uses a custom selector, DKIM appears not found even if signing is active. Check your email provider settings and verify using the SPF / DKIM / DMARC Validator with the specific selector.
What is a PTR record and why does it matter for mail?
A PTR record maps an IP address back to a hostname. For mail servers, forward-confirmed reverse DNS (PTR record that matches the forward DNS of the sending IP) is a signal of legitimate infrastructure. Some strict receiving servers check PTR records as a spam signal. For domains using Google Workspace or Microsoft 365, PTR records are managed by the provider and are typically correct automatically.
How is the overall score calculated?
The overall score is a weighted composite: Email Authentication (50% — SPF, DKIM, DMARC deductions from a base of 100), MTA-STS (20%), Mail Infrastructure/MX (20%), and TLS-RPT (10%). BIMI is shown as a Brand Protection score but contributes 0% to the composite — it is optional and its absence does not penalise the domain. Grades: A+ (95–100), A (85–94), B (70–84), C (55–69), D (40–54), F (below 40).
What should I fix first?
Address Critical findings first: no DMARC record and SPF +all are the highest-risk configurations. Then fix High findings: add or harden DMARC to p=reject, add SPF if missing, fix SPF lookup overflows. Medium findings (MTA-STS, TLS-RPT, DMARC reporting) improve defence in depth. The Recommendations section orders all actions by impact-to-effort ratio so you always know what to tackle next.
Can MSPs use this for client reports?
Yes. Use the shareable URL (?domain=clientdomain.com) to create a direct link to any client's analysis. The Copy Executive Summary button produces a plain-text snapshot with score, grade, top findings, and recommendations suitable for emailing or pasting into a ticket. The Copy Full Report button exports all findings, recommendations, and deep links. Each recommendation includes impact level, difficulty, and estimated effort for scoping remediation.
How often should I scan?
Scan any time you change DNS records, switch email providers, update DMARC policies, or migrate infrastructure. At minimum, scan monthly for production domains. MSPs typically scan client domains at onboarding, after migrations, and on a quarterly review cycle to catch configuration drift.