SPF, DKIM and DMARC Setup Guide: How to Authenticate Your Email Domain

If your password reset emails land in spam, or Gmail shows a "via" warning next to your sender name, the cause is usually the same: your domain isn't properly authenticated. SPF, DKIM and DMARC are three DNS-based standards that prove a message really came from you. Mailbox providers check all three before deciding whether to deliver, junk-folder or reject your mail.

This guide explains what each record does, how to set them up in the right order, and the mistakes that quietly break authentication on production domains.

Why email authentication matters

Email was designed without sender verification. Anyone can type any address into the "From" field, which is why phishing is so easy. SPF, DKIM and DMARC close that gap by letting a receiving server verify two things: that the sending server is allowed to send for your domain, and that the message wasn't altered in transit.

Since 2024, Gmail and Yahoo have required bulk senders (roughly 5,000+ messages a day to their users) to authenticate with SPF and DKIM and publish a DMARC policy. Microsoft has since tightened requirements for high-volume senders to Outlook.com as well. Even if you send far less, unauthenticated mail is treated with suspicion, and transactional messages like receipts, password resets and sign-in codes are the ones you can least afford to lose.

SPF: which servers may send for your domain

Sender Policy Framework (SPF) is a TXT record that lists the servers and services authorized to send mail using your domain. When a message arrives, the receiving server looks at the envelope sender (the Return-Path domain), fetches that domain's SPF record and checks whether the connecting IP is on the list.

A typical record looks like this:

example.com.  TXT  "v=spf1 include:_spf.your-email-provider.com -all"

Breaking it down:

• v=spf1 identifies the record as SPF.
• include: pulls in the authorized IP ranges published by your email provider.
• -all tells receivers to fail anything not listed. ~all (soft fail) is more lenient and is often used while testing.

SPF rules that cause real outages

• One SPF record per domain. Publishing two TXT records that both start with v=spf1 makes SPF return a permanent error. Merge them into a single record.
• The 10 DNS lookup limit. Every include, a, mx and redirect counts toward a limit of ten lookups. Go over it and SPF fails for everyone, even legitimate senders. Audit your record whenever you add a new service.
• SPF checks the envelope sender, not the visible From address. This matters for DMARC alignment, covered below.

DKIM: a cryptographic signature on every message

DomainKeys Identified Mail (DKIM) adds a digital signature to each outgoing message. Your sending system signs selected headers and the body with a private key. The matching public key is published in DNS, and the receiving server uses it to confirm the message is genuine and unmodified.

The public key lives at a hostname built from a selector and your domain:

selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

Your email provider generates the key pair and gives you the DNS record to publish. A few practical points:

• Use 2048-bit keys where your DNS host supports them. 1024-bit keys still work but are considered weak.
• Long keys can exceed the 255-character limit of a single DNS string. Most DNS panels split these automatically, but if verification fails, check that the value was saved as one continuous key.
• Selectors let you rotate keys. Publish a new selector, switch signing over, then retire the old one. Rotating every six to twelve months is a sensible habit.
• Unlike SPF, DKIM survives forwarding in most cases, because the signature travels with the message.

DMARC: the policy that ties it together

Domain-based Message Authentication, Reporting and Conformance (DMARC) tells receivers what to do when SPF and DKIM don't pass, and sends you reports about it. It also adds the concept of alignment: the domain authenticated by SPF or DKIM must match the domain in the visible From address. A message passes DMARC if either SPF or DKIM passes and aligns.

A starter record:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

The key tags:

• p= is the policy: none (monitor only), quarantine (send to spam) or reject (block outright).
• rua= is the address that receives daily aggregate reports.
• pct= applies the policy to a percentage of failing mail, useful for gradual rollouts.
• adkim and aspf set alignment mode to relaxed (default) or strict.

Step-by-step setup order

Order matters. Turning on a strict DMARC policy before SPF and DKIM are working will block your own legitimate mail.

1. Inventory every sender. List each system that sends as your domain: your transactional provider, your marketing tool, your support desk, your CRM, your billing system.
2. Publish SPF with an include for each authorized service, staying under ten lookups.
3. Enable DKIM in each sending service and publish the DNS records they provide. Send a test message and confirm the signature validates.
4. Publish DMARC at p=none with an rua address. Leave it for two to four weeks.
5. Read the reports. Aggregate reports arrive as XML, so most teams feed them into a free or paid DMARC report viewer. Look for legitimate sources that are failing and fix them.
6. Move to p=quarantine, ideally with pct=10 and then increasing.
7. Move to p=reject once failures from legitimate sources are gone.

Separate transactional and marketing mail

A practical way to protect your most important messages is to send transactional and marketing email from different subdomains, such as mail.example.com for receipts and resets and news.example.com for campaigns. Each subdomain builds its own sending reputation, so a spike in marketing complaints won't drag down your password reset emails. Each subdomain needs its own SPF, DKIM and DMARC setup, though a DMARC record on the parent domain applies to subdomains unless you override it with sp=.

Common mistakes to avoid

• Duplicate SPF records instead of one merged record.
• Exceeding the 10-lookup limit after adding yet another SaaS tool.
• Jumping straight to p=reject without monitoring first.
• Forgetting third-party senders that use your From address.
• Ignoring DMARC reports. A record with no one reading the reports is a missed opportunity.
• Leaving old DKIM selectors published after a provider change.

How to test your setup

Send a message to a Gmail account, open it, choose "Show original" and look for SPF: PASS, DKIM: PASS and DMARC: PASS in the header summary. You can also query your records directly from a terminal:

dig TXT example.com +short
dig TXT selector1._domainkey.example.com +short
dig TXT _dmarc.example.com +short

Remember that DNS changes can take anywhere from a few minutes to several hours to propagate, depending on your record's TTL.

Frequently asked questions

Do I need all three records? Yes. SPF and DKIM do the authentication, and DMARC enforces policy and gives you visibility. Major mailbox providers now expect all three.

Is SPF or DKIM more important? Neither works as a substitute for the other. DMARC only needs one of them to pass with alignment, but you should configure both so that forwarding or a misconfiguration in one doesn't sink your mail.

Will DMARC at p=none hurt me? No. It changes nothing about delivery. It simply starts the reporting that tells you what is safe to enforce.

How long does the full rollout take? For most small and mid-sized domains, four to eight weeks from p=none to p=reject, depending on how many third-party senders you need to fix.

Final checklist

• One merged SPF record, under ten lookups
• DKIM enabled and passing for every sending service, 2048-bit where possible
• DMARC published with an rua reporting address
• Reports reviewed regularly and policy tightened in stages
• Transactional and marketing mail separated by subdomain

Authentication isn't glamorous, but it is the foundation every other deliverability tactic builds on. Get these three records right once, monitor them, and your transactional email has the best possible chance of reaching the inbox.