SPF, DKIM and DMARC Setup Guide: How to Configure Email Authentication to Improve Deliverability, Prevent Spoofing and Land in the Inbox
Summarize this article with:
On this page
Why Email Authentication Matters
Every email you send passes through authentication checks before it reaches the recipient's inbox. Gmail, Outlook, Yahoo and other major email providers check whether the sending server is authorised to send email on behalf of your domain. If these checks fail, your email goes to spam or is rejected outright.
As of February 2024, Gmail and Yahoo enforce stricter requirements for bulk senders (anyone sending 5,000+ messages per day to Gmail or Yahoo addresses): SPF or DKIM authentication is required, DMARC must be set up with at least a p=none policy, and messages must pass DMARC alignment. Senders who do not meet these requirements see their email throttled or rejected.
Even if you send fewer than 5,000 messages per day, authentication directly affects whether your email lands in the inbox or the spam folder. Setting up all three protocols (SPF, DKIM, DMARC) is the single most impactful thing you can do for email deliverability.
The Three Protocols
| Protocol | What it does | How it works | What happens without it |
|---|---|---|---|
| SPF (Sender Policy Framework) | Tells receiving servers which mail servers are authorised to send email from your domain | You publish a DNS TXT record on your domain listing every IP address and service that sends email on your behalf; when a receiving server gets an email from your domain, it checks this list; if the sending server is on the list, SPF passes; if not, SPF fails | Receiving servers cannot verify that the email actually came from your domain; anyone can send email claiming to be from your domain (spoofing); your email is more likely to be flagged as spam |
| DKIM (DomainKeys Identified Mail) | Digitally signs your outgoing email so the recipient can verify it was not altered in transit and was sent by an authorised sender | Your mail server attaches a cryptographic signature to each outgoing email using a private key; you publish the corresponding public key as a DNS TXT record; the receiving server uses the public key to verify the signature; if it matches, DKIM passes | Receiving servers cannot verify email integrity; man-in-the-middle alterations go undetected; your email is more likely to be treated as suspicious |
| DMARC (Domain-based Message Authentication, Reporting and Conformance) | Tells receiving servers what to do when SPF or DKIM checks fail, and sends you reports about authentication results | You publish a DNS TXT record specifying your DMARC policy: p=none (monitor only, take no action on failures), p=quarantine (send failures to spam), or p=reject (reject failures outright); DMARC also requires "alignment" -- the domain in the From header must match the domain authenticated by SPF or DKIM | Receiving servers make their own decisions about failed authentication (usually spam or reject); you get no visibility into who is sending email as your domain; you cannot detect spoofing or phishing attempts using your domain |
Step-by-Step Setup
Step 1: Audit your current sending sources
Before creating DNS records, list every service that sends email from your domain:
| Source type | Examples | How to find them |
|---|---|---|
| Your email provider (transactional email for your team) | Google Workspace, Microsoft 365, Zoho Mail, Fastmail, Rackspace | Check your MX records: these point to your email provider |
| Marketing email platform | Mailchimp, ActiveCampaign, ConvertKit, HubSpot, Brevo, Constant Contact | Check your marketing team: which platform sends newsletters, drip campaigns, promotional emails? |
| Transactional email service | SendGrid, Postmark, Amazon SES, Mailgun, SparkPost | Check your development team: which service sends password resets, order confirmations, receipts, notifications? |
| CRM | Salesforce, HubSpot, Pipedrive, Zoho CRM | Some CRMs send email directly (not through your email provider); check if your CRM sends email as your domain |
| Help desk / support platform | Zendesk, Freshdesk, Intercom, Help Scout | Support platforms typically send email as support@yourdomain.com |
| Cold outreach tool | Lemlist, Instantly, Woodpecker, Smartlead, Apollo | Cold outreach tools send email through your email accounts or through their own servers using your domain |
| Form builder / survey tool | Typeform, JotForm, SurveyMonkey | Some form builders send confirmation emails as your domain |
| Other | Billing (Stripe, QuickBooks), HR (Gusto, BambooHR), project management (Monday.com, Asana, ClickUp notifications) | Any SaaS tool that sends email notifications "from" your domain |
Step 2: Set up SPF
| Action | Details |
|---|---|
| Create or edit the SPF TXT record | Go to your domain's DNS management (your domain registrar or DNS provider: Cloudflare, Namecheap, GoDaddy, Route 53, Google Domains, etc.); create a TXT record on your root domain (e.g., example.com) |
| Record format | v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net -all -- This example authorises Google Workspace, Mailchimp and SendGrid; replace with your actual sending services |
| Key rules | Only one SPF record per domain (multiple SPF records cause all checks to fail); use include: for each service (each service's documentation tells you what to include); end with -all (hard fail: reject anything not listed) or ~all (soft fail: flag but do not reject); SPF allows a maximum of 10 DNS lookups -- each include: typically counts as 1-2 lookups; if you exceed 10, SPF breaks (use an SPF flattening service like AutoSPF or dmarcian if needed) |
| Verify | Use a free SPF checker: MXToolbox SPF Lookup, dmarcian SPF Surveyor, or send a test email to mail-tester.com |
Step 3: Set up DKIM
| Action | Details |
|---|---|
| Generate DKIM keys | Each sending service provides its own DKIM setup: Google Workspace: Admin Console > Apps > Google Workspace > Gmail > Authenticate email; Mailchimp: Website > Domains > Authenticate; SendGrid: Settings > Sender Authentication > Domain Authentication; the service generates a public key for you to add to DNS |
| Add the DNS record | The service gives you a TXT or CNAME record to add to your DNS; it typically looks like: Name: selector._domainkey.example.com; Value: v=DKIM1; k=rsa; p=MIGfMA0GCS... (a long string that is the public key) |
| Key rules | Each sending service gets its own DKIM selector (a unique name like google._domainkey, k1._domainkey, s1._domainkey); you can have multiple DKIM records (unlike SPF, there is no limit); set up DKIM for every service that sends email from your domain |
| Verify | Use MXToolbox DKIM Lookup or check the email headers of a test message (look for dkim=pass in the Authentication-Results header) |
Step 4: Set up DMARC
| Action | Details |
|---|---|
| Start with monitoring (p=none) | Create a TXT record: Name: _dmarc.example.com; Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100 |
| What each tag means | p=none: policy is monitor only (do not quarantine or reject failed emails); rua=mailto:...: send aggregate reports (daily XML summaries of authentication results) to this address; ruf=mailto:...: send forensic reports (individual failure reports) to this address; adkim=r: relaxed DKIM alignment (subdomains are allowed); aspf=r: relaxed SPF alignment; pct=100: apply the policy to 100% of messages |
| Monitor for 2-4 weeks | DMARC aggregate reports tell you which servers are sending email as your domain and whether they pass SPF and DKIM; use a DMARC report analyser to read the XML reports: dmarcian, Postmark DMARC (free), Valimail; identify any legitimate sending sources that are failing authentication and fix their SPF/DKIM setup before tightening the policy |
| Tighten the policy | After all legitimate sources pass authentication, change p=none to p=quarantine (send failures to spam); monitor for another 2-4 weeks; then change to p=reject (reject failures outright); p=reject is the strongest protection against spoofing and phishing |
Common Mistakes
| Mistake | What happens | How to fix |
|---|---|---|
| Multiple SPF records on the same domain | SPF fails for all email (the standard requires exactly one SPF record per domain; if there are two, receivers treat it as a permanent error) | Merge all include: directives into a single SPF record |
| Exceeding 10 DNS lookups in SPF | SPF returns a "permerror" result, which many receivers treat as a failure | Count your lookups: each include:, a:, mx:, and redirect= counts as one lookup; include: chains can add nested lookups; use an SPF flattening tool to replace include: directives with IP addresses (which do not count as lookups) |
| Not setting up DKIM for all sending services | Email from services without DKIM fails DMARC alignment even if SPF passes (DMARC requires either SPF or DKIM to pass AND align; if only SPF is set up and the service sends from a different Return-Path domain, SPF alignment fails, and without DKIM, DMARC fails) | Set up DKIM for every service that sends email from your domain |
| Jumping straight to p=reject without monitoring | Legitimate email gets rejected because a sending source was missed or misconfigured; once email is rejected, the recipient never sees it (unlike quarantine, where they can check spam) | Always start with p=none, monitor reports for 2-4 weeks, fix all issues, then move to quarantine, then reject |
| Using a personal email (gmail.com, outlook.com) for cold outreach or marketing | You cannot set up SPF, DKIM, or DMARC on gmail.com or outlook.com (you do not own those domains); bulk sending from a free email provider violates Gmail's and Yahoo's sender requirements | Use a custom domain for all business email; set up authentication on that domain |
After Authentication: Maintaining Deliverability
Authentication is the foundation, but deliverability also depends on list quality. Sending authenticated email to invalid addresses still damages your sender reputation (high bounce rates trigger spam filters regardless of authentication status). Before running campaigns, consolidate your contact lists from your CRM exports (CSV), marketing platform exports (CSV), form submission exports (CSV) and any other sources. Upload them to Email Extractor to extract and deduplicate email addresses, then run the deduplicated list through a verification service to remove invalid addresses before sending.
