These three acronyms decide whether your cold email reaches the inbox or gets rejected before anyone reads it, and most explanations of them are written for network engineers. This one is not. Here is what each record actually does, how they work as a set, the mistakes that break them without any visible error, and how to check your own domain in about a minute.
Think of a receiving mail server as a bouncer checking IDs. SPF is the guest list: the domain publishes which servers are allowed to send on its behalf. DKIM is a tamper-proof seal: each message carries a cryptographic signature the receiver can verify, proving the message was not altered in transit and really came from the domain. DMARC is the house policy: it tells the bouncer what to do when a message is not on the guest list and has no valid seal, and it asks the venue to send the domain owner a report of everything that failed. SPF and DKIM do the checking; DMARC decides the consequence and gives you visibility.
SPF (Sender Policy Framework) is a single DNS TXT record listing the servers authorized to send email for your domain. When a message arrives, the receiver checks whether the sending server is on that list. It looks like v=spf1 include:_spf.google.com ~all, where the includes name the services allowed to send, and the ending tells the receiver how strict to be.
Two things silently break SPF, and neither shows up as an obvious error:
+all. The ending qualifier matters enormously. -all hard-fails unlisted senders, ~all soft-fails (the practical norm), but +all authorizes every server on the internet to send as you, which is worse than having no SPF at all, because forgeries then pass.DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every message, generated with a private key only you hold. The matching public key lives in your DNS. The receiver uses it to confirm two things: the message genuinely came from your domain, and it was not modified in transit. It is the strongest of the three signals because it is expensive to forge.
The catch that trips up most checkers is that DKIM has no fixed location. The record lives at <selector>._domainkey.yourdomain.com, and the selector is chosen by whoever set up sending, so it cannot be guessed reliably. Google Workspace is the classic example: its default selector is a rotating date string, so a checker trying common names finds nothing even though DKIM is working perfectly. A "DKIM not found" result almost always means "not found at the names we tried", never "not there". Two real problems to watch for, per RFC 6376: an empty p= tag explicitly revokes the key (a checker that only tests whether p= exists will call a revoked key healthy), and keys under 1024 bits are considered forgeable.
DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM and does two jobs. First, it sets a policy for messages that fail both: p=none monitors and does nothing, p=quarantine sends failures to spam, and p=reject blocks them. Second, it asks receivers to send you aggregate reports (via a rua= address) so you can see which of your mail is passing and which is failing.
Two DMARC subtleties matter for cold senders on subdomains:
sp= tag governs subdomains (falling back to p= if sp= is absent). This is defined in RFC 7489 section 6.6.3, and it is the normal, correct setup, not a gap.pct= trap. p=reject; pct=10 only enforces the reject policy on 10% of failing mail and delivers the rest as if the policy were none. It looks like strong protection and is close to none in practice.Here is the piece almost every plain-English guide leaves out. DMARC does not just check that SPF or DKIM passed; it checks that the domain they passed for aligns with the domain in your visible From: address. A message can pass SPF for some intermediary's domain and still fail DMARC because that domain does not match your From:. This is exactly why Google's bulk-sender rules require From: alignment specifically, and why "we set up SPF and DKIM" is not the same as "we pass DMARC". Alignment is the bridge that makes the other two enforceable.
p= tag from a half-finished migration leaves a key that fails every signature.Our grader reads your live records, walks the full SPF include chain against the 10-lookup limit, catches revoked DKIM keys, resolves inherited DMARC, and scores the setup A to F. No signup.
Set up well, the three form a chain: SPF says the server was allowed to send, DKIM proves the message arrived unaltered from your domain, and DMARC confirms both align with your visible From: address and tells the receiver to trust it, while reporting anything that does not. Break any link and the chain weakens; break DMARC alignment and the other two stop being enforceable. This is the configuration Gmail, Yahoo, and Outlook now expect, and it is the baseline every cold sender has to clear before warm-up or list quality even enters the picture.
They are three DNS records that prove your email is really from you. SPF lists which servers are allowed to send mail for your domain. DKIM adds a tamper-proof cryptographic signature to each message so the receiver can confirm it was not altered and came from your domain. DMARC ties the two together: it tells receivers what to do when a message fails SPF and DKIM, and asks them to send you reports on what is failing. Together they are how Gmail and Outlook decide whether an unknown message is genuinely from your domain or a forgery.
For cold email and any serious sending, yes. SPF and DKIM alone were enough for years, but Google and Yahoo now require all three from bulk senders, and DMARC is what makes SPF and DKIM actually enforceable through alignment. SPF plus DKIM without DMARC leaves a gap that both forgers and spam filters notice. The good news is that DMARC can start at p=none, which meets the requirement while only monitoring, so there is no reason to skip it.
The most common cause is the SPF 10-lookup limit. SPF is capped at 10 DNS lookups across the whole record and everything it includes; go over that and the record permanently fails (permerror) even though it reads perfectly in a text editor. Adding one more tool that needs an SPF include, such as a new sending platform or helpdesk, is what usually tips a working record over the edge. Two or more void lookups (includes that resolve to nothing) also trigger the failure. A checker that walks the full include chain is the only way to catch this.
Usually not. If send.yourcompany.com has no DMARC record of its own, receivers fall back to the policy published at yourcompany.com, where the sp= tag governs subdomains (falling back to p= when sp= is absent). This is defined in RFC 7489. Many checkers skip that fallback and wrongly report "no DMARC" for a subdomain that is in fact fully covered by its parent, so a missing record on the subdomain alone is not evidence of a problem.
Start at p=none to monitor without affecting delivery, read the aggregate reports to confirm your legitimate mail is authenticating, then move to p=quarantine and eventually p=reject for real protection against forgery. p=none satisfies Google's bulk-sender minimum but does nothing to stop spoofing, so treat it as a starting point rather than a destination. If you move to reject, avoid pct values below 100, because p=reject; pct=10 only enforces on a tenth of failing mail and is much weaker than it looks.
Once your records pass, a new domain still needs sending history before it lands at volume. lemwarm runs that ramp inside a live network of inboxes. Start a 14 day free trial.
Start your free trial