SPF, DKIM and DMARC: What the Three Records Actually Prove

SPF, DKIM and DMARC are three DNS records that let a receiving mail server check whether a message was authorised to use your domain. That is the whole of what they do. They are an answer to forgery, not a route to the inbox, and the three specifications say so themselves.

They are also three separate documents, written years apart by different people. SPF is RFC 7208, Standards Track, April 2014. DKIM is RFC 6376, Standards Track, September 2011. DMARC is RFC 7489, published March 2015 as an Independent Submission and marked Informational — it is not an IETF standard at all.

The disclosure first. We build Keaz Signals, which sells ecommerce buying signals and sends outreach through the customer's own Instantly workspace. We are not a deliverability vendor, we do not sell domain warmup, and we do not manage anyone's DNS. That is the reason this post can describe the three records plainly: there is nothing here we are trying to sell you.

A pass proves authorisation and responsibility, and stops there. RFC 7208 is unusually direct about it. Section 8.3 defines the result:

A "pass" result means the client is authorized to inject mail with the given identity. The domain can now, in the sense of reputation, be considered responsible for sending the message.

Read the second sentence slowly. A pass makes your domain responsible for the message. It attaches the send to you. If the mail is unwanted, SPF has not protected you from that judgement — it has made sure the judgement lands on your domain rather than on a shared IP address. RFC 7208's introduction gives that as the benefit: receivers can make decisions based on the sender's domain rather than the host's IP, because domain reputation is more stable.

DKIM works differently and lands in the same place. RFC 6376's abstract describes it as a way for the owner of a signing domain to "claim some responsibility for a message by associating the domain with the message", validated by a cryptographic signature. Claiming responsibility is the function. Nothing in the signature asserts that the message is welcome, useful, or solicited.

So the two records answer one question — may this sender use this domain — and hand the answer to something else to act on.

No, and the specification says so in its own abstract. RFC 7489 states:

DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection.

Every verb in that sentence points downward. DMARC is a way of telling receiving servers how harshly to treat mail that fails — nothing, quarantine, or reject. There is no corresponding upward setting. A published DMARC policy cannot ask for better treatment, and by the document's own words it does not earn any.

What DMARC adds on top of the other two is alignment and reporting. It ties the domain a human actually sees in the From header to the domain that SPF or DKIM authenticated, which closes the gap where a message passes SPF for one domain while displaying another. And it asks receivers to send aggregate reports back, which is where the operational value sits: you find out that something is sending as you.

Worth knowing when you are weighing advice about it: DMARC is Informational, an Independent Submission rather than an IETF consensus document. It is near-universally deployed in practice, and it is not a standard in the sense SPF and DKIM are.

Most articles on this keyword end with a number: configure these three records and reach the inbox some stated percentage of the time. We are not going to give you that number, and the reason is simple. We did not measure it.

We could not measure it honestly even if we wanted to. Inbox placement is decided per recipient, per mailbox provider, per domain, against filtering rules that are not published and change without notice. A figure produced from our own sending would describe our domains and our content on the days we tested, and would tell you nothing reliable about yours.

The same restraint applies to the mailbox providers' own rules. Google and Microsoft both publish sender requirements, and those pages are the only authority worth quoting on what they currently demand — but they change, and we could not retrieve and verify their current text at the time of writing. So this post does not paraphrase them. Go and read them directly rather than trusting a third party's summary, this one included.

What is safe to say is structural, and it is the point of the whole post: authentication is a precondition, not a result. Without the records, well-run receivers have a reason to treat you harshly. With them, you have removed a reason to be rejected — and acquired a domain-level identity that now carries the consequences of everything you send.

Every fact the three records carry is a fact about the sender. Your domain, your authorised hosts, your signing key, your policy. Nothing in SPF, DKIM or DMARC describes the recipient, and no amount of DNS hygiene answers the question that decides whether a cold email works: does this store have a reason to hear from you this week?

That evidence comes from watching what stores do, not from resolving a TXT record. A store that just switched on Meta ads, launched a product or installed Klaviyo has a reason that did not exist a fortnight ago. Those are the events in our buying signal catalogue, and what our AI sales agent writes the first line from.

Both halves are required and neither substitutes for the other. Authentication without relevance is a well-formed message nobody wanted. Relevance without authentication is a good message that may never be trusted enough to be read. Fix the records once; earn the relevance every time.

Authentication and reputation are two systems that get discussed as one. The three records assert authorisation, once, in DNS. Reputation is the running judgement mailbox providers form about your domain over time, and it is reported separately — which is why reading Google Postmaster Tools is a separate job from publishing a DMARC record, and why deliverability tools watch something the records never see.

The order matters. Records first: cheap, one-time, checkable. Reputation after, because it only accumulates once you are sending — against the domain the records made responsible.

Then spend your attention on who you are writing to. If that is ecommerce stores, the ecommerce leads database covers 4.1M stores as of September 2026, and the first 1,000 leads are free.

• RFC 7208, Sender Policy Framework (SPF), Version 1 — Standards Track, April 2014. Introduction and section 8.3 quoted. Retrieved 14 September 2026.
• RFC 6376, DomainKeys Identified Mail (DKIM) Signatures — Standards Track, September 2011. Abstract quoted. Retrieved 14 September 2026.
• RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC) — Informational, Independent Submission, March 2015. Abstract quoted. Retrieved 14 September 2026.