Synthetic Industry

Free tool · updated 2026-10-11

SPF, DKIM and DMARC record checker: read your pasted records against the RFCs

Paste your SPF, DMARC and optional DKIM key records as text and get specific findings, each with the RFC section behind it. No DNS lookups; nothing leaves your browser.

What you paste and what you get

Paste the text of your SPF record, your DMARC record and, if you have one, a DKIM public-key record. Choose Check the records. You get a parse of each one and a list of findings, worst first. Every finding says what the record contains, what the standard says about it and which section of which RFC that statement rests on, so you can check the reasoning yourself.

Nothing is looked up. The tool reads exactly the text you give it, which means it can be used on a record you are about to publish as well as one that is already live.

  • SPF: the version tag (including a tab or non-breaking space after it, which stops the line being an SPF record), each term, how many terms cause DNS lookups against the limit of 10, whether more than one SPF record was pasted, whether all is present, last and which qualifier it has, and whether the deprecated ptr is used.
  • DMARC: each tag and whether its value is valid, the effective policy and how strong it is, and the defaults that apply to the tags you left out.
  • DKIM: the version, key type and tags, and for an RSA key the actual bit length of the modulus, worked out from the key itself.

How the findings are decided

SPF. A record is only an SPF record if it begins with exactly v=spf1; more than one such record is an error (RFC 7208 section 4.5). The terms include, a, mx, ptr and exists, and the redirect modifier, each cost one DNS lookup, and an implementation must limit the total to 10 during evaluation and return permerror beyond it (section 4.6.4). Evaluation goes term by term, so a sender matched before the 11th lookup term can still pass, while any evaluation that reaches the 11th ends in permerror, which includes every sender not matched earlier. The tool counts the terms in the record you paste. It cannot open an included record, so when an include or redirect is present the count shown is a minimum and the tool says so. Anything after an all is ignored, and a redirect next to an all is ignored and costs no lookup (sections 5.1 and 6.1).

DMARC. The record must start v=DMARC1 followed by p, and a record that does not is ignored completely (section 6.3). The policy is described in the words of the RFC: none asks for no specific action, quarantine asks for the mail to be treated as suspicious, reject asks for it to be refused. A pct below 100 is reported as partial enforcement, because the policy is requested for only that share of failing mail (section 6.6.4). Mail that is not selected is treated as though quarantine applies when the policy is reject, and gets the receiver's normal local classification when the policy is quarantine, so applying that rule to pct=0 (which selects no mail), p=reject behaves like quarantine, not like having no policy. The RFC does not single out pct=0; the tool says so in its finding.

DKIM. The p value is decoded from base64 and read as a DER RSA public key, which gives the modulus length directly. RFC 8301 section 3.2 sets the floor at 1024 bits and recommends 2048, so a 1024-bit key is reported as meeting the minimum but below the recommendation. An Ed25519 key is checked for the 32-byte size that RFC 8463 describes.

  • A finding is marked Problem when the RFC says the record or term is invalid, ignored or gives an error result.
  • It is marked Check when the record is valid but the RFC advises against it, or it weakens the protection the record seems to give.
  • It is marked Note for facts worth knowing, and OK for a check that passed.

What this cannot know

It checks the text, not your mail system. It cannot tell you what is actually published in DNS right now, which services send mail as your domain, whether any of them is missing from your SPF record or has no DKIM key, or whether a real message passes and lines up with its From domain. That last one, called alignment, can only be read from the Authentication-Results header of a message you received. It cannot tell you what a receiving provider will do, and a passing result is not a promise of inbox placement.

The DNS lookup limit is the clearest example. An SPF record can look short and still be over the limit once the records it includes are counted. If the tool shows a minimum, treat the true total as higher and test the live record with a lookup-counting service or with your mail provider's own checker.

  • A record that looks valid here can still be wrong for your business if it omits a sender.
  • Do not move a DMARC policy to quarantine or reject because this tool reports no problems; check the aggregate reports first.
  • Receivers may be more lenient or stricter than the RFC text; where a finding depends on that, it says so.

Privacy and scope

Everything you paste is processed by this page in your browser. It is not sent anywhere, not stored, and not added to a web address. A DKIM record holds only a public key, which is meant to be public. If you paste something that looks like a private key into any of the three boxes, as a key file or as bare base64, the tool refuses to read it, says why, and clears that box without repeating any of it: never paste a private key into any website.

The tool does not change your DNS and cannot confirm a fix worked. It is a reading aid for records you already have.

If you want this done for you

The linked outcome covers inventorying the services that send as your domain, writing one SPF record within the lookup limit, DKIM for the agreed senders and a monitoring DMARC policy, then checking real test messages. Scope and price are agreed before any work. Send your domain and the providers involved, not passwords or private keys.

Use the tool

Sources and limits

  • Checker implementation and tests Checked 2026-10-11.
    • The checker parses only the text pasted into it and performs no DNS lookup, network request or storage.
    • Every finding carries the RFC section it is based on.
  • RFC 7208: Sender Policy Framework (SPF), version 1 Checked 2026-10-11.
    • Only records beginning with exactly v=spf1 are SPF records, and the version section is terminated by either an SP character or the end of the record; none gives the result none and more than one gives permerror (section 4.5).
    • The include, a, mx, ptr and exists mechanisms and the redirect modifier cause DNS queries; an implementation must limit their total to 10 during evaluation and return permerror beyond it. The all, ip4 and ip6 mechanisms and the exp modifier are not subject to the limit (section 4.6.4).
    • The ptr mechanism should not be published (section 5.5).
    • Mechanisms after all must be ignored (section 5.1), and a redirect is ignored if all is present anywhere in the record (section 6.1).
    • An omitted qualifier means + (section 4.6.2); with no match and no redirect the result is neutral (section 4.7).
    • Several strings in one TXT record are concatenated without spaces (section 3.3); a record should stay small enough to fit a 512-octet answer, with 450 octets as the guideline (section 3.4).
    • Redirect and exp must not appear more than once each; unrecognised modifiers are ignored (section 6).
  • RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) Checked 2026-10-11.
    • DMARC records are TXT records at _dmarc.<domain> (section 6.1).
    • The v tag must be first with the value DMARC1, and v then p must be present in that order; unknown tags are ignored (section 6.3).
    • The tags are v, p, sp, rua, ruf, adkim, aspf, pct, fo, rf and ri, with defaults including pct 100, adkim r, aspf r and sp falling back to p (section 6.3).
    • With more than one DMARC record, policy discovery ends and DMARC is not applied; a missing or invalid p is treated as p=none only if a valid rua exists (section 6.6.3).
    • Receivers apply pct as a statistical approximation and may deviate from the published policy (sections 6 and 6.6.4).
    • Mail not selected by pct under a reject policy should be treated as though quarantine applies, and mail not selected under a quarantine policy should get local message classification as normal (section 6.6.4).
    • A report address at a different organizational domain needs a TXT record at <policy-domain>._report._dmarc.<destination> (section 7.1).
  • RFC 6376: DomainKeys Identified Mail (DKIM) Signatures Checked 2026-10-11.
    • A key record's tags are v, h, k, n, p, s and t; v if present must be first and equal DKIM1; p is required and an empty p means the key is revoked; the default k is rsa (section 3.6.1).
    • The t=y flag marks testing, and verifiers must not treat such messages differently from unsigned email (section 3.6.1).
    • Keys are TXT records at <selector>._domainkey.<domain>, and several strings in one record are joined with no whitespace (section 3.6.2).
  • RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM Checked 2026-10-11.
    • Signers must use RSA keys of at least 1024 bits and should use at least 2048; verifiers must handle 1024 to 4096 bits and must not accept signatures made with keys under 1024 bits (section 3.2).
    • rsa-sha1 must not be used for signing or verifying (section 3.1).
  • RFC 8463: A New Cryptographic Signature Method for DKIM Checked 2026-10-11.
    • An Ed25519 key record uses k=ed25519, and its p value is the 256-bit public key in base64, 44 characters long (sections 3 and 4.2).