The Technical Setup: SPF, DKIM, and DMARC Explained

Short answer: SPF, DKIM, and DMARC are three DNS-based standards that together prove an email genuinely came from your domain and was not altered in transit. SPF lists which servers may send mail for your domain. DKIM adds a cryptographic signature that verifies the message was not tampered with. DMARC ties the two together, tells receiving servers what to do when authentication fails, and sends you reports about who is sending mail as your domain. You need all three working together, not just one.

This guide explains how each standard works, how they interact, and how to set them up in the right order without breaking your existing email. It is written for site owners, marketers, developers, and anyone who has been told their emails are landing in spam or that they need a DMARC record.

Why Email Authentication Matters

Email was not designed with identity verification in mind. The original protocols let anyone claim to be anyone. That is why phishing works: a scammer can send a message that appears to come from your bank, your boss, or your own domain.

Authentication standards fix this by giving receiving mail servers a way to check three things:

• Authorization: Was this server allowed to send mail for this domain?
• Integrity: Was the message modified after it was sent?
• Policy: What should happen if either check fails?

Beyond security, authentication directly affects deliverability. Major mailbox providers including Gmail, Outlook, and Yahoo have tightened requirements for bulk senders, and a valid DMARC record is now effectively expected for anyone sending meaningful volume. If you skip it, your legitimate mail is more likely to be filtered, throttled, or rejected.

The key point: authentication is not just a security measure. It is the baseline that determines whether your email is trusted at all.

The Three Standards at a Glance

SPF: Sender Policy Framework

SPF is a DNS record that lists the servers authorized to send email on behalf of your domain. When a receiving server gets a message, it looks up your SPF record and compares it against the IP address of the server that connected to deliver it.

How SPF Works

SPF is evaluated against the envelope sender — the address used in the SMTP conversation, also called the Return-Path. This is often different from the visible "From" address the recipient sees. That distinction matters later when we talk about alignment.

A basic SPF record looks like this:

Reading it left to right:

• v=spf1 — identifies this as an SPF record.
• include:_spf.google.com — authorizes servers listed in Google's SPF record (useful if you use Google Workspace).
• ip4:203.0.113.10 — authorizes one specific IPv4 address.
• -all — rejects anything not listed above.

The 10-Lookup Limit

SPF has a hard limit of 10 DNS lookups. Mechanisms like include, a, mx, ptr, and exists each count toward it. If you exceed the limit, SPF fails outright with a permanent error — and that failure can affect every message you send.

This is the single most common SPF problem. Marketing platforms, CRMs, help desks, and transactional senders each add their own include, and the count adds up fast. If you are near the limit, the practical fix is to consolidate senders, move some traffic to a subdomain with its own SPF record, or use a service that flattens your SPF record into static IPs.

Common SPF Mistakes

• Creating more than one SPF record. You must have exactly one TXT record starting with v=spf1. Multiple records cause a permanent error.
• Using ~all everywhere. Soft fail looks permissive; if you are confident in your list, -all is stronger.
• Forgetting third-party senders. If a tool sends mail for you and is not listed, that mail fails SPF.
• Editing the record by hand and losing track of the lookup count.
• Assuming SPF protects the visible From address. It does not, on its own.

DKIM: DomainKeys Identified Mail

DKIM adds a digital signature to every outgoing message. The sending server signs selected headers and the message body with a private key. The matching public key is published in your DNS. The receiving server uses that public key to verify the signature.

How DKIM Works

1. Your mail server generates a key pair: a private key it keeps secret and a public key it publishes.
2. When a message is sent, the server creates a hash of the selected headers and body, then signs that hash with the private key.
3. The signature is added to the message headers as a DKIM-Signature field, which includes a selector and your domain.
4. The receiving server looks up selector._domainkey.yourdomain.com in DNS, retrieves the public key, and verifies the signature.

A DKIM DNS record looks like this:

Understanding Selectors

The selector is an arbitrary label that lets you publish multiple DKIM keys under the same domain. This is how providers like Microsoft 365 use selector1 and selector2 — one active key and one for rotation. Selectors also let different sending services sign with different keys without conflicting.

If a message fails DKIM verification, the usual causes are a missing or malformed DNS record, a selector mismatch, a key that was rotated without updating DNS, or a mailing list or forwarder that modified the message body.

DKIM Best Practices

• Use a key length of at least 1024 bits; 2048 bits is the current standard.
• Rotate keys periodically, and keep the old key published until mail signed with it has expired.
• Do not sign only the From header. Sign the headers that matter, and let your provider handle the defaults unless you have a reason to customize.
• Be aware that forwarding can break DKIM if the forwarder modifies headers or body content.

DMARC: Domain-based Message Authentication, Reporting, and Conformance

SPF and DKIM each answer a narrow question. DMARC is the layer that connects them to the domain recipients actually see in the From field, and defines what happens when authentication fails.

Alignment: The Core Idea

DMARC requires that at least one of SPF or DKIM passes and aligns with the domain in the visible From header. Alignment comes in two modes:

• Relaxed alignment: the organizational domain must match. mail.example.com aligns with example.com.
• Strict alignment: the domains must match exactly.

This is why SPF passing is not enough on its own. If a spammer sends from a server that passes SPF for a different domain, but the visible From says your domain, SPF alone will not catch it. DMARC will, because the domains do not align.

DMARC Policies

The policy tells receiving servers what to do with mail that fails both SPF and DKIM alignment:

• p=none — take no action, but send reports. This is the monitoring phase.
• p=quarantine — send failing mail to spam or a quarantine folder.
• p=reject — block failing mail outright.

A typical DMARC record:

Reading the Tags

• v=DMARC1 — required version tag, must come first.
• p — policy for the domain.
• sp — separate policy for subdomains, if you want one.
• rua — where aggregate reports are sent.
• ruf — where forensic (failure) reports are sent, though many providers do not send these.
• fo — when to generate forensic reports.
• pct — the percentage of failing messages the policy applies to. Useful for gradual rollout.
• adkim and aspf — set alignment mode to relaxed (r) or strict (s).

Important: never jump straight to p=reject. Start at p=none, collect reports for a few weeks, identify every legitimate sender, fix their SPF and DKIM, and only then move to quarantine and finally reject.

How the Three Work Together

A receiving server processes an incoming message roughly like this:

1. Read the visible From domain.
2. Look up the DMARC record for that domain.
3. Check SPF against the envelope sender and check whether it aligns with the From domain.
4. Check DKIM against the signature domain and check whether it aligns with the From domain.
5. If at least one passes and aligns, the message passes DMARC.
6. If both fail, apply the DMARC policy: none, quarantine, or reject.

SPF alone is fragile because it breaks on forwarding. DKIM alone is fragile because it breaks when content is modified. Together, they cover each other's weaknesses, and DMARC gives the whole system a policy and a feedback loop.

Setup Order: A Practical Sequence

Do these in order. Skipping ahead is the fastest way to block your own legitimate mail.

1. Inventory every sender. List your mail host, marketing platform, CRM, ticketing system, invoicing tool, and anything else that sends mail as your domain. Include subdomains.
2. Publish SPF records. One record per domain or subdomain. Keep the lookup count under 10.
3. Enable DKIM at each sender. Most providers give you the DNS record to publish. Turn on signing and confirm it is active.
4. Publish a DMARC record with p=none. Add an rua address you actually monitor. Do not skip this step.
5. Read the reports for two to four weeks. Identify sources that fail alignment. Decide whether each is legitimate.
6. Fix or remove failing sources. Update SPF, enable DKIM, or stop the sender.
7. Move to p=quarantine. Optionally use pct to roll it out gradually.
8. Move to p=reject. Once reports are clean and stable, enforce fully.
9. Monitor continuously. New tools and senders get added all the time. Review reports monthly.

Common Mistakes Across All Three

• Setting DMARC to reject on day one. This blocks legitimate mail you forgot to authorize.
• Ignoring subdomains. A subdomain without its own policy inherits the organizational policy, which may not match how it sends mail.
• Publishing records on the wrong host. SPF goes at the domain root, DKIM at the selector host, DMARC at _dmarc.
• Copying records from a tutorial without changing the values. The p= value and the public key must be yours.
• Not monitoring reports. A DMARC record with no one reading rua is a record you cannot safely tighten.
• Assuming a passing SPF means passing DMARC. Alignment is a separate requirement.
• Using a domain you do not control. If a vendor sends on your behalf with their own domain in the From header, DMARC for your domain is irrelevant to that message.

Testing and Monitoring

After publishing records, verify them. DNS changes can take time to propagate, so check after a few hours and again the next day.

Useful checks:

• Query your TXT records directly to confirm they are published correctly and there are no duplicates.
• Send a test message to a mailbox you control and inspect the full headers for spf=pass, dkim=pass, and dmarc=pass.
• Use free public SPF, DKIM, and DMARC lookup tools to validate syntax and lookup counts.
• If you send at volume, register for Google Postmaster Tools and any equivalent dashboards your other providers offer.
• Set up a process for aggregate reports. They arrive as XML attachments, which are hard to read by hand — most teams use a DMARC reporting service.

Treat authentication as an ongoing process, not a one-time task. Every new tool that sends email is a new potential alignment failure, and every DNS change is a chance to break something.

Frequently Asked Questions

Do I need SPF, DKIM, and DMARC, or can I pick one?

You need all three for meaningful protection. SPF and DKIM are the authentication mechanisms; DMARC is the policy and alignment layer that makes them useful for the From domain. A DMARC record without working SPF or DKIM alignment will simply fail.

What happens if I only set up SPF?

You get partial protection and no policy enforcement. SPF can still be broken by forwarding, and it does not protect the visible From address on its own. Spoofing of your From domain remains possible.

How long do DNS changes take to apply?

It depends on the TTL values on your records. Changes often propagate within an hour, but can take up to 24–48 hours in some cases. If you lowered TTLs before making changes, propagation will be faster.

Can I have more than one SPF record?

No. You must have exactly one TXT record beginning with v=spf1 per domain. If you need to authorize multiple senders, combine them into a single record using include and ip4 or ip6 mechanisms.

What is DMARC alignment in plain terms?

Alignment means the domain that passed SPF or DKIM matches the domain the recipient sees in the From field. If SPF passes for a different domain than the one shown to the recipient, DMARC does not count it as a pass.

Will moving to p=reject block my legitimate email?

It can, if you have not identified every legitimate sender first. That is exactly why the recommended path is p=none first, then quarantine, then reject — with reports reviewed at each stage.

What is a DKIM selector?

A selector is a label that lets you publish more than one DKIM public key under the same domain. It appears in the DNS hostname as selector._domainkey.yourdomain.com and in the DKIM-Signature header of outgoing mail.

Do I need DMARC if I use a third-party sending platform?

Yes. The platform should be configured to send with your domain and sign with DKIM, and it should be included in your SPF record if it uses your domain as the envelope sender. Your DMARC policy still governs what happens when those checks fail.

Where to Go From Here

The order matters more than the speed. Inventory your senders, get SPF and DKIM right, publish DMARC at p=none, and let the reports tell you what to fix before you enforce anything.

If you are just starting, the next practical step is to list every system that sends email as your domain and check whether each one has SPF authorization and DKIM signing enabled. That single audit usually reveals the gaps that matter most. From there, publish your first DMARC record in monitoring mode and give it a few weeks before tightening the policy.

Once enforcement is stable, you can look at advanced options like BIMI, which displays a verified logo in supporting inboxes and depends on a strong DMARC policy being in place first.