How to read an SPF, DMARC or DKIM record

The analyzer reads the pasted record as text and checks it against the rules of its own specification: SPF mechanisms and modifiers (RFC 7208), DMARC tags (RFC 7489) and DKIM key records (RFC 6376, updated by RFC 8301). Each finding names the rule that the line breaks.

Nothing is queried and nothing is verified: no DNS lookup is made, no message signature is checked and no delivery is tested. A record that passes here is consistent text; whether it matches what the domain really publishes still has to be confirmed at the DNS level.

Paste the value of the TXT record, or press Load example. Keep the v= tag and the quotes as they are published.
Leave the type on Auto-detect, or choose SPF, DMARC or DKIM when the record is ambiguous.
Press Analyze locally. The report shows findings, a table of the record’s terms or tags, and counters such as the SPF lookup budget written as x / 10.
Read the table next to the findings: the qualifier and the note repeat what was flagged, and the JSON view carries the same data into a ticket.
Fix the record in the zone editor, wait for the TTL to pass, then paste it again to confirm the change.

What each record type must contain

What the SPF report counts

Mechanisms are read in order with their qualifier (+ pass, - fail, ~ softfail, ? neutral), and a record is not required to end in all: without it, or with a redirect=, the result of an unmatched host depends on the values you did provide.

The ten-term budget of RFC 7208 covers include, a, mx, ptr, exists and redirect. ip4, ip6, all and exp do not count, and duplicated terms count again. Mechanisms written after all are listed, but they never run.

DMARC tags that change behaviour

v=DMARC1 has to come first, and p= (none, quarantine or reject) is what receivers act on; sp= sets the policy for subdomains, and pct= limits the share of mail it is applied to.

rua= and ruf= take URIs, normally mailto: addresses. adkim and aspf accept r or s, fo only matters together with ruf=, rf only defines afrf, and tags that DMARC does not define are ignored instead of failing the record.

DKIM keys and what makes them usable

A key record is published per selector: v=DKIM1 first, k= named as rsa or ed25519, and p= holding the public key as base64. An empty p= is not a mistake, it revokes the key.

RFC 8301 sets the crypto floor: a key below 1024 bits cannot produce a valid signature, 2048 bits is the recommended size, and SHA-1 must not be used at all. The s= tag has to include email, and t=y declares testing mode.

What a text check cannot see

SPF include chains, DMARC alignment and DKIM selector records are resolved by DNS at delivery time. The analyzer can only judge the text in front of it, so a missing warning is not a guarantee that a domain sends authenticated mail.

The DKIM key record also depends on the selector: paste the record from the selector actually used for signing (for example selector1._domainkey), not the domain root.