Email Security Score
Check the public controls protecting your domain's email identity and get a prioritized repair list.
Free · No signup · Read-only public DNS check · Results in seconds
Checks DMARC, SPF, DKIM, MX, MTA-STS, TLS-RPT, and BIMI. It cannot inspect mailbox passwords, private tenant settings, message content, private reputation data, or inbox placement.
No Score Just Yet
Your score will appear here once you submit a domain.What is an Email Security Score?
The Email Security Score is a point-in-time assessment of the public DNS controls protecting a domain's email identity. It checks DMARC, SPF, DKIM, BIMI, MX, MTA-STS, and TLS-RPT, then turns the findings into a 0–100 score and an ordered repair list. It does not inspect mailbox passwords, private provider reputation data, or inbox placement.
How the score is calculated
The checker queries the domain's published records and evaluates each control for presence, validity, and safer configuration. Missing or failing SPF, DKIM, and DMARC findings carry the most practical urgency because they affect sender authentication. Transport security, routing, and BIMI findings complete the public-domain picture. The report shows the individual evidence behind the total, so the number never has to be interpreted on its own.
The total and the bands below are Palisade's prioritization model, not an industry certification, provider-compliance verdict, or inbox-placement prediction.
Example: turn a score into an action plan
Suppose a domain scores 42 because DMARC is still monitoring, one sending service is not represented in SPF, and MTA-STS is missing. The useful output is not “42”; it is the sequence of evidence to verify: identify the real sender, repair SPF or DKIM alignment for that stream, review DMARC reports before enforcement, then add transport security without interrupting inbound mail.
- Start with the highest-impact failed finding in the report.
- Confirm it against the provider configuration or a real message header.
- Change one controlled setting and wait for its DNS TTL.
- Re-run the score and preserve the before-and-after evidence.
Use the right follow-up check
Use the focused DMARC checker, SPF checker, or DKIM checker when one published record needs repair. Use the email deliverability test when you need evidence from a message sent through a production stream. Public checks cannot guarantee a receiver's final handling decision.
Technical references
The checks use the public standards for SPF, DKIM, DMARC, MTA-STS, and TLS reporting. BIMI findings follow the current specifications published by the Authenticated Mark Certificates Working Group.
Email authentication knowledge base
What is a good email security score?
A score of 80 or above is rated "great" on this checker's 0–100 scale and usually means SPF, DKIM, and DMARC are set up correctly. 60–79 is "good" with at least one gap worth closing, 35–59 signals weak protection, and below 35 is critical. Domains that have never set up DMARC usually land in the lower bands on their first check, so a low starting score is normal. The report lists the exact fixes, ranked by impact.
How is the email security score calculated?
The checker reads your domain's public DNS records and runs individual checks across DMARC, SPF, DKIM, BIMI, MX, MTA-STS, and TLS-RPT. Each check looks for a valid record and a safe configuration, and every finding contributes to the 0–100 total. Missing or failing sender-authentication records (SPF, DKIM, and your DMARC policy) typically pull the score down the most, and the report shows which fixes will lift it the most.
How do I check if my email is secure?
Enter your domain in the checker above. It inspects the public DNS records that control sender authentication (SPF, DKIM, DMARC), transport security (MTA-STS, TLS-RPT), mail routing (MX), and brand indicators (BIMI), then returns a 0–100 score with the specific issues it found. This covers the domain side of email security: whether someone else can convincingly send email as you. Securing an individual mailbox is separate, and comes down to strong passwords and two-factor authentication.
How do I improve my email security score?
Work through the report from the highest-impact finding down. Publish a valid SPF record and keep it under the 10-DNS-lookup limit, enable DKIM signing for every service that sends as your domain, then publish a DMARC record and move it gradually from p=none to p=quarantine and p=reject as legitimate senders come into alignment. MTA-STS, TLS-RPT, and BIMI add further points. Re-run the check after each DNS change to confirm the fix took effect.
Why Check Domain Security?
Checking domain security is crucial to protect against cyber threats like phishing, domain spoofing, and unauthorized access. Regular security checks help identify vulnerabilities, ensure compliance with best practices, and maintain the integrity and reputation of the domain. This is essential not only for safeguarding sensitive information but also for preserving user trust and confidence in digital interactions with the domain.
What does an email security assessment include?
An email security assessment (also called an email security audit) reviews how well a domain resists spoofing, phishing, and interception. It covers sender authentication (SPF, DKIM, and the DMARC policy), transport encryption (MTA-STS, TLS-RPT), mail-server setup (MX records), and brand protection (BIMI). This tool runs the domain-layer assessment automatically from public DNS in seconds. A full organizational audit would add items no DNS scan can see, such as mailbox access controls and user awareness.
What is an email risk score?
An email risk score estimates how exposed a domain is to email-based attack, based on whether SPF, DKIM, and DMARC are missing, misconfigured, or left unenforced. The 0–100 score on this page is that kind of domain-level measure. The same phrase is also used in fraud prevention, where vendors score individual email addresses at signup; that is a different measurement. To understand your own domain's spoofing exposure, the domain-level score is the one to track.
Is this email security check free?
Yes. The check is free, runs online in seconds, and needs no account: enter a domain and you get the full score and findings. You can re-run it as often as you like, for example after each DNS fix. It only reads public DNS records, so it makes no changes to your domain.
Can I check any domain's email security?
Yes. The check works on any domain because it reads public DNS records, so you don't need to own or verify a domain to score it. IT teams typically check their own domains and subdomains, while managed service providers use it to assess client and prospect domains before an email-security conversation. Scoring a domain changes nothing on the domain itself.
How often should I run an email security check?
Re-run the check after any change to your DNS or sending stack: a new marketing platform, CRM, or helpdesk that sends as your domain, a DNS migration, or a DMARC policy update. For a stable domain, a quarterly check is a sensible floor. A check is a point-in-time snapshot, though. Sending services and DNS records drift, which is why teams that take DMARC seriously monitor aggregate reports continuously instead of relying on occasional scans.
A comprehensive reference for the technical terms and tags used in these email authentication and branding protocols.
- vVersion
- The Version tag is essential in a DMARC record and must strictly be set to ‘DMARC1’. If this value is not correctly specified or if the tag is absent, the DMARC record will not be considered valid and will be disregarded.
- pDMARC policy
- The DMARC policy setting is crucial and accepts three possible values: ‘none’, ‘quarantine’, or ‘reject’. By default, it is set to ‘none’, which means it doesn’t actively intervene with emails that fail authentication. This setting primarily serves to gather DMARC reports, aiding in understanding the existing email traffic and its authentication status. On the other hand, the ‘quarantine’ option flags unauthenticated emails as dubious, and ‘reject’ outright prevents their delivery.
- ruaAggregate report destination
- The destination for sending aggregate reports is specified using a ‘mailto:’ URI, which Email Service Providers (ESPs) utilize to dispatch failure reports. While this tag is not mandatory, omitting it means you will not receive any reports.
- rufForensic report destination
- The destination for Forensic (Failure) report transmission is designated by a ‘mailto:’ URI, which is employed by Email Service Providers (ESPs) for the delivery of failure reports. Although this tag is not obligatory, failing to include it will result in not receiving any reports.
- spSubdomain policy
- The policy for subdomains defaults to inheriting the main domain’s policy tag (p=), as previously described, unless explicitly stated otherwise. Similar to the domain policy, the permissible values for subdomains are ‘none’, ‘quarantine’, or ‘reject’. However, this option is not commonly employed in current practices.
- adkimDKIM alignment
- The alignment of the DKIM signature, indicated by this tag, refers to the congruence between the DKIM domain and the originating domain in the ‘Header From’. The acceptable values for this tag are ‘r’ for relaxed and ‘s’ for strict. The default setting, ‘r’, permits a partial match between these domains, whereas the ‘s’ setting demands an exact match of the domains.
- aspfSPF alignment
- This tag pertains to the SPF alignment, which concerns the compatibility between the SPF domain (the sender) and the domain in the ‘Header From’. It allows two settings: ‘r’ for relaxed and ‘s’ for strict. By default, it is set to ‘r’, which tolerates a partial match between the domains. In contrast, the ‘s’ setting necessitates an exact correspondence of the domains.
- foForensic reporting options
- The options for forensic reporting include ‘0’, ‘1’, ‘d’, and ‘s’. The default setting is ‘0’, which triggers a forensic report only when both SPF and DKIM alignments do not pass. Use ‘1’ if the outcome of either SPF or DKIM is anything other than a pass. The option ‘d’ is selected to generate a report specifically for DKIM validation failures, and ‘s’ is used for SPF-related issues. To actually receive these forensic reports, it’s necessary to specify the ‘ruf’ tag.
- rfFailure report format
- The format for failure report generation can be set to either ‘afrf’ or ‘iodef’, as these are the two permissible options.
- pctPercentage (historic)
- The legacy Percentage tag asked receivers to apply a quarantine or reject policy to only part of the mail that failed DMARC. RFC 9989 removed pct because receivers implemented partial enforcement inconsistently. New records should omit it and stage rollout with aggregate reports, whole-policy changes, and low-volume subdomains.
- riReporting interval
- The Reporting interval specifies how often XML reports are received, measured in seconds. The standard setting is 86400 seconds, which equates to daily reporting. However, it’s important to note that despite the specified interval, Internet Service Providers (ISPs) typically send these reports on their own schedules, which in most cases, is also once a day.