Loading DMARC & SPF Record Explainer…
Paste the record itself, not the domain. Nothing is resolved and nothing leaves this tab, so this reads what you give it and never checks what you have actually published — which is also why it cannot follow an include: or confirm a reporting address.
Paste a record above and it is taken apart here.
allno lookupMatches every sender, so it sets the result for anything the earlier terms did not match. It belongs last: terms after it are never evaluated.includeDNS lookupEvaluates another domain’s SPF record and matches if that record passes. It is a cross-reference, not a textual paste, and each one costs a DNS lookup — plus every lookup inside it.aDNS lookupMatches if the sending address is one of the A or AAAA records of the domain — this domain unless another is named.mxDNS lookupMatches if the sender is one of the domain’s mail exchangers. Servers that receive your mail are not necessarily the ones that send it.ptrDNS lookupMatches on the reverse DNS of the sending address. The specification heads this section “ptr (do not use)” and says it SHOULD NOT be published: it is slow, it loads other people’s DNS, and the answer is controlled by whoever owns the address.ip4no lookupMatches an IPv4 address or CIDR block literally. Costs no DNS lookup, which is why a record that has outgrown the limit is usually rewritten in terms of these.ip6no lookupMatches an IPv6 address or prefix literally, and likewise costs no lookup.existsDNS lookupMatches if a name built from the connection resolves to anything at all. Used with macros for per-sender or per-address rules.redirectDNS lookupHands the whole decision to another domain’s record. It is ignored entirely if the record also has an all mechanism, wherever the two appear relative to each other.expno lookupNames a record holding the human-readable explanation returned with a fail. It is only fetched after a fail, so it does not count against the lookup limit.+passthis sender is authorised. The default when no qualifier is written.-failthis sender is not authorised, and the receiver may reject the message outright.~softfailprobably not authorised. The receiver is asked to accept but mark it, which is what most published records end with.?neutralno assertion either way, treated exactly as if no record existed.vactiveThe version, which must be the first tag and must read exactly DMARC1, case-sensitively. If it is missing, misspelled or not first, the whole record must be ignored — and a domain whose record is ignored has no DMARC at all.pactiveWhat you ask receivers to do with mail that claims to be from your domain and fails. If it is absent from an otherwise valid record, the record is read as p=none.spactiveThe same choice, for existing subdomains. Absent, subdomains inherit p — which is usually what you want, and occasionally a surprise for a subdomain used by a supplier.npactiveThe policy for subdomains that do not exist at all. Nothing legitimate is ever sent from a name with no DNS record, so np=reject costs nothing and closes a favourite trick.ruaactiveWhere aggregate reports go, as a comma-separated list of URIs — in practice mailto: addresses. Without it, receivers must not send aggregate reports, and you are publishing a policy with no way to see what it is doing.rufactiveWhere per-message failure reports go. These carry parts of real messages, which is why far fewer receivers send them and why the address needs to be treated as holding personal data.adkimactiveHow closely the DKIM signing domain must match the visible From domain. Relaxed by default, which lets a subdomain sign for the parent; strict requires an exact match.aspfactiveThe same question for SPF: whether the envelope sender’s domain must match the From domain exactly, or only share an organisational domain.foactiveWhich failures are worth a failure report. It has no effect at all unless ruf is also set, and 0 and 1 cannot both be given.tactiveTest mode. t=y asks receivers to apply one step less than the policy says — quarantine instead of reject, none instead of quarantine — while still sending reports. It is the tag that replaced what people were really using pct=0 for.psdactiveWhether this record belongs to a public suffix domain. Almost nobody publishing for an ordinary domain should set it; the default u lets the tree walk work it out.pcthistoricThe old sampling percentage. RFC 9989 registers it as historic: implementations applied it inconsistently for every value except 0 and 100, and the useful half of it became the t tag.rfhistoricThe failure report format. Registered as historic — there was only ever one format anybody produced.rihistoricThe requested interval between aggregate reports. Registered as historic; receivers send daily and always did.SPF follows RFC 7208, which is still the current specification. DMARC follows RFC 9989, published in May 2026, which obsoletes RFC 7489 and RFC 9091 and moves aggregate reporting to RFC 9990 and failure reporting to RFC 9991. That is why pct, rf and ri are shown here as historic and t is not: the tag registry changed. Specs read 2026-08-17. Nothing in this tool queries DNS, so it can tell you what a record says and never whether it is the record you have published.
SPF is a list of the machines allowed to send mail carrying your domain in the envelope. A receiver compares the connecting address against the mechanisms in the record, left to right, and stops at the first match. DMARC asks something else entirely: does the domain a human actually sees in the From line match a domain that passed SPF or signed with DKIM, and what would you like done about it when neither holds?
That distinction is the reason a domain can pass SPF on every message and still be trivially spoofable. SPF checks the envelope sender, which nobody reads; DMARC is what ties the result back to the visible header and gives the receiver an instruction. Publishing one without the other is half a system.
A policy of none asks receivers to do nothing whatsoever with mail that fails. It exists for a good reason — it turns on the aggregate reports that tell you which of your own mail streams are misconfigured before you start refusing anything — and it is where deployments go to stop. The record is published, the dashboard is green, the domain appears authenticated, and anybody in the world can still send mail as it, because nothing was ever asked of anyone.
The reports are the point of that stage, not the record. If there is no address to send them to, none is not monitoring; it is silence with extra DNS. The path out is the same one every time: read the reports until you recognise every sender, fix or remove the ones you do not, then move the policy to quarantine and later to reject, with subdomains and non-existent subdomains handled explicitly rather than left to inherit.
Six kinds of term make a receiver query DNS while evaluating a record, and the total across the whole evaluation may not exceed ten. Go over and the result is a permanent error, which means the record stops protecting the domain rather than degrading gracefully. Address literals cost nothing, which is why a record that has outgrown the limit is usually rewritten in terms of them.
The trap is that the limit counts the whole evaluation, not the record in front of you. Each cross-reference to another provider brings that provider’s record with its own terms, and a chain three deep can consume the budget from four visible entries. Nothing on this page resolves anything, so it counts what it can see and says so instead of pretending to a total it cannot know.
DMARC spent a decade as an informational document. In May 2026 it became a standards-track specification that obsoletes the old one, and three tags went with it: the sampling percentage, the report format and the report interval are all registered as historic. Percentages were applied inconsistently by everyone except at nought and a hundred, so the useful half of that behaviour became a plain test-mode flag instead.
Records written before the change are still valid — unknown and deprecated tags are ignored rather than treated as errors — but a record carrying them is a record nobody has revisited in years. Reporting also moved into its own documents, which is where the requirement lives that a third-party report address must publish an authorisation record of its own before anything will be sent to it.
No. A receiver that finds more than one returns a permanent error and the check fails outright, which is worse than having none at all. Merge the mechanisms into a single record, and mind the lookup budget when you do.
A soft fail asks the receiver to accept the message and mark it as suspicious; a hard fail asks it to refuse. Most published records use the softer form because a forwarded message breaks the check through no fault of the sender.
It can. A list that rewrites the subject or appends a footer invalidates the signature, and the message then fails alignment. Well-behaved lists rewrite the From header to their own domain to avoid exactly this, and most large ones now do.
Rarely. Aggregate reports are counts and addresses, which is what you need to find a broken sender. Failure reports carry parts of individual messages, so they arrive from far fewer receivers and bring a data protection question with them.
No, and that is deliberate. It reads the text you paste and makes no DNS query at all, so it can tell you what a record says and never whether that record is the one live in your zone.