SPF · DKIM · DMARC
validated in 3 seconds.

The validator returns three blocks: SPF, DKIM, and DMARC. Each block has a status pill (pass, warn, or fail), a parsed record breakdown, and specific findings if anything looks off. Here's what to look at first in each block, and what each common finding actually means for your deliverability.

SPF block: lookup count is the trap.

SPF rules cap the number of DNS lookups during evaluation at 10. This includes every include:, a, mx, ptr, and exists: mechanism, plus any nested lookups they trigger. A record that looks short can blow past 10 if your includes chain into more includes; some ESPs (notably older Mailchimp configurations and some Microsoft 365 setups) are known offenders. If the validator shows your record exceeding 10, receivers will return PermError and DMARC will treat SPF as failed regardless of whether the sending IP is actually in the chain.

The fix is flattening: replace include: mechanisms with the IP ranges they resolve to, eliminating the lookup. Flattening creates a maintenance burden (when your ESP rotates IPs, your flat record breaks), so use flattening services that re-resolve and update DNS daily, or only flatten the includes that haven't changed in 12+ months.

~all (soft fail) versus -all (hard fail) is the second SPF judgment call. Hard fail tells receivers to reject mail from IPs not on the list; soft fail asks them to mark it suspicious. In production we recommend -all once you're confident your record covers all legitimate sending sources. ~all is appropriate during initial deployment when you're not yet sure you've enumerated every sender.

DKIM block: selector availability and key length.

DKIM is selector-scoped. The validator checks selectors common in the wild (default, google, k1, s1, mailo, selector1/2 for Microsoft 365, dkim, mxvault, and others) plus any selector you specify. A missing selector record is not necessarily a failure; it just means that selector isn't being used. A failure is when a selector record exists but is malformed (broken base64, missing p= tag, unsupported algorithm).

Key length below 1024 bits is now considered weak; below 768 bits, receivers may ignore the signature entirely. We recommend 2048-bit RSA keys for new deployments. If your validator shows 1024-bit keys, it's not an immediate failure but should be on your rotation schedule.

DMARC block: policy alignment and reporting.

DMARC requires either SPF or DKIM to pass with the result aligned to the From: header domain. Alignment is the subtle part: SPF can pass on the envelope sender domain but fail alignment if your envelope sender uses a different domain than the From: header. ESPs sometimes send via bounce.example.net while messages appear to come from example.com, breaking alignment unless the ESP signs with DKIM aligned to example.com.

DMARC policy progression: p=none for monitoring, p=quarantine for soft enforcement, p=reject for full enforcement. Don't jump to p=reject without first running p=none with reporting (rua= tag) for at least 14-30 days; reports will show legitimate senders you didn't know about and your p=reject would have blocked them.

DMARC aggregate reports (the rua reports) are sent daily by major receivers to the mailbox specified in the rua tag of your DMARC record. The reports arrive as XML attachments documenting all the mail that receivers observed claiming to be from your domain during the previous 24-hour window, including authentication results for each source.

For domains starting from p=none, the first 14-30 days of reports typically reveal more sending sources than the operator was aware of. Common surprises: third-party marketing platforms that the marketing team set up without informing IT, transactional email vendors (Postmark, Mailgun, SendGrid) that legacy applications were configured to use, CRM platforms with built-in email functionality, internal forwarding from satellite-office mail servers, customer-service desk tools that send notification emails. Each of these needs either explicit authorisation in SPF/DKIM or migration to authorised infrastructure before DMARC can move to p=quarantine without affecting legitimate mail.

The processing pattern that most operators settle on: aggregate reports flow to a dedicated mailbox, automated parsing runs daily (DMARC XML is well-documented; many open-source tools exist), the parsed data flows into a dashboard showing pass/fail rates per source and over time. Trends matter more than individual reports: a single failure event is often noise (a misconfigured forwarder, a transient DNS issue, a one-off transactional mail problem); sustained failures from a specific source indicate a real configuration issue that needs to be addressed before DMARC enforcement increases.

For operators without dedicated DMARC tooling, the minimum viable processing is forwarding the reports to one of the commercial DMARC dashboards (DMARC Analyzer, Valimail, Dmarcian, Postmark) that handle parsing and dashboard rendering. These cost USD 50-500 monthly depending on volume and feature requirements. For operators with engineering capacity, self-hosted parsing (such as ParseDMARC, the open-source DMARC tool from DomainTools) is operationally cheap and produces equivalent visibility. The choice typically comes down to whether the operator prefers a managed service or a self-hosted pipeline; both produce the same outcome for most operational use cases.