SPF, DKIM and DMARC Setup Guide

Editorial Team·1 months ago

021014 minutes read

Quick answer: SPF, DKIM, and DMARC setup involves adding three DNS TXT records to your domain that together verify your identity as a sender, protect against spoofing, and tell receiving servers how to handle messages that fail authentication. Most domains can usually be configured within an hour, and the records themselves are free — but the order and testing sequence matters significantly.

SPFAuthorized sending server?

↓

DKIMMessage signature valid?

↓

DMARCPolicy: none / quarantine / reject

↓

📥 InboxDelivered, quarantined, or rejected

How SPF, DKIM, and DMARC work together to authenticate incoming email

Why Emails Fail Authentication — and What the Three DNS Records Actually Do

A common deliverability problem after switching email providers or adding a new sending service is that outgoing messages start landing in spam — or get rejected outright. In most cases, the cause is straightforward: the domain's DNS authentication records are missing, outdated, or don't cover the new sending infrastructure. Receiving mail servers check SPF, DKIM, and DMARC before deciding what to do with an incoming message. A domain without these records in place looks indistinguishable from a spoofed domain to those servers. This guide covers the complete SPF, DKIM, and DMARC setup process — what each record does, how to create it, how to test it, and how to roll out DMARC enforcement without disrupting legitimate email. The recommendations here are based on published IETF standards and best-practice guidance from Google, Microsoft, and CISA. DNS record syntax and provider-specific steps may vary; verify against your email provider's current documentation before making changes.

Why Email Authentication Fails — and Why It Matters More Than Ever

Email spoofing — sending messages that appear to come from a domain the sender does not control — has been a persistent problem since the early days of the internet. The core SMTP protocol used to deliver email was designed without authentication in mind, which means any server can technically claim to send mail from any domain. SPF, DKIM, and DMARC are the three DNS-based mechanisms that address this gap, and they have become increasingly important as major providers have tightened their filtering requirements. In 2024, Google and Yahoo both announced that bulk senders — domains sending more than 5,000 messages per day to their platforms — would be required to have SPF, DKIM, and DMARC configured or face delivery problems. While the threshold applies specifically to bulk senders, the underlying filtering logic affects all senders: domains without proper authentication records are more likely to be flagged as suspicious by spam filters, regardless of message volume. For business email, this means that authentication is no longer optional — it is a baseline requirement for reliable delivery. Many deliverability problems are linked to incomplete authentication setups rather than content issues. A domain may have SPF configured but no DKIM, or DKIM enabled but no DMARC policy to enforce alignment. Each gap leaves a different attack surface open and reduces the domain's reputation with receiving mail servers over time.

5 Core Concepts Behind SPF, DKIM, and DMARC

1. SPF — Declaring Which Servers Are Allowed to Send Your Email

An SPF record is a DNS TXT record that lists the IP addresses and mail servers authorized to send email on behalf of your domain. When a receiving server gets a message claiming to be from your domain, it checks your SPF record to see whether the sending server's IP address is on the authorized list. If it is, SPF passes. If it isn't, SPF fails — and depending on the receiving server's policy, the message may be flagged or rejected. A basic SPF record for a domain that sends only through Google Workspace looks like this: v=spf1 include:_spf.google.com ~all The include: directive pulls in Google's list of authorized sending IPs. The ~all at the end is a "soft fail" — messages from unauthorized servers are flagged but not rejected. Using -all (hard fail) rejects them outright, which is stricter but can cause problems if any legitimate sending source is missing from the record. One important limitation: SPF has a maximum of 10 DNS lookups per evaluation. Domains that send through multiple services (CRM, marketing platform, transactional email provider) can hit this limit, which causes SPF to fail even for legitimate messages. Auditing all sending sources before writing the SPF record helps avoid this.

2. DKIM — Signing Your Outgoing Messages Cryptographically

DKIM works differently from SPF. Instead of checking the sending server's IP address, it verifies that the message content has not been altered in transit. When DKIM is enabled, your mail server adds a cryptographic signature to each outgoing message using a private key. The corresponding public key is published in your DNS as a TXT record. Receiving servers retrieve the public key and use it to verify the signature. If the signature matches, DKIM passes — confirming both that the message came from an authorized source and that it hasn't been tampered with. A DKIM DNS record looks like this (the key value is abbreviated here): google._domainkey.yourdomain.com IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..." The selector (google in this example) is a label that allows a domain to have multiple DKIM keys — one per sending service. Most email providers generate the DKIM key pair for you and provide the DNS record value to copy into your DNS. The private key stays on the mail server; only the public key goes in DNS. DKIM does not prevent spoofing on its own — a spoofed message simply won't have a valid DKIM signature — but combined with DMARC, it becomes an enforcement mechanism.

3. DMARC — Tying SPF and DKIM Together with a Policy

DMARC is the policy layer that makes SPF and DKIM actionable. A DMARC record tells receiving servers what to do with messages that fail SPF or DKIM alignment, and instructs them to send reports back to the domain owner. DMARC alignment means that the domain in the message's "From" header must match the domain that passed SPF or DKIM — this prevents a common attack where a spoofed message passes SPF because it was sent from a legitimate server, but the "From" address belongs to a different domain. A minimal DMARC record looks like this: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com The p=none policy means no action is taken on failing messages — they are delivered normally, but reports are sent to the specified address. This is the recommended starting point. Once reports confirm that all legitimate sending sources are passing authentication, the policy can be tightened to p=quarantine (send failing messages to spam) or p=reject (block them entirely).

4. DMARC Alignment — The Concept Most Guides Skip

DMARC alignment is one of the most commonly misunderstood aspects of email authentication setup. It is not enough for SPF or DKIM to pass — the domain that passes must align with the domain in the "From" header. For SPF, this means the domain in the SMTP envelope sender (the "Return-Path") must match the "From" domain. For DKIM, the domain in the DKIM signature's d= tag must match the "From" domain. Alignment can be "relaxed" (subdomains are allowed to match) or "strict" (exact match required). Relaxed alignment is the default and is appropriate for most organizations. A practical example: if your domain is example.com and you send marketing email through a third-party platform that signs messages with d=mail.example.com, relaxed DKIM alignment will pass because mail.example.com is a subdomain of example.com. Strict alignment would fail. Understanding alignment is important when reviewing DMARC reports — a message can show SPF=pass and DKIM=pass but still fail DMARC if neither passes alignment with the "From" domain.

5. DMARC Reporting — Reading the Data Before Tightening the Policy

⚠️ Worth knowing before you proceed: Do not move your DMARC policy from p=none to p=quarantine or p=reject until you have reviewed at least two to four weeks of DMARC aggregate reports. These reports, sent daily by participating receiving servers, show every source that sent email claiming to be from your domain — including sources you may not have known about, such as a CRM tool, a third-party newsletter platform, or an automated notification system. Moving to a strict policy before identifying and authenticating all legitimate sending sources will cause those sources' messages to be quarantined or rejected. DMARC aggregate reports are delivered as XML files; free tools like MXToolbox or Dmarcian can parse them into a readable format.

How to Set Up SPF, DKIM, and DMARC — Step by Step

Step 1: Auditing All Sources That Send Email From Your Domain

Before writing a single DNS record, identify every service that sends email using your domain in the "From" address. This typically includes your primary mail provider (Google Workspace, Microsoft 365, or a self-hosted server), but may also include a CRM platform, a transactional email service like SendGrid or Mailgun, a marketing automation tool, an e-commerce platform, or automated notification systems. Each of these sources needs to be included in your SPF record and, ideally, configured with its own DKIM key. A common mistake is writing an SPF record that covers only the primary mail provider, then discovering after DMARC enforcement that the CRM's messages are failing authentication. Listing all sending sources in a spreadsheet before starting makes the subsequent steps significantly more straightforward.

Step 2: Creating and Publishing the SPF Record

Log in to your DNS provider (your domain registrar, Cloudflare, Route 53, or wherever your domain's DNS is managed) and add a TXT record for your root domain (@ or yourdomain.com). The record value should list all authorized sending sources using include: directives for each provider, followed by ~all or -all. For example, a domain that sends through both Google Workspace and SendGrid would use: v=spf1 include:_spf.google.com include:sendgrid.net ~all Each email provider's documentation specifies the correct include: value for their infrastructure — use the value from your provider's current documentation rather than a generic example, as these values can change. After publishing the record, use MXToolbox's SPF lookup to verify it resolves correctly and check the DNS lookup count to ensure it stays within the 10-lookup limit.

Step 3: Enabling and Publishing DKIM

DKIM setup is done in two places: your email provider's admin console and your DNS. In the admin console (Google Workspace Admin, Microsoft 365 Admin Center, or your provider's equivalent), navigate to the DKIM or email authentication settings and generate a new DKIM key pair. The console will display a DNS TXT record value — a long string beginning with v=DKIM1; k=rsa; p= followed by the public key. Copy this value exactly and add it as a TXT record in your DNS at the hostname specified by your provider (typically something like google._domainkey.yourdomain.com). After the DNS record propagates (which may take up to 48 hours), return to the admin console and click the button to start DKIM signing. The console will verify that the DNS record is in place before activating signing. Repeat this process for each additional sending service that supports DKIM.

Step 4: Publishing a DMARC Record in Monitoring Mode

Add a TXT record at _dmarc.yourdomain.com with the following value as a starting point: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; fo=1 The rua tag specifies where aggregate reports are sent; ruf specifies where forensic (per-message failure) reports are sent. The fo=1 tag requests a forensic report whenever either SPF or DKIM fails, which provides more detail during the monitoring phase. Use a dedicated mailbox or alias for DMARC reports — the volume can be significant for domains with high sending volume. After publishing, send test messages from each of your identified sending sources and verify that they appear in the DMARC reports as passing.

Step 5: Reviewing Reports and Tightening the Policy

After two to four weeks of monitoring, review the DMARC aggregate reports to confirm that all legitimate sending sources are passing SPF or DKIM alignment. Any source showing failures needs to be investigated — either it is a legitimate sender that needs to be added to SPF or configured with DKIM, or it is an unauthorized source attempting to spoof your domain. Once all legitimate sources are passing, update the DMARC policy to p=quarantine and monitor for another one to two weeks before moving to p=reject. The incremental approach — none → quarantine → reject — is strongly recommended over jumping directly to reject, as it gives you time to catch any legitimate sources that were missed during the audit phase. A domain that reaches p=reject with all legitimate sources passing is considered fully DMARC-compliant.

Frequently Asked Questions — SPF, DKIM, and DMARC Setup

What is the difference between SPF, DKIM, and DMARC?

SPF specifies which mail servers are authorized to send email on behalf of your domain. DKIM adds a cryptographic signature to outgoing messages that receiving servers use to verify the message has not been altered in transit. DMARC ties SPF and DKIM together by telling receiving servers what to do with messages that fail either check — and sends reports back to the domain owner. All three work together; implementing only one or two provides incomplete protection and does not give you the enforcement or visibility that DMARC provides.

Do I need all three records — SPF, DKIM, and DMARC?

In most cases, yes. SPF and DKIM each address different aspects of email authentication, and DMARC requires at least one of them to be in place before it can function. Without DMARC, there is no enforcement mechanism — receiving servers may check SPF and DKIM but take no consistent action on failures. Without SPF or DKIM, DMARC has nothing to align against. The three records are designed to work as a system, and implementing all three is the recommended approach for any domain that sends business email.

Will setting up DMARC break my existing email?

A DMARC record set to monitoring mode (p=none) will not affect email delivery — it only generates reports. Problems can arise when the policy is tightened to quarantine or reject before SPF and DKIM are fully configured and verified. The recommended approach is to start with p=none, review the DMARC reports for two to four weeks to identify any legitimate sending sources that are failing authentication, fix those sources, and only then move to a stricter policy.

How do I check if my SPF, DKIM, and DMARC records are working?

Several free tools can verify your DNS authentication records. MXToolbox (mxtoolbox.com) offers SPF, DKIM, and DMARC lookup tools that show the current record and flag common configuration errors. Google Admin Toolbox (toolbox.googleapps.com) includes a DNS lookup and email header analyzer. Sending a test message to a Gmail or Outlook account and checking the message headers will also show whether SPF and DKIM passed — look for dkim=pass and spf=pass in the Authentication-Results header.

How much does it cost to set up SPF, DKIM, and DMARC?

Setting up SPF, DKIM, and DMARC records is free — the records are added to your domain's DNS at no additional cost beyond your existing DNS hosting fees. The only potential cost is time: configuring the records correctly and monitoring DMARC reports during the rollout period. Some organizations use paid DMARC reporting and management platforms (such as Dmarcian or Valimail) to simplify report analysis, but these are optional. Pricing for such platforms varies by plan and sending volume — check current vendor pricing before committing.

Conclusion & My Take

SPF, DKIM, and DMARC setup is one of the highest-value configuration tasks available to any domain owner who sends business email. The records are free to create, the process takes under an hour for most domains, and the protection they provide — against spoofing, phishing, and deliverability problems — is significant. The most common mistake is rushing the DMARC enforcement phase: moving to p=reject before all legitimate sending sources have been identified and authenticated will cause real messages to be blocked. The monitoring phase is not optional — it is where the actual work of authentication happens. If your domain currently has no authentication records, start with SPF and DKIM for your primary mail provider, then add a DMARC record in monitoring mode. If you already have SPF and DKIM but no DMARC, adding a p=none DMARC record is a low-risk first step that immediately gives you visibility into who is sending email from your domain. If you have all three but your DMARC policy is still at p=none after several months, reviewing the reports and moving toward enforcement is the logical next step. Have you recently set up or audited your domain's email authentication records? I would be curious to hear what you found in your DMARC reports during the monitoring phase — feel free to share in the comments below.