SPF, DKIM and DMARC checks

Every domain scan reads the three authentication records and grades each Pass, Review or Fail with a one-line explanation. A record marked Review shows the record to publish: the most secure one the evidence supports.

SPF

The scan reads the v=spf1 TXT record at the apex and analyses it:

• Lookup count. SPF fails with a permanent error when it needs more than 10 DNS lookups, or more than two lookups that return nothing (RFC 7208, section 4.6.4), so legitimate mail fails. The page shows how many of the ten you have used; 8 to 10 is Review, and over 10 (or more than two void lookups) is Fail with "flatten or remove includes" as the fix. See Managed email authentication for SPF flattening.
• Policy strength. ~all (soft fail) and -all (hard fail) both Pass. We recommend ~all: with DMARC in place the receiver acts on your DMARC policy, and a soft fail does not bounce forwarded mail or a sender you have not listed yet. ?all is Review and +all is Fail because it authorises everyone. A domain that sends no mail at all publishes v=spf1 -all.
• Provider coverage. Whether the record includes the sending provider the MX records point at (Microsoft 365, Google Workspace, and others).

DKIM

DKIM keys live at <selector>._domainkey.<domain>. The scan tries the selectors used by the mail provider it detected (for example Microsoft's selector1 / selector2, Google's google) and reports the selector found and whether the key is present. An RSA key under 1024 bits, which RFC 8301 forbids, is flagged with advice to rotate to 2048 bits; 1024-bit, 2048-bit and Ed25519 keys pass. A revoked or invalid key is Fail. When no key answers on any selector the scan tried, the row is Review ("No DKIM key answered for any selector the scan probed"), not Fail, because the provider may use a selector the scan cannot guess. When the lookups themselves get no definite answer, the row says DKIM could not be checked.

DMARC

The _dmarc TXT record is parsed into its policy (p=), the subdomain policy, the percentage (pct=), alignment modes, and the report addresses (rua=, ruf=).

When DMARC needs fixing the page shows two records, each labelled: p=reject, the most secure and the one to move to once every sender passes SPF or DKIM, and p=none, the safest way to start because nothing is blocked while you watch the reports. Both carry the account's report address in rua=. Each has a Copy button.

Where

• Web: the Email authentication row on a domain's Overview tab, and Security, Overview, the Email authentication table for every domain. A broken record is also listed under Fixes.
• iOS: Email & DMARC, three cards; tap one for the record exactly as published, the breakdown, and the record to publish.
• API/MCP: GET /api/domains/:id/email-security returns a fresh read of SPF, DKIM, DMARC, MX, MTA-STS, TLS-RPT and BIMI; the get_domain_email_security tool does live lookups and so counts as a write.

A domain that sends no mail

A domain with no MX and no SPF is graded "mail not configured", not as a failing domain. If it genuinely sends no mail, set Ignore mail in its scan settings and publish v=spf1 -all plus a p=reject DMARC record so nobody else can send as it either.

Common questions

My SPF has 9 lookups and the page says Review. Nine is within the limit, but anything from 8 up is close enough that one more include breaks it; the Review is a warning to flatten before that happens.

DKIM says no key answered. The scan could not guess the selector. The record may be fine; the MX provider's documentation names the selector, and DMARC reports will show DKIM passing if it is.

Which DMARC record should I paste? Start with p=none if you have never had DMARC, watch the reports for two weeks, then move to p=reject once 95% of mail aligns. See DMARC setup and diagnostics.