SPF, DKIM, and DMARC explained

By the zmam.ai team ·

On this page

Email was designed in an era of trust. The protocol that carries it, SMTP, will happily let any server claim to be sending mail from any address — there is nothing in the original design that stops a stranger from writing your name in the “From” line. Everything we now call email authentication is a set of patches bolted on afterward to answer one question the protocol never asked: is this message really from who it says it is?

Three records answer it, and they live in your DNS where anyone can read them — including the attacker deciding whether your domain is worth impersonating.

SPF: who is allowed to speak for you

SPF (Sender Policy Framework) is a public list of the servers permitted to send mail for your domain. When a message arrives, the receiving server looks up your SPF record and checks whether the sending server is on it. A typical record reads:

v=spf1 include:_spf.google.com include:servers.mcsv.net -all

The include: entries delegate trust to other senders — your mail provider, your newsletter tool. The -all at the end is the part people get wrong: it means “reject anything not on this list.” Ending instead with ~all (soft fail) or omitting it entirely tells receivers to shrug at unauthorized mail.

SPF also has a famous limit: a record may trigger at most ten DNS lookups while it expands all those include: chains. Exceed it and the whole record collapses into an error that receivers treat as failure. And because include: delegates trust to a domain you do not control, a forgotten include: pointing at an expired domain is a live takeover risk — the exact mechanism behind the SubdoMailing campaign , which sent millions of fully SPF-authenticated spam messages a day from brands that had simply stopped tidying their records.

Precision note. SPF authorizes sending hosts for the SMTP envelope (MAIL FROM / HELO) identity — it does not, on its own, prove the visible “From” address a person reads. DMARC alignment is what ties an SPF or DKIM pass back to that visible domain.

DKIM: a tamper-proof seal

SPF says where mail may come from; it says nothing about whether the message was altered. DKIM (DomainKeys Identified Mail) fills that gap. Your mail server signs each outgoing message with a private cryptographic key; the matching public key sits in your DNS. The receiver verifies the signature and learns two things: the message genuinely came from your domain, and its signed contents were not changed in transit. DKIM is the part that survives most forwarding, which is why the next record leans on it.

DMARC: the policy that makes the other two matter

SPF and DKIM are mechanisms. DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy that tells receivers what to do when they fail, and asks them to send you reports. A record looks like this:

v=DMARC1; p=reject; rua=mailto:[email protected]

The policy escalates in three steps:

DMARC’s real power is alignment: it requires the domain a human sees in the “From” line to match the domain that SPF or DKIM actually validated. That is what defeats look-alike impersonation, because an attacker cannot align a domain they do not control.

Why this is no longer optional

For years a weak email setup was a quiet liability. As of 2024 it is an operational one: Google and Yahoo began requiring SPF, DKIM, and DMARC from bulk senders, and through 2025 Microsoft followed and Gmail moved from deferring non-compliant mail to outright rejecting it. The inbox now checks IDs at the door. A domain with no DMARC is not just easier to forge — its legitimate mail is increasingly likely to bounce.

How zmam.ai helps

When zmam.ai reviews a domain it reads the public SPF, DKIM, and DMARC records and flags the failures that matter: a missing DMARC policy, a ~all that should be -all, an SPF record drifting past the ten-lookup limit, or a policy still parked at p=none long after setup. Every check reads public DNS only — nothing is sent, no mail is touched.