SMTP, the protocol that moves email around the internet, will happily accept a message claiming to be from [email protected] even if it came from an unrelated server on another continent. Nothing in the original protocol verifies who’s really sending — the exact gap phishing and domain spoofing exploit, and the reason SPF, DKIM, and DMARC exist.

All three are DNS TXT records, not hosting settings. They determine whether Gmail, Outlook, and Yahoo trust mail claiming to come from your domain, and whether someone else can forge that domain to send mail that isn’t. This guide covers what each record does, the correct syntax, how to set all three up in order, the misconfigurations that break them most often, and why mail can still land in spam even with every record correct.

1. Why Email Authentication Matters

Every email has two “from” addresses most people never see: the envelope sender (used for bounce handling) and the visible From: header shown in the inbox. Nothing requires them to match or to be tied to the sending server. SPF, DKIM, and DMARC close that gap, each a different way:

• SPF — publishes which servers are authorized to send mail for your domain
• DKIM — cryptographically signs each message so it can be verified as untampered and genuinely yours
• DMARC — tells receivers what to do when a message fails both, and reports the results back to you

Beyond blocking spoofed mail, all three feed directly into spam filtering. A domain with none of them isn’t necessarily malicious, but it looks exactly like one to an automated filter — “it just works” email delivery is quietly the product of three DNS records working together.

2. SPF Explained

SPF (Sender Policy Framework) is a single TXT record at your domain’s root listing servers authorized to send mail on its behalf. A receiving server checks the connecting IP against that list.

# Host: @ (root domain)  |  Type: TXT
v=spf1 include:_spf.google.com ~all

v=spf1 must come first. include:_spf.google.com pulls in Google’s own authorized IP list — how you authorize a provider without knowing its server addresses. The final all mechanism’s qualifier decides what happens to everyone else:

Use ~all while confirming setup, then -all once no legitimate mail comes from an unlisted source. Other mechanisms: ip4:/ip6: (a specific IP), a/mx (your domain’s own listed servers), and include: (another domain’s record — how Google Workspace, Microsoft 365, or a marketing platform gets authorized). A domain using both Google Workspace and SendGrid combines them in one record:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

RFC 7208 caps SPF evaluation at 10 DNS lookups. include, a, mx, ptr, exists, and the redirect modifier each count, and include: entries can nest — a provider’s own record may include others, quietly burning lookups you didn’t budget for. ip4, ip6, and all cost nothing. Exceed 10 and the whole check returns a PermError — not the same as having no record at all, but DMARC treats any SPF PermError as an outright fail, so the practical effect is the same.

3. DKIM Explained

DKIM (DomainKeys Identified Mail) works differently: instead of authorizing IPs, it cryptographically signs each outgoing message with a private key your mail server or provider holds, and publishes the matching public key in DNS. A receiving server fetches that key, verifies the signature, and confirms the message wasn’t altered and really came from your domain’s key holder.

The Selector Concept

Because a domain may use more than one sending service, DKIM records include a selector — a label letting multiple keys coexist:

selector._domainkey.yourdomain.com

Every signed message carries a DKIM-Signature header naming the selector and domain (d=) to check, so the receiver knows which record to fetch. The record itself looks like this:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7...(continues, no line breaks)

v=DKIM1 is the version, k=rsa the key algorithm, and p= the public key — a long base64 string that must be entered as one continuous value, since a broken or truncated key silently fails verification.

You Don’t Generate This Yourself

Your provider generates the key pair and hands you the exact record to publish:

• Google Workspace — Admin console → Apps → Google Workspace → Gmail → Authenticate email. Choose 2048-bit RSA and a selector name, then copy the generated TXT record into DNS.
• Microsoft 365 — Defender portal → Email & Collaboration → Policies & Rules → Threat Policies → Email Authentication Settings → DKIM tab. It issues two CNAMEs (fixed selectors selector1/selector2) pointing to Microsoft-hosted keys rather than a TXT value you paste yourself. Publish both, then enable signing in the same panel.
• Self-hosted servers (Postfix with OpenDKIM, etc.) generate the pair locally with a tool like opendkim-genkey, producing the private key file plus the public TXT record.

4. DMARC Explained

DMARC (Domain-based Message Authentication, Reporting & Conformance) doesn’t authenticate anything itself — it’s a policy layer on top of SPF and DKIM telling receivers what to do with mail that fails both, and where to send reports.

v=DMARC1; p=none; rua=mailto:[email protected]; pct=100; adkim=r; aspf=r

Alignment

DMARC checks whether the domain that passed SPF or DKIM aligns with the visible From: header. Relaxed (default) accepts a match at the organizational level — mail.yourdomain.com aligns with yourdomain.com. Strict requires an exact match. Most setups use relaxed for both.

The Rollout Path

Never jump straight to p=reject. The standard sequence:

1. p=none — monitor only; nothing is blocked while you collect reports on what’s passing and failing.
2. p=quarantine — once legitimate mail authenticates cleanly, send failures to spam instead of the inbox.
3. p=reject — once nothing legitimate is still failing, block unauthenticated mail outright.

Most domains spend several weeks to a few months at p=none — long enough to catch sources people forget about, like an invoicing tool sending “from” the company domain.

5. How the Three Work Together

Roughly what a receiving server does for every incoming message:

1. Check SPF against the envelope sender Is the connecting IP in the SPF record for the envelope (Return-Path) domain?
2. Check DKIM against the signature Does the message carry a valid signature that verifies against the public key at the named selector?
3. Check alignment against the visible From: header Does the domain that passed SPF, or the domain that passed DKIM, match what the recipient sees? Only one needs to align.
4. Apply the published DMARC policy If neither passes and aligns, DMARC applies none, quarantine, or reject, and reports the result back to your rua address.

The either/or design is deliberate. Forwarding often breaks SPF (the forwarding server isn’t in your record) while leaving the DKIM signature intact, since DKIM signs content rather than depending on which server relayed it — exactly why DMARC needs only one of the two, not both.

6. Setting Up SPF Step-by-Step

1. Inventory everything that sends mail as your domain Your inbox provider plus any marketing, transactional, CRM, invoicing, or helpdesk tool sending “from” your domain.
2. Check for an existing SPF record first Look up your domain’s TXT records. If one already starts with v=spf1, edit it — never add a second.
3. Add an include: for each sending service Google Workspace uses include:_spf.google.com; Microsoft 365 uses include:spf.protection.outlook.com. Combine every provider your inventory found into one record.
4. Choose your catch-all qualifier Start with ~all, move to -all once you’ve confirmed the record is complete.
5. Publish as one TXT record at the root (“@”) Host/name field is typically @ or blank, type TXT, value is the full SPF string.
6. Verify the lookup count stays under 10 Re-check with an SPF tool after every new include: — some providers’ own records nest additional lookups you won’t see just by reading yours.

7. Setting Up DKIM Step-by-Step

Screens vary by provider, but the pattern is the same everywhere: generate a key, publish the record, then flip signing on.

1. Open your provider’s email authentication settings Google Workspace: Admin console → Apps → Google Workspace → Gmail → Authenticate email. Microsoft 365: Defender portal → Email & Collaboration → Policies & Rules → Threat Policies → Email Authentication Settings → DKIM.
2. Generate a new key Google Workspace: choose 2048-bit RSA and a selector name. Microsoft 365: auto-generates two CNAMEs on fixed selectors — no length choice needed.
3. Publish the exact record given to you A TXT record at selector._domainkey.yourdomain.com for Google Workspace, or two CNAMEs at selector1/selector2._domainkey.yourdomain.com for Microsoft 365. Copy exactly — don’t retype from a generic template.
4. Wait for DNS propagation Minutes to about 48 hours depending on your DNS provider and TTL. The dashboard shows the record as “not yet detected” until it’s live.
5. Turn on signing, then repeat for other senders Publishing the record doesn’t start signing — enable it once detected. Any other service sending as your domain needs its own selector, set up the same way.

8. Setting Up DMARC Step-by-Step

1. Confirm SPF and DKIM are both live first DMARC only helps once at least one is passing and aligned — set it up last.
2. Set up a mailbox or report-parsing service for reports Aggregate reports arrive daily, in XML, from every major receiver. A dedicated address like [email protected] keeps them separate; several dashboard tools can parse them automatically.
3. Publish your first record at p=none At the host name _dmarc: v=DMARC1; p=none; rua=mailto:[email protected]; pct=100. Monitors everything, blocks nothing.
4. Monitor for at least a few weeks Watch for legitimate sources showing failures — a forgotten invoicing tool or event platform. Fix each at the source before tightening.
5. Move to quarantine, then reject Optionally start quarantine at pct=25, raising to 100 over a week or two. Move to p=reject once confident — the end state, blocking unauthenticated mail outright.

9. Reading Your DMARC Reports

Your rua address gets one aggregate report per day from each major provider that saw mail from your domain. Each is an XML file that structurally contains the same information every time: which IPs sent mail as your domain, how many messages from each, whether SPF and DKIM passed and aligned, and what policy action resulted.

Almost no one parses this XML by hand. Free and paid dashboards (from DNS providers, DMARC-focused services like dmarcian and EasyDMARC, and some security platforms) turn it into a readable table. The workflow: scan for unfamiliar IPs sending real volume — a red flag — and familiar, legitimate sources showing failures — a configuration gap to fix before tightening policy.

10. Testing Your Setup

Verify records directly rather than assuming they propagated correctly.

# SPF record
dig TXT yourdomain.com +short

# DKIM record (replace "selector" with your actual selector name)
dig TXT selector._domainkey.yourdomain.com +short

# DMARC record
dig TXT _dmarc.yourdomain.com +short

nslookup -type=TXT yourdomain.com
nslookup -type=TXT _dmarc.yourdomain.com

A propagated record returns a quoted string starting with v=spf1, v=DKIM1, or v=DMARC1. Nothing returned means it hasn’t propagated or wasn’t saved correctly — check the host field, since a record accidentally saved as _dmarc.yourdomain.com.yourdomain.com (common when a DNS panel already appends the domain) won’t be found where receivers look.

• MXToolbox — free SPF/DKIM/DMARC lookup tools that flag syntax errors and, for SPF, count lookups against the 10-lookup limit.
• mail-tester.com — send a test email to the address it gives you; returns a deliverability score covering authentication, blocklist status, and content signals.
• Google Postmaster Tools — free, Gmail-specific: shows domain reputation, spam-rate trends, and authentication pass rates as Gmail actually sees them.

11. Common Misconfigurations

Multiple SPF Records on One Domain

Usually the result of a new tool’s setup instructions saying “add this TXT record” without checking one already exists. Always merge into one record, never publish a second.

Exceeding the 10-Lookup SPF Limit

Common on domains with accumulated include: entries for tools tried once and never removed. Re-check the count with every new service and prune unused entries.

Forgetting SPF After Adding a New Sender

The most common cause of a working setup suddenly breaking: a new platform starts sending “from” your domain, its include: is never added, and its mail fails SPF for every recipient checking it.

DKIM Selector Mismatch

The signature names a selector that doesn’t match what’s published in DNS — a copied old record, a typo, or a dashboard reporting signing active before DNS has finished propagating.

DMARC Alignment Failures From a Mismatched “Friendly From”

A marketing platform can pass its own SPF and DKIM while still failing your DMARC alignment, if the “friendly from” shows your domain but the message authenticates under the platform’s domain instead.

Jumping Straight to p=reject

Worth repeating: the misconfiguration most likely to cause real, unnoticed damage, since dropped mail generates no visible complaint from the sender’s side.

12. Why Mail Still Lands in Spam With Correct Records

SPF, DKIM, and DMARC are necessary but not sufficient — they prove a message came from your domain, not that it’s wanted. Mailbox providers layer other signals on top:

• Sender reputation — engagement versus complaints, built up over time per provider
• IP/domain warm-up — a new domain is treated cautiously regardless of authentication; ramp volume gradually
• Content signals — subject lines, link density, and spammy phrasing still factor in independently
• Engagement rate — low opens and frequent deletions push even authenticated mail toward spam

Google and Yahoo’s 2024 bulk sender requirements formalized this: senders reaching roughly 5,000 or more messages a day to personal Gmail addresses must have SPF and DKIM passing, at least one aligned to the From: domain, plus a DMARC record at p=none or stronger — Yahoo applies comparable expectations at volume. Below that threshold nothing is formally enforced, but the deliverability benefit applies regardless.

13. Frequently Asked Questions