# EasyDMARC SPF checker: what it shows and how to read the result > EasyDMARC SPF checker folds SPF into a combined domain score. See what Low, Medium, and High mean and how to verify SPF yourself against RFC 7208. EasyDMARC's public SPF checker is not a separate SPF-only tool. Entering a domain on EasyDMARC's homepage runs a combined scan that returns a Risk Assessment Level of Low, Medium, or High and a DMARC Policy score out of 10, folding SPF together with DKIM and DMARC. To know whether SPF itself is valid, read the raw record against RFC 7208's rules directly, or run a dedicated SPF-only lookup. ## Quick takeaways - EasyDMARC's homepage scanner combines SPF, DKIM, and DMARC into one Risk Assessment Level and a DMARC Policy score out of 10; it does not publish a standalone SPF-only result page. - EasyDMARC also sells EasySPF, a paid product that flattens an SPF record to work around the 10 DNS-lookup limit. - The 10-lookup ceiling and the one-record-per-domain rule both come from RFC 7208, not from any vendor's checker. - A record can look fine in a combined score and still fail a live message if a sending service was added after the record was last updated. - A dedicated SPF-only checker confirms the isolated record state without averaging it against DKIM and DMARC. ## What this tool checks Enter a domain at [EasyDMARC's homepage](https://easydmarc.com) and its scanner returns two headline numbers: a "Risk Assessment Level: Low / Medium / High" and a "DMARC Policy: Score 0 of 10," evaluating SPF, DKIM, and DMARC together. This is the tool most people find when searching for an EasyDMARC SPF check, but its published output describes a whole-domain assessment, not an isolated SPF report. EasyDMARC also sells EasySPF, described on the same page as performing "a one-time DNS configuration" that lets a user "manage your SPF record from a centralized platform" and "eliminates issues like the 10 DNS lookup limit by dynamically flattening the record, converting domain includes into IP addresses." That is a paid remediation product, separate from the free scan. Both tools only see what is published in public DNS. Neither confirms that the server actually sending your mail uses the domain the record was written for, or that a specific message authenticated on delivery. For a side-by-side look at how free SPF and DMARC checkers compare, see Palisade's [comparison hub](/compare). ## How to run the check ### 1. Pull the current SPF record yourself Before trusting any score, query the domain's own TXT record so you have independent evidence: ```bash dig +short TXT yourdomain.com ``` Look for the line beginning with `v=spf1`. [RFC 7208](https://datatracker.ietf.org/doc/html/rfc7208) permits exactly one SPF record per domain; a second one is a permanent error, not a second layer of protection. ### 2. Run the domain through EasyDMARC's scanner Go to easydmarc.com and enter the domain. Note the Risk Assessment Level and the DMARC Policy score. Because the score blends three protocols, a Low risk rating does not by itself mean the SPF record has no problems: a strong DKIM and DMARC setup can offset a weaker SPF record in a combined score. ![EasyDMARC product graphic used on its marketing pages to illustrate combined SPF, DKIM, and DMARC reporting](/images/editorial/easydmarc-spf-checker/easydmarc-spf-checker-easydmarc-spf-checker-homepage-scan-widget.webp "1600x900") *Source: [EasyDMARC](https://easydmarc.com), general product graphic, checked 2026-08-11. [Open the full-size image](/images/editorial/easydmarc-spf-checker/easydmarc-spf-checker-easydmarc-spf-checker-homepage-scan-widget.webp).* ### 3. Count the record's own DNS lookups Read back through the record you pulled in step 1 and count every mechanism that triggers its own DNS lookup: `include`, `a`, `mx`, `ptr`, `exists`, and `redirect`. RFC 7208 caps SPF evaluation at 10 of these per check. Going over that ceiling produces a permanent error regardless of what any combined score reports. ## How to interpret the results ### Risk assessment level: Low EasyDMARC's own page publishes the label names, Low, Medium, and High, without publishing the scoring formula behind them. Treat a Low rating as a starting point, not a substitute for reading the record. A domain can carry a technically valid SPF record and still land in this tier partly because of DKIM or DMARC factors, since a combined score does not isolate any single protocol. ### Risk assessment level: Medium or High A Medium or High rating tells you at least one of SPF, DKIM, or DMARC needs attention, but not which one on its own. Pull the record yourself (step 1) and compare it against RFC 7208's requirements: one record, prefixed with `v=spf1`, ending in an explicit qualifier such as `-all` or `~all`, and under the 10-lookup ceiling. ### DMARC policy score out of 10 The DMARC Policy score is a separate number from the risk level and reflects the DMARC record's policy strength directly. A domain publishing `p=none` scores lower than one publishing `p=reject`, independent of whether its SPF record is otherwise correct. Palisade's [DMARC checker](/tools/dmarc) reads the same `p=` tag directly if you want to confirm the enforcement level without the combined score attached. ## An independent SPF result matrix Because a combined score does not isolate SPF, the table below separates the raw SPF states defined by RFC 7208 from what each one means and what to do next. This is an original reference built from the RFC, not a reproduction of any vendor's output. ![Table mapping SPF checker result states to their RFC 7208 meaning and the recommended fix](/images/editorial/easydmarc-spf-checker/spf-result-states.webp "1200x666") *Source: Palisade.* ## How to act on the result For a missing or malformed record, republish it from the sending service's current documentation rather than copying an old one from another domain. For a lookup count near or over 10, either remove unused includes or evaluate a flattening product like EasyDMARC's EasySPF, which converts includes into static IP addresses; that is a tradeoff worth weighing, since a flattened record needs regenerating whenever an underlying service's IP ranges change. For a record that reads as valid on both the combined score and the RFC checklist, the remaining question is whether the server that sent your last message actually matches the record and whether the return path aligns with the visible From domain. Palisade's [SPF checker](/tools/spf) inspects the record directly rather than folding it into a combined score, which makes it a faster way to confirm the isolated SPF state at any point in a repair. ![Generic Palisade product graphic illustrating DMARC agent reporting, not a specific SPF checker results screen](/images/editorial/easydmarc-spf-checker/easydmarc-spf-checker-easydmarc-spf-checker-interpretation-matrix.png "1600x900") *Source: Palisade, general product graphic, checked 2026-08-11. [Open the full-size image](/images/editorial/easydmarc-spf-checker/easydmarc-spf-checker-easydmarc-spf-checker-interpretation-matrix.png).* ## Investigate this with your coding agent Use this when a record already has five or six mechanisms and you cannot tell by eye whether it is near the 10-lookup ceiling. Export the record from your DNS provider or version-controlled zone file, and redact the domain name before handing it to the agent. ```agent Problem: A domain's SPF TXT record may exceed RFC 7208's 10 DNS-lookup limit or contain a syntax error, and it is unclear which included domain accounts for the most lookups. Evidence: The current SPF TXT record for the domain (redact the domain name and any internal hostnames), taken from `dig +short TXT yourdomain.com` or the DNS provider's export, plus the zone file or IaC source if one exists. Repository scope: The DNS zone file, the Terraform or other IaC module defining the TXT record, and any script that generates it. No application code. Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not query external resolvers with the real production domain name if that is a concern; work from the redacted record text instead. Requested output: A count of DNS-querying mechanisms (include, a, mx, ptr, exists, redirect) against the 10-lookup ceiling, a list of any syntax issues (missing v=spf1, missing or ambiguous terminating mechanism, more than one SPF record), and a minimal proposed rewrite naming the removed or merged mechanisms. Verification: Re-run the same redacted record through Palisade's SPF checker or a fresh dig +short TXT query after a human applies the DNS change, and confirm the lookup count and syntax state both changed as expected. Stop if: The task requires DNS provider credentials, API tokens, or write access to production DNS. Report findings only. ``` ## How to retest After you change the record, propagation means the new value will not appear everywhere at once. Query the authoritative name server directly first: ```bash dig +short TXT yourdomain.com @ ``` Then check a public resolver such as 8.8.8.8 or 1.1.1.1 to confirm the change has spread. Only after both agree should you re-run EasyDMARC's scanner or Palisade's [SPF checker](/tools/spf) and expect the new record to show. Neither check confirms your outbound server is actually using the new record until a live message goes out and its `Authentication-Results` header shows an SPF pass; that step needs a delivered message, not a DNS lookup alone. ## Check the SPF record, then keep it accurate as senders change A one-time scan, from EasyDMARC or from Palisade's own checker, confirms today's record. It does not catch the day a team adds a new marketing platform or help desk tool that sends mail from the domain without anyone updating the SPF `include`, which is a common way a previously valid record starts failing alignment months later. Palisade's DMARC Agent reads incoming aggregate reports, identifies which sending sources are failing SPF or DKIM alignment, and creates a prioritized ticket when a new or misaligned source shows up, while a human reviews the evidence and applies the DNS change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_comparisons&utm_content=easydmarc-spf-checker) ## Sources and further reading - [EasyDMARC](https://easydmarc.com) - [RFC 7208: Sender Policy Framework (SPF)](https://datatracker.ietf.org/doc/html/rfc7208) - [RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)](https://datatracker.ietf.org/doc/html/rfc7489) - [Palisade SPF checker](/tools/spf) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### How do I check if an SPF record is valid? Query the domain's TXT records and confirm exactly one starts with `v=spf1`, per [RFC 7208](https://datatracker.ietf.org/doc/html/rfc7208). Count every mechanism that triggers a DNS lookup (`include`, `a`, `mx`, `ptr`, `exists`, `redirect`) and confirm the total stays at or under 10. The record must also end in an explicit qualifier, most commonly `-all` or `~all`. A dedicated checker such as [Palisade's SPF checker](/tools/spf), or a plain `dig +short TXT` query against your own domain, confirms this directly without folding SPF into a wider score. ### Does DMARC override SPF? No, DMARC does not replace or override SPF. It reads the SPF (and DKIM) result and adds an identifier alignment check on top, per [RFC 7489](https://datatracker.ietf.org/doc/html/rfc7489). A message can pass SPF on its own and still fail DMARC if the domain SPF authenticated does not align with the visible From header domain. DMARC's policy tag then decides what a receiver does with that outcome, not SPF's pass or fail result by itself. ### Why did SPF cause my mail to be rejected? SPF failure by itself does not usually reject a message; most mailbox providers act on a domain's own DMARC policy after an SPF or DKIM failure, not on SPF alone. Two SPF-specific causes are common: the lookup count exceeded the RFC 7208 ceiling of 10, which returns a PermError treated as a fail, or a sending service was added without updating the record's `include` mechanism, so its sending IP is no longer listed. Reading the exact message from your own mail logs alongside the record narrows down which one applies. ### How does EasyDMARC work? EasyDMARC scans a domain's SPF, DKIM, and DMARC records from its homepage and returns a Risk Assessment Level of Low, Medium, or High plus a DMARC Policy score out of 10. From there it sells remediation products for what the scan finds, including EasySPF for flattening an SPF record past the lookup limit, managed DKIM, and reputation monitoring, according to [EasyDMARC's own product pages](https://easydmarc.com). ### Does EasySPF fix a record that is already over the lookup limit? Yes. EasyDMARC describes EasySPF as performing "a one-time DNS configuration" that "dynamically flattening the record, converting domain includes into IP addresses," according to [its product page](https://easydmarc.com). That approach removes the includes causing the extra lookups, though a flattened record needs to be regenerated later if one of the underlying services changes its sending IP ranges, since the record no longer references the include dynamically.