SPF, DKIM and DMARC: The Complete Email Authentication Setup

Three DNS records decide whether mailbox providers trust your email: SPF, DKIM and DMARC. Get them right once and you have built the foundation for every campaign and every transactional message you will ever send. Get them wrong — or skip them — and even perfectly legitimate mail will be throttled, junked, or outright rejected. Since 2024, Gmail and Yahoo require all three from bulk senders, so this is no longer optional. This guide explains what each record does, how to configure it, the order to roll them out, and the mistakes that quietly break everything.

The big picture: identity and trust

Email was designed in an era when nobody lied about who they were, so the protocol itself has no built-in way to prove a sender's identity. SPF, DKIM and DMARC are the layers bolted on afterward to fix that. SPF says which servers may send for your domain. DKIM cryptographically signs each message so it cannot be altered or forged. DMARCties the two together, tells receivers what to do when checks fail, and sends you reports. Together they let Gmail say, with confidence, "this really is from yourapp.com" — and that confidence is what earns the inbox.

SPF — who is allowed to send

SPF (Sender Policy Framework) is a single TXT record on your domain listing the servers and services authorized to send mail as you. A typical record looks like this:

v=spf1 include:_spf.sendersy.com include:_spf.google.com ~all

Read it left to right: version spf1, then a list of include: mechanisms delegating to each service that sends for you, ending in ~all (soft-fail anything else) or -all (hard-fail). Two rules matter enormously:

• Stay under 10 DNS lookups. Each includecan trigger more lookups; exceed ten and SPF returns "permerror" and effectively fails. Consolidate services and use SPF-flattening if you must.
• Publish exactly one SPF record. Two v=spf1 records on the same domain is invalid and breaks SPF entirely. Merge all your includes into one record.

DKIM — sign every message

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to the header of every message. The receiving server fetches your public key from DNS and verifies the signature, proving the message was not tampered with in transit and genuinely originated from a server holding your private key. Your provider generates a key pair and gives you a selector record to publish, something like:

postal._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

Publish it exactly as provided — the selector (postal here) must match what the sender stamps on outgoing mail. Once the record propagates, every message is signed automatically. If you send from multiple services, each gets its own selector, and they coexist happily because each lives at a different selector hostname.

DMARC — set the policy and get reports

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the keystone. It does three things: requires that SPF or DKIM not only pass but align with your visible from-domain, tells receivers what to do with mail that fails, and emails you aggregate reports of everything sent in your name. A starter record:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1"

The p= tag is the policy: none (monitor only), quarantine (send failures to spam) or reject (block failures outright). The rua address receives the daily aggregate reports that tell you who is sending as your domain — invaluable for finding every legitimate sender before you tighten the policy.

The safe rollout sequence

The number-one mistake is jumping straight to p=reject and blocking your own legitimate mail. Do it in stages instead:

1. Publish SPF and DKIM and confirm both pass on a test message.
2. Publish DMARC at p=none with a reporting address. You change nothing about delivery yet.
3. Read the reports for 2–4 weeks. Identify every legitimate source — your app, your ESP, support desk, invoicing tool — and make sure each passes SPF and DKIM with alignment.
4. Move to p=quarantine; pct=25, watch, then raise the percentage toward 100.
5. Switch to p=reject once nothing legitimate is failing. Now nobody can spoof your domain.

Common mistakes that silently break authentication

• Going straight to p=reject and discovering — via angry customers — that a tool you forgot about was sending as you.
• Forgetting to update SPF when you switch sending providers, so the old include stays and the new sender fails.
• Publishing two SPF records, which invalidates both.
• Exceeding the 10-lookup SPF limit, causing a permerror.
• Publishing DKIM with the wrong selector, so signing silently fails verification.
• Setting up SPF and DKIM but never adding DMARC — leaving the door open to spoofing and missing the reports that would catch it.

Alignment: the subtle part everyone misses

DMARC does not just require SPF or DKIM to pass — it requires alignment. SPF alignment means the domain in the envelope sender matches your from-domain; DKIM alignment means the signing domain matches it. A message can pass raw SPF on the provider's domain yet fail DMARC because that domain does not align with the from address your recipient sees. This is why "SPF passes but DMARC fails" is such a common, confusing result — and why using a provider that signs with your own domain matters.

Verify before you trust

After publishing, send a test to a Gmail address and open "Show original." You want three green PASS results: SPF, DKIM and DMARC. Repeat for Outlook, Yahoo and Yandex. Use a DMARC report analyzer to keep an eye on aggregate reports over time, because new tools that start sending as your domain will show up there first.

Keeping authentication healthy over time

Authentication is not a set-and-forget task. Your sending landscape changes — you adopt a new CRM, a new help desk, a new invoicing tool — and each one needs to be added to SPF and ideally to sign with DKIM under your domain. If you forget, that tool's mail starts failing DMARC the moment you reach enforcement, and a real business email stops arriving. The DMARC aggregate reports are your early-warning system: a new IP appearing in the "failing" column is usually a legitimate tool someone added without telling you, not an attacker. Treat the reports as an ongoing inventory, not a one-time audit.

It is also worth rotating DKIM keys periodically and using a reasonable key length — 2048-bit RSA is the modern baseline, since 1024-bit is increasingly considered weak. Keep your SPF record lean as you add and remove services, because it is easy to creep past the ten-lookup limit over years of accumulation. A quarterly review — confirm every sender still passes, remove includes for tools you no longer use, verify DMARC is still at the policy you intend — takes an hour and prevents the slow, silent decay that catches so many organizations by surprise.

Frequently asked questions

Do I need DMARC if SPF and DKIM already pass? Yes. Without DMARC there is no policy and no reporting, so spoofers can still forge your domain and you would never know.

Will p=reject block my newsletters? Only if they fail authentication. Properly configured marketing mail passes and is unaffected; that is the whole point of the staged rollout.

How long does DNS propagation take? Usually minutes to a couple of hours, occasionally up to 24. Lower your record TTLs before making changes if you need to iterate quickly.

What the DMARC reports actually contain

The reason to publish DMARC even at p=none is the reporting. Once a day, every major receiver sends an aggregate XML report to your ruaaddress summarizing the mail it saw claiming to be from your domain: the source IP, how many messages, and whether SPF and DKIM passed and aligned. Read as raw XML it is unfriendly, so most teams pipe it into a DMARC report analyzer that turns it into a readable table. What you are hunting for is simple: a list of every IP sending as you, split into "legitimate and passing" and "everything else." The legitimate column is your inventory of senders you must keep working; the other column is either shadow IT you forgot about or outright spoofing.

This is why DMARC is as much a security control as a deliverability one. Before DMARC enforcement, anyone can forge your domain in phishing emails and your customers have no protection. Once you reach p=rejectwith aligned authentication, those forgeries are dropped at the receiver, and your brand can no longer be cheaply impersonated. The reports are how you get from "none" to "reject" without collateral damage — they show you every sender to fix before you turn on enforcement.

Subdomains and a multi-sender setup

Most real organizations send from more than one source: an app sends transactional mail, an ESP sends marketing, a support desk sends ticket replies, a billing tool sends invoices. The clean architecture is to give each its own subdomain — notify., mail., help., billing. — each with its own SPF include and DKIM selector, and each building its own reputation. A complaint storm against the marketing subdomain then has no power to harm the transactional one, and your DMARC policy can be tuned per subdomain.

A subtle benefit of subdomains is isolation during warm-up and incidents. If you need to warm a new sending service, you do it on a fresh subdomain without risking your established root-domain reputation. If a key leaks or a tool is compromised, you can cut off and re-key one subdomain without taking down your whole email operation. Plan the subdomain map early; retrofitting it after you have built reputation on a single shared domain is painful and slow.

Let the platform generate the records

Sendersy auto-registers your DKIM key and checks SPF, DKIM and DMARC alignment the moment you add a domain, so you see green before you send a single campaign — and it signs with your own domain, so alignment just works. Add your domain to Sendersy and we will generate the exact records to paste into your DNS.