SPF, DKIM, and DMARC: The Complete Setup Guide for Email Senders

Gmail and Yahoo started rejecting unauthenticated bulk email in 2024. Microsoft followed with similar enforcement for Outlook and Hotmail. If your domain doesn't have SPF, DKIM, and DMARC configured correctly, your emails either land in spam or get rejected outright. No amount of great content or perfect list hygiene can override a failed authentication check.

Despite this, research monitoring over one million domains found that only about 10% have full DMARC protection with a reject policy. That means 90% of domains are either partially protected or completely exposed. If you haven't set up all three protocols, or you're not sure whether yours are configured correctly, this guide walks you through the entire process from scratch.

What Each Protocol Does

What are SPF, DKIM, and DMARC?

SPF, DKIM, and DMARC are three email authentication protocols that work together to prove your emails are legitimate. SPF authorizes which servers can send email for your domain. DKIM adds a cryptographic signature proving each message wasn't altered in transit. DMARC ties SPF and DKIM together, telling receivers what to do when authentication fails and providing reports back to you. All three are implemented through DNS records on your domain.

Think of them as layers of a security system:

• SPF is the guest list at the door. It tells receiving servers which IP addresses and mail servers are authorized to send email on behalf of your domain. If an email comes from a server not on the list, it fails SPF.
• DKIM is a tamper-proof seal. It attaches a cryptographic signature to every email. The receiving server uses a public key published in your DNS to verify the signature. If the message was modified in transit, the signature breaks and the check fails.
• DMARC is the decision-maker. It checks whether SPF or DKIM passed and whether the authenticated domain aligns with the "From" address the recipient sees. Then it applies your policy: do nothing (monitor), send to spam (quarantine), or reject the message entirely.

Setting Up SPF

SPF is the easiest of the three to set up. It's a single DNS TXT record that lists every server authorized to send email for your domain.

Step 1: Identify All Your Sending Sources

Before creating your SPF record, list every service that sends email from your domain. Common sources include:

• Your hosting provider's mail server
• Google Workspace or Microsoft 365
• Your ESP (Mailchimp, Klaviyo, SendGrid, etc.)
• Transactional email services (Postmark, SES, etc.)
• CRM systems that send email (HubSpot, Salesforce)
• Help desk tools (Zendesk, Freshdesk)

Missing a sending source means emails from that service will fail SPF. Get the complete list before you create the record.

Step 2: Build Your SPF Record

An SPF record is a DNS TXT record on your domain. The format is:

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

The key components:

• v=spf1 identifies this as an SPF record
• include: statements authorize each sending service. Your ESP will provide the correct include value in their documentation.
• ~all (soft fail) means unauthorized servers are flagged but not rejected. Use -all (hard fail) once you're confident all sources are listed.

Step 3: Add the Record to Your DNS

Log into your DNS provider (GoDaddy, Cloudflare, Namecheap, Route 53, etc.), add a TXT record with your domain as the host, and paste your SPF record as the value. DNS changes typically propagate within 10-60 minutes, though some providers may take up to 48 hours.

Setting Up DKIM

DKIM is more involved than SPF because it requires generating a cryptographic key pair. The good news: most email services handle the key generation for you. Your job is to add the public key to your DNS.

Step 1: Generate DKIM Keys in Your Email Service

Go to your ESP or email service's settings panel and look for "Domain Authentication," "DKIM Setup," or "Email Authentication." The service will generate a DKIM key pair and give you a DNS record to add. This is typically a CNAME or TXT record.

Step 2: Add the DNS Record

The record your email service provides will include a selector (a name like google._domainkey or s1._domainkey) and a value (the public key or a CNAME target). Add this to your DNS as instructed. Each email service you use may need its own DKIM record with a unique selector.

Step 3: Verify the Setup

After DNS propagation, use your email service's verification tool to confirm the DKIM record is detected. Then send a test email and check the email headers for dkim=pass in the authentication results.

Unlike SPF, you can have multiple DKIM records for the same domain. Each sending service gets its own record with a different selector. This means adding a new ESP doesn't break existing DKIM authentication.

Setting Up DMARC

DMARC is the protocol most senders skip, and it's the one that matters most for enforcement. Without DMARC, SPF and DKIM authenticate messages but don't tell receivers what to do when authentication fails. DMARC closes that gap.

Step 1: Create a Basic DMARC Record

Start with a monitoring-only policy. This collects data about who is sending email from your domain without blocking anything:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

The components:

• v=DMARC1 identifies this as a DMARC record
• p=none sets the policy to monitoring only (no blocking)
• rua= specifies where to send aggregate reports (use a mailbox you monitor)

Step 2: Add to DNS

Add a TXT record with the host _dmarc.yourdomain.com (or just _dmarc depending on your DNS provider's interface) and your DMARC record as the value.

Step 3: Monitor Reports

DMARC aggregate reports arrive as XML files. They show every server that sent email using your domain, whether SPF and DKIM passed, and whether the results aligned with your "From" address. Review these reports for 2-4 weeks to identify any legitimate sending sources that are failing authentication.

Rolling Out DMARC Safely

Don't jump straight to a reject policy. A rushed rollout can block legitimate email from services you forgot to authenticate. Follow this progression:

Phase 1 (Weeks 1-4): Monitor. Set p=none and review reports. Identify all legitimate sending sources. Fix any SPF or DKIM failures for authorized services.

Phase 2 (Weeks 5-8): Quarantine. Change to p=quarantine; pct=10. This sends 10% of failing messages to spam instead of the inbox. Monitor for any impact on legitimate delivery. Gradually increase the percentage (25%, 50%, 100%) as you confirm no legitimate email is affected.

Phase 3 (Week 9+): Reject. Once quarantine at 100% shows no false positives, switch to p=reject. This tells receivers to drop any email from your domain that fails DMARC authentication. Your domain is now fully protected against spoofing.

The full rollout typically takes 2-3 months. Rushing it risks blocking legitimate email. Taking your time ensures nothing breaks.

Common Authentication Mistakes

These are the errors that break authentication most often:

• Multiple SPF records. You can only have one SPF TXT record per domain. Adding a second one (instead of merging the includes) causes both to fail. Combine all sending sources into a single record.
• Exceeding the SPF lookup limit. SPF allows a maximum of 10 DNS lookups. Each include: counts as at least one, and nested includes count too. Exceeding the limit causes SPF to return a permanent error (PermError), which many receivers treat as a fail.
• Forgetting a sending source. Every tool that sends email from your domain needs to be in your SPF record and have DKIM configured. Forgot your help desk sends password resets? Those emails will fail authentication.
• Misaligned domains. DMARC requires alignment: the domain in the "From" header must match the domain authenticated by SPF or DKIM. Sending from marketing@yourdomain.com through a service that authenticates as sender.espservice.com will fail DMARC alignment without proper DKIM setup.
• Jumping to p=reject too fast. Going straight to reject without monitoring catches legitimate email in the crossfire. Always start with p=none and progress gradually.

Authentication + Verification: The Full Stack

Email authentication and email verification solve different sides of the same problem. Authentication proves your emails are legitimate. Verification proves the addresses you're sending to are real. Together, they maximize deliverability.

Here's how they complement each other:

Authentication gets your emails past the front door. Verification ensures you're only knocking on doors where someone's home. Run your list through bulk verification to remove invalid addresses, then set up authentication to ensure every valid address actually receives your messages. Use the free email checker to spot-test individual addresses.

Frequently Asked Questions

Do I need all three protocols, or is one enough?

You need all three. SPF and DKIM authenticate individual messages, but without DMARC, receivers don't know what to do when authentication fails. Gmail and Yahoo require all three for bulk senders (5,000+ emails per day). Even if you send fewer, having all three configured is the standard that inbox providers expect and reward with better deliverability.

Will setting up authentication fix my spam folder problem?

Authentication is necessary but not sufficient. It proves your emails are legitimate, which is a prerequisite for inbox placement. But if your list has high bounce rates, low engagement, or spam complaints, you'll still face deliverability issues. Authentication + clean lists + engaged recipients is the full formula. Real-time email verification helps keep the list clean.

How do I check if my authentication is working?

Send a test email to a Gmail account. Open the message, click the three dots, and select "Show original." Look for the Authentication-Results section. You should see spf=pass, dkim=pass, and dmarc=pass. You can also use tools like MXToolbox to check your DNS records directly.

Can authentication break my existing email setup?

Yes, if done incorrectly. The most common issue is creating an SPF record that's missing a legitimate sending service, which causes those emails to fail authentication. This is why DMARC should start with p=none (monitor-only) so you can identify problems before any email gets blocked.

How long does it take to set up all three protocols?

The DNS changes themselves take 30-60 minutes of work. DNS propagation may take up to 48 hours. The DMARC monitoring phase (before moving to enforcement) takes 4-8 weeks. Budget 2-3 months for the full rollout from initial setup to p=reject enforcement.

Get Authenticated Today

SPF, DKIM, and DMARC aren't optional anymore. They're baseline requirements that inbox providers enforce. Every day your domain runs without proper authentication is a day your emails are at risk of spam placement or outright rejection.

Start with SPF (the easiest), add DKIM for each sending service, then publish a DMARC record in monitor mode. Review reports, fix any issues, and gradually tighten your policy. Combine authentication with email list verification to build the complete deliverability stack: authenticated sender, verified recipients, and clean sending infrastructure. Check pricing to get started with verification credits.