# Email security checker: what a public check can and cannot prove > An email security checker reads public DNS for DMARC, SPF, DKIM, and BIMI records. See how Palisade's free check works, and exactly what it can't prove. A public email security checker reads a domain's DNS records and reports whether DMARC, SPF, DKIM, and related signals are published and internally consistent. Palisade's free Email Security Score does this for DMARC, SPF, DKIM, BIMI, MX, MTA-STS, and TLS-RPT, then returns a 0-100 score with a plain-language finding for each signal. It cannot inspect a delivered message, confirm that a separate DMARC monitoring service is actually working, or see every DKIM selector a provider keeps private. ## Quick takeaways - Palisade's Email Security Score checks DMARC, SPF, DKIM, BIMI, MX, MTA-STS, and TLS-RPT from a single domain or email address input. - The score runs 0-100, with published bands of 80+ ("great"), 60-79 ("good"), 35-59 (weak), and below 35 (critical), on Palisade's own scale, not an audited industry standard. - Every section pairs a plain-language finding with a "Technical details" expander, and a failing section can offer a "Fix Now" control. - The DMARC finding can read "Domain protected" while the tool separately states it cannot confirm a third-party monitoring service is active and effective. - DKIM coverage is a scan of known selectors, so a provider-only selector can go undetected even when signing is correctly configured. - A high score reflects what public DNS shows at the moment of the check. It does not test whether every message from the domain will authenticate or reach an inbox. ## What this tool checks [Palisade's Email Security Score](/tools/email-security-score) describes its own job directly on the tool page: "Score your domain's DMARC, SPF, DKIM, and BIMI in one free check." Its published FAQ goes further than that headline and adds three more signals: it "reads your domain's public DNS records and runs individual checks across DMARC, SPF, DKIM, BIMI, MX, MTA-STS, and TLS-RPT," and "every finding contributes to the 0-100 total." All seven signals live in public DNS. DMARC is defined in [RFC 7489](https://datatracker.ietf.org/doc/html/rfc7489), SPF in [RFC 7208](https://datatracker.ietf.org/doc/html/rfc7208), DKIM in [RFC 6376](https://datatracker.ietf.org/doc/html/rfc6376), MTA-STS in [RFC 8461](https://datatracker.ietf.org/doc/html/rfc8461), and TLS-RPT in [RFC 8460](https://datatracker.ietf.org/doc/html/rfc8460). A checker limited to these published records can confirm a record exists, that its syntax and mechanisms parse, and that the pieces line up with each other. It cannot confirm what a specific outbound system does when it actually sends mail, and it cannot see inside a provider's private signing infrastructure. ![Email authentication signals checked by the Email Security Score](/images/editorial/email-security-checker/email-security-checker-signals.webp "1200x843") *Source: Palisade.* ## How to run the check ### 1. Decide what to submit The tool has one input field, whose hint text reads "user@example.com or example.com," so a full address or a bare domain both work. No account, sign-in, or payment step sits in front of it. The only thing submitted is the domain. ### 2. Get the score Enter the domain and select "Get Score." A worked run against cloudflare.com returned "Results for cloudflare.com," a score of 90, "Risk level: Low," and "Better than 97% of tested domains." Below the headline number, a "Security Indicators" row shows a pass or fail state for DMARC, SPF, DKIM, and BIMI, with a "Scan another domain" control to check a second address. ### 3. Confirm the same records independently Because the check reads public DNS, the same answers are visible through any resolver. Query the DMARC, SPF, and MX records directly before acting on a score: ```bash dig +short TXT _dmarc.yourdomain.com dig +short TXT yourdomain.com dig +short MX yourdomain.com ``` If a direct query disagrees with the tool's result, a DNS change is likely still propagating, or the query targeted a different owner name than the one the tool used. ## How to interpret the results ### The score and risk band Palisade publishes four bands on its 0-100 scale: 80 and above is "great," 60 to 79 is "good," 35 to 59 is weak, and below 35 is critical. A domain that has never set up DMARC "usually lands in the lower bands on their first check," per the tool's own documentation. Both the bands and the "Better than X% of tested domains" comparison are built from domains Palisade has scanned, not an independently audited benchmark, so a result here is not directly comparable to a score from a different vendor's checker. ![Palisade Email Security Score bands from critical to great](/images/editorial/email-security-checker/email-security-checker-score-bands.webp "1200x600") *Source: Palisade.* ### DMARC: a defended domain, and a monitoring gap it can't verify "Defended Domain (DMARC)" can cost up to 5 points if the record is missing or invalid. DMARC, defined in RFC 7489, publishes a policy of `p=none`, `quarantine`, or `reject` and layers it on top of SPF and DKIM alignment; the record itself does not guarantee anyone is watching the aggregate reports it generates. Cloudflare.com's DMARC finding read "Domain protected - Double check monitoring emails," meaning the record and policy passed while the tool flags monitoring as a separate, unverified question. When a domain's reports route to a service other than Palisade, the finding is explicit: "DMARC Monitoring: Not Palisade" and "We cannot determine if this monitoring is active and effective." A published record proves the policy is public. It does not prove anyone is reading what it reports. For the basics of what the record itself controls, see [what DMARC is](/learning/what-is-dmarc), or run the domain through the [DMARC checker](/tools/dmarc) on its own. ### SPF: authorized senders and an overly rigid record "Authorized Senders List Record (SPF)" is also worth up to 5 points. SPF, defined in RFC 7208, publishes the hosts authorized to send for a domain and ends with a qualifier, `-all`, `~all`, or `?all`, that tells a receiver how to treat everything else. The worked run flagged cloudflare.com's SPF record as "SPF record is too rigid," with a "Fix Now" control attached to that section. The exact rule behind that specific label wasn't part of this review, so treat it as a prompt to compare the record's mechanisms against the domain's confirmed sending inventory rather than a documented formula. Rebuild the record with an SPF generator once every current sender is confirmed, not before. ### DKIM: signature found, but selector coverage is limited "Digital Signature (DKIM)" returned "DKIM signature(s) found - Properly configured" for cloudflare.com. DKIM, defined in RFC 6376, ties a signature to a specific selector published at `._domainkey.`, and a domain can run several selectors across different senders at once. Palisade states its own limit here directly: "We may be unable to detect all of your DKIM signatures as they are protected by your providers." A pass on this section confirms the selectors the scan found are usable. It does not confirm that every selector a sending provider actually uses was included in the scan. ### BIMI: brand display and the verified checkmark "Brand Display and Verified Checkmark (BIMI)" reported "Brand verification found and working correctly" for cloudflare.com. BIMI, documented in the IETF draft [Brand Indicators for Message Identification](https://datatracker.ietf.org/doc/html/draft-brand-indicators-for-message-identification), ties a domain's logo to its DMARC record, and the verified checkmark several mailbox providers display generally requires a Verified Mark Certificate alongside DMARC enforcement. A pass here shows the published record parses. Whether a specific mailbox provider actually renders the logo is a decision made inside that provider's own inbox, not something a DNS check can confirm. ### MX, MTA-STS, and TLS-RPT Three lower sections round out the score. "Mail Exchange Address (MX)" confirms mail servers are published for the domain; cloudflare.com's result read "Mail exchange (MX) record is present." "MTA-STS and TLS Reporting," marked Beta, checks two transport-security records defined in RFC 8461 and RFC 8460: cloudflare.com returned "MTA-STS is not configured" and "TLS-RPT reporting is not configured." Both sit apart from message authentication. MTA-STS tells sending servers to require TLS when delivering to a domain, and TLS-RPT reports on TLS connection failures; neither affects whether DMARC, SPF, or DKIM pass. ## How to act on the result Work through findings in the order they change what a receiver does with the domain's mail, not the order the score lists them: - A missing or invalid DMARC record comes first. Nothing else on the list matters to a receiver's policy decision if DMARC itself is absent. - An SPF record flagged as too rigid comes next. Rebuild it against the confirmed sending inventory, not a guess, so senders that are actually authorized do not start failing. - A DKIM pass with an unclear selector list is a prompt to confirm coverage with each sending provider directly, since the scan cannot guarantee it saw every selector in use. - BIMI and the beta MTA-STS or TLS-RPT sections are worth configuring once DMARC, SPF, and DKIM are solid, since BIMI depends on DMARC enforcement and the other two govern transport security rather than authentication. If a dedicated email security product already sits in front of the domain, the checker still reads the same public DNS regardless of what else is inspecting mail in transit; see [Mimecast email security: what it does and what it cannot prove](/learning/mimecast-email-security) for how a gateway product's checks differ from a DNS-only scan. Every section's "Technical details" expander shows the specific record a finding is based on. The results page also offers "Analyze these results with AI," which sends the check and its results to a third-party model, ChatGPT, Claude, Gemini, Perplexity, or Grok, for a plain-language explanation and a fix plan. That feature summarizes the same DNS evidence already on the page; it does not run a new check or add evidence the tool did not already collect. ## How to retest DNS changes take time to propagate, and a resolver can still serve a cached answer for the previous record's time-to-live. Confirm the new record with a direct query before expecting the score to change: ```bash dig +short TXT _dmarc.yourdomain.com ``` Once the direct query returns the corrected record, rerun the domain through the checker and compare the new finding label and score against the earlier run. Keep both results, with their dates, since the score is a snapshot rather than a continuously updated status. ## Fix the gaps the score can't keep watching The Email Security Score reads DNS once, at the moment you select "Get Score." It cannot tell you when a new sending source shows up next month, whether the DMARC monitoring service already in place is actually processing an aggregate report, or when a corrected SPF record drifts back toward "too rigid" after someone adds a new mail platform. Palisade's DMARC Agent reads a domain's incoming aggregate reports on an ongoing basis, identifies sending sources and the specific authentication or alignment problem behind each one, and creates a prioritized remediation ticket for a human to act on, instead of a one-time label from a single scan. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_evaluation&utm_content=email-security-checker) Signing up gives ongoing analysis of aggregate-report data and prioritized remediation tickets. It does not change a DNS record on your behalf or guarantee that a corrected record will pass at every receiver. ## Sources and further reading - [Palisade Email Security Score](https://www.palisade.email/tools/email-security-score) - [RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)](https://datatracker.ietf.org/doc/html/rfc7489) - [RFC 7208: Sender Policy Framework (SPF)](https://datatracker.ietf.org/doc/html/rfc7208) - [RFC 6376: DomainKeys Identified Mail (DKIM) Signatures](https://datatracker.ietf.org/doc/html/rfc6376) - [Brand Indicators for Message Identification (BIMI)](https://datatracker.ietf.org/doc/html/draft-brand-indicators-for-message-identification) - [RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)](https://datatracker.ietf.org/doc/html/rfc8461) ## Frequently asked questions ### Does a high score mean the domain is protected from spoofing? No. A high score confirms DMARC, SPF, DKIM, and the other checked records are published and internally consistent. It does not test how every receiver enforces the domain's policy, and it is not a substitute for reviewing headers from a delivered message. ### Does the checker need account access or a password? No. It reads only public DNS for the domain or address submitted. No sign-in, account, or payment step is part of the flow. ### Why did DKIM read "properly configured" when a provider's dashboard shows a signing error? The DKIM section confirms it found at least one usable selector in DNS. Palisade states directly that it may not detect every DKIM signature a provider protects internally, so a signing error on a selector the scan did not see would not appear in this result. Treat the sending provider's own dashboard as the more current source for that specific selector. ### Is 80 a passing score on every checker? No. Palisade publishes 80 and above as its own "great" band on a 0-100 scale built from domains it has tested. Other checkers use different signal sets and different scoring methods, so scores are not directly comparable across tools. ### What does "Analyze these results with AI" actually check? It sends the same check and result data already on the results page to a third-party AI model (ChatGPT, Claude, Gemini, Perplexity, or Grok) and returns a plain-language explanation and fix plan. It summarizes the DNS evidence Palisade already collected. It does not run an independent scan or add new evidence. ### Can the checker confirm that a third-party DMARC monitoring service is working? No. When a domain's DMARC record routes reports somewhere other than Palisade, the tool states this directly: it cannot determine whether that monitoring is active or effective. Confirm report delivery with the monitoring provider's own dashboard instead.