Email Authentication: SPF and DKIM Setup Guide

Email authentication is the set of DNS based standards that prove a message really came from the domain it claims to use, and the two you set up first are SPF and DKIM. Together with DMARC they stop spoofing, lift inbox placement, and protect your brand. This guide walks through creating the records and shows how the three technologies interlock.

Key Takeaways

• SPF publishes an authorized sending IP list in DNS so receivers can reject impostors.
• DKIM adds a cryptographic signature that survives forwarding and proves message integrity.
• DMARC sits on top of SPF and DKIM to set a policy and collect failure reports.
• You should create SPF and DKIM before worrying about deliverability problems at scale.
• Test with a signed message and a lookup tool before you declare the setup done.

What Is Email Authentication?

Email authentication is the practice of using published DNS records and cryptographic signatures to verify that an incoming message is authorized by the domain in its From address. The core standards are SPF, DKIM, and DMARC. They do not encrypt your message content, and they do not filter spam directly. Instead, they answer a narrower but critical question: is this sender allowed to use this domain, and can we trust that the message was not altered in transit?

For a founder or marketer, email authentication is the unglamorous plumbing that keeps your newsletters, transactional receipts, and sales outreach out of the spam folder. Without it, mailbox providers such as Google and Microsoft increasingly treat your mail as suspicious regardless of how good your content is. The good news is that the first two layers, SPF and DKIM, are simple DNS changes you can make in an afternoon.

Why Does Email Authentication Matter for Deliverability?

Deliverability is the percentage of your emails that actually reach the inbox instead of the spam folder or the void. Sender reputation is the score mailbox providers assign your domain based on complaint rates, engagement, and technical signals. One of the strongest technical signals is whether your mail passes authentication. When a provider sees a message that fails SPF or DKIM, it has no reliable way to know the mail is yours, so it leans toward filtering.

The cost of poor deliverability is not just lost opens. If your domain develops a reputation for sending unauthenticated or spoofable mail, future campaigns suffer even after you fix the problem. Authentication is therefore preventive maintenance. It tells receiving servers you are a responsible sender who has taken the basic steps, which makes them more willing to deliver your messages and to trust your reputation over time.

What Is SPF and How Does It Work?

SPF, or Sender Policy Framework, is a DNS TXT record that lists the IP addresses and servers permitted to send mail on behalf of your domain. When a receiving server gets a message, it looks up the SPF record for the From domain and checks whether the connecting IP is on the list. If it is, SPF passes. If it is not, the message is flagged or rejected depending on the policy the domain published.

An SPF record starts with a version tag, v=spf1, followed by mechanisms such as include: for third party senders, ip4: for explicit addresses, and a closing qualifier like ~all or -all. The qualifier matters: ~all means softfail, a suggestion to mark suspicious mail, while -all means hardfail, a directive to reject. Most senders start with softfail and move to hardfail once they are confident the record is complete.

What Is DKIM and How Does It Work?

DKIM, or DomainKeys Identified Mail, uses a public and private key pair. Your mail server signs each outgoing message with the private key, adding a signature header. The public key is published in DNS as a TXT record under a selector, a named label that lets you rotate keys without disruption. When a receiver gets the message, it fetches the public key and verifies the signature.

The elegance of DKIM is that the signature covers the message body and selected headers, so any tampering breaks the verification. Unlike SPF, DKIM survives forwarding, because the signature travels inside the message rather than depending on the connection IP. A single domain commonly has several selectors active at once, each tied to a different sending system such as your ESP, your help desk, or your product notifications.

How Do SPF, DKIM, and DMARC Work Together?

These three standards are layered rather than competing. SPF validates the sending server by IP. DKIM validates a signature tied to your domain. DMARC then says what to do when neither, or only one, aligns with the From domain, and it requests reports so you can see who is abusing your domain. DMARC also introduces alignment, meaning the authenticated domain must match the visible From domain, which closes a gap that SPF alone leaves open.

The table below summarizes how the three fit together.

In practice a receiver checks SPF and DKIM independently, then DMARC decides the outcome. If your message passes either SPF or DKIM with proper alignment, DMARC passes. DMARC is the policy and reporting layer that turns raw authentication results into an enforceable stance and actionable visibility, which is why it belongs in the picture even though this post focuses on setup.

How Do You Create an SPF TXT Record?

Creating an SPF record is a sequence of small DNS edits. Work from a list of every system that sends mail for your domain before you write the record, because a missing include is the most common cause of an email authentication failed result.

1. List your senders: your website host, your ESP, your transactional email tool, and any CRM or help desk that emails customers.
2. Collect each provider's SPF include value, usually shown as include:send.example.com in their documentation.
3. Compose the record starting with v=spf1, then add each include and any explicit ip4: entries.
4. End with a qualifier: use ~all first, then switch to -all after testing.
5. Publish the TXT record at the root of your sending domain, not a subdomain, unless your mail uses that subdomain.
6. Wait for DNS propagation, which can take from a few minutes up to a day at most registrars.
7. Send a test message and inspect the authentication headers to confirm SPF passes.

Keep in mind that SPF has a hard limit on DNS lookups, so flattening many includes into a single list of IPs can help if you approach that ceiling. We cover the lookup limit in the FAQ below.

How Do You Set Up a DKIM Record?

DKIM setup is slightly different because the keys are generated by your sending system, not typed by hand. The steps below assume your ESP or mail server supports DKIM, which the large ones all do.

1. Open the sending platform and locate the DKIM or email authentication settings.
2. Generate a DKIM key pair; the platform shows a selector name and a public key value.
3. Create a TXT record at the selector host, formatted as selector._domainkey.yourdomain.com.
4. Paste the public key value exactly, including any segmentation the platform specifies.
5. Save the DNS record and return to the platform to enable signing.
6. Send a test message and confirm the DKIM signature header is present and valid.

If you run several sending systems, repeat the process with a different selector for each. Keeping selectors separate makes rotation and troubleshooting far easier, because you can revoke one key without breaking the others.

What Are the Most Common SPF and DKIM Mistakes?

The first mistake is multiple SPF records at the same domain. DNS only honors one SPF TXT record, so if you add a second, receivers ignore both. Merge everything into a single record. The second mistake is forgetting a sender, which produces an email authentication failed softfail the moment that system sends. The third is typos in include values or in the DKIM public key, where a missing character silently breaks verification.

• Publishing two SPF records instead of combining them into one.
• Using the wrong selector name when creating the DKIM TXT record.
• Switching to -all before testing, which rejects legitimate mail.
• Copying a DKIM key with line breaks that some DNS panels insert automatically.

A related trap is assuming SPF covers forwarded mail. It does not, because the forwarding server's IP is not on your list. That is exactly why DKIM matters: its signature travels with the message and keeps verifying after hops that break SPF.

How Do You Test That SPF and DKIM Are Working?

Testing is the step people skip, and it is the step that catches the silent failures. After publishing both records, send a message from your domain to a mailbox you control and view the full source. Look for the Authentication Results header, where receivers report spf=pass and dkim=pass alongside your domain.

• Send to a Gmail or Outlook address and check the message details for the authentication summary.
• Use a free authentication checker that sends you a report of SPF, DKIM, and DMARC status.
• Query DNS directly with a lookup command to confirm the TXT records return the expected values.
• Review DMARC aggregate reports once they start arriving to spot unauthorized senders.

If you see spf=pass but dkim=fail, focus on the DKIM key and selector. If both fail, double check that the records are at the correct host names and that propagation has completed. Patience here prevents a later deliverability incident.

Frequently Asked Questions

What Is the Difference Between SPF and DKIM?

SPF and DKIM solve different halves of the trust problem. SPF checks whether the sending server's IP address is on your authorized list, which is easy to set up but breaks when mail is forwarded. DKIM signs the message with a private key and publishes the public key in DNS, so the signature proves the message came from you and was not changed. Using both gives receivers two independent ways to trust your mail, and DMARC ties the result together with a clear policy.

Do I Need DMARC If I Already Have SPF and DKIM?

Yes, you should still publish a DMARC record even after SPF and DKIM pass. SPF and DKIM only authenticate; they do not tell receivers what to do when authentication fails, nor do they report abuse to you. DMARC adds that policy and reporting layer, letting you move from monitoring to enforcement and receive daily aggregate reports about who is sending as your domain. Start with a monitor policy, then tighten it once the reports look clean.

How Many DNS Lookups Does SPF Allow?

SPF permits a maximum of ten DNS lookups across all mechanisms in your record, counting each include, a, mx, ptr, and exists term. Exceeding this limit causes an SPF permerror, which typically fails authentication even when your senders are correct. If you use many third party services, consider flattening includes into explicit ip4 entries or using a managed SPF service that keeps the count under ten while listing every authorized sender accurately.

Can I Have More Than One DKIM Selector?

Yes, and in most mature setups you should. A selector is simply a named label, such as s1 or google, that points to one public key, and a domain can publish as many selectors as it needs. Running several lets you give each sending system its own key, rotate keys without downtime, and revoke a compromised key independently. Receivers only check the selector named in the message signature, so extra selectors cause no conflict.

How Do I Check Whether My SPF and DKIM Are Passing?

Send a test message to a mailbox where you can view the full headers, then look for the Authentication Results line reporting spf=pass and dkim=pass next to your domain. Many free email authentication checkers will send a report after you email them. You can also query DNS directly to confirm your TXT records are present and correct. Once DMARC is live, its aggregate reports give you a daily view of pass and fail rates across all receivers.