When a receiving server gets an email claiming to come from your domain, it does roughly three things before it even thinks about the content:
- Checks whether the IP address that delivered the message is allowed to send for your domain. SPF.
- Checks whether the message body and key headers have a cryptographic signature that matches a public key in your DNS. DKIM.
- Checks what to do if either of the above fails. DMARC.
All three are DNS records. None of them cost anything. Together they answer the question “is this email actually from this domain, or is someone impersonating it?” — and if a receiving server can't answer that question confidently, your message goes to spam or gets dropped entirely. The good news is that they're not hard. They just have edge cases that bite.
SPF — “these servers are allowed to send for me”
SPF (Sender Policy Framework) is the simplest of the three. It's a TXT record on your domain that lists which servers — by IP, by hostname, or by “include this other domain's SPF record” — are authorised to send mail using your domain in the From address.
A typical record looks like:
v=spf1 include:_spf.google.com include:sendgrid.net ~allTwo pieces matter. include:pulls in another SPF record (Google's, SendGrid's), so that every server they authorise also authorises mail for you. The trailing mechanism — ~all or -all — tells receivers what to do with mail from anywhere else.
The mistake everyone makes
SPF allows at most 10 DNS lookups per check. Each include: uses one. But those includes can themselves contain more include: statements, and the count is recursive. A single include:_spf.google.comalready burns three lookups. Add Mailchimp, SendGrid, and a CRM, and you're often at 12 or 14 — over the limit. The whole record fails with permerror, and SPF stops working entirely.
We see this constantly. The fix is either to remove providers you no longer use, or to flatten the SPF record — replacing include: chains with explicit IP ranges. Flattening is fine, but you have to re-flatten when your providers change their infrastructure, which they do silently.
DKIM — “here's a signature, verify it”
DKIM (DomainKeys Identified Mail) is the cryptographic one. When your mail server sends an email, it generates a hash of specific headers and the body, signs it with a private key it holds, and includes the signature in a header on the outgoing message. The receiving server fetches the matching publickey from your DNS, verifies the signature, and confirms two things: the message came from a server with your private key, and the content hasn't been modified in transit.
The DNS record sits at selector._domainkey.yourdomain.com, where selector is a short label — Google uses google, Microsoft uses selector1 and selector2, SendGrid uses s1. You can have multiple selectors active at once; that's how a domain signs mail from several providers.
The 1024 vs 2048 question
Most providers default to 1024-bit RSA keys. Gmail and Yahoo's 2024 guidance recommends 2048-bit for any sender over 5,000 messages per day — and that threshold is easy to cross during normal outbound. The fix is to rotate to a 2048-bit key in your provider's admin console, publish the new public key under a new selector, and let traffic transition.
DMARC — “here's what to do when checks fail”
DMARC (Domain-based Message Authentication, Reporting, and Conformance — yes, that's its real name) sits on top of SPF and DKIM. It does two things: it tells receivers what to do with mail that fails authentication, and it gives you reports about who's sending mail claiming to be your domain.
A simple DMARC record:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comThe p= tag is the policy: none means “monitor only,” quarantine means “send failing mail to spam,” and rejectmeans “drop failing mail entirely.” The rua=address gets daily aggregate reports — these are XML files and not particularly readable, but tools like Postmark's DMARC Digests parse them for free.
How to roll out DMARC without breaking everything
The temptation is to start with p=reject. Don't. The right rollout is:
- Start with
p=none. Receive reports for two to four weeks. Find every server sending as your domain that you didn't know about — almost every company finds at least one. - Once your legitimate senders are all properly authenticated, move to
p=quarantinewithpct=10. This quarantines 10% of failing mail, lets you watch the impact, then ramp the percentage up. - After a month at full
p=quarantine, move top=reject. Now you have full enforcement.
Most teams stall at p=none forever and that's a real shame, because p=none doesn't protect you from anything — it just publishes a self-monitoring tag. Get to p=quarantine at minimum.
“Authentication tells providers you're legitimate. It doesn't tell them you're wanted. You still need the engagement side, which is what warming is for.”
Why these aren't enough
If you set up SPF, DKIM, and DMARC correctly and stopped there, you would still land in spam. The reason is unromantic: authentication only proves identity. It says “this email is really from this domain.” That's necessary, but it's not sufficient. Receiving servers still need a reason to want mail from that domain, and that reason is engagement.
Cold outreach domains, especially new ones, have no engagement history. Filters treat them as “authenticated unknowns” — provably real, provably not interesting yet. That's why warming exists: to produce engagement signals at small volume, on a ramp, so that by the time real outbound starts, the domain has a track record of being opened and replied to. Authentication gets you in the conversation; warming earns you a seat at the table.
How to test all this in five minutes
Free tools that'll tell you almost everything you need:
- Email Auth Checker — runs SPF (with lookup count), DKIM (probes common selectors), DMARC parsing, MX, BIMI. One screen.
- Mail Tester — send a real email to a unique address, get a score with detailed findings.
dig TXT yourdomain.com— if you're comfortable on the command line, this is the fastest way to see your raw records.
If you're seeing inconsistent inbox rates and you haven't looked at this in 6 months, start here. It's almost always something boring in the records that's causing the problem — and almost always free and easy to fix.