What SPF, DKIM, and DMARC Actually Do

The Simple Version

SPF tells receiving mail servers which servers are allowed to send email from your domain. DKIM attaches a digital signature to every email proving it wasn't altered in transit. DMARC ties the two together and tells receivers what to do if a message fails both checks. You need all three. Without them, Gmail, Yahoo, and Outlook will either spam or reject your cold emails.

Think of it this way. SPF is a guest list at the door. It says "these specific servers are allowed to send mail on behalf of this domain." DKIM is a wax seal on an envelope. It proves the email is authentic and hasn't been tampered with since it left the server. DMARC is the policy that tells the bouncer what to do when someone shows up without being on the guest list and without a seal.

All three are published as TXT records in your domain's DNS settings. They're not software you install. They're just lines of text that sit in your DNS zone file, and every receiving mail server checks them before deciding whether to accept your email.

Since February 2024, Google and Yahoo require SPF, DKIM, and DMARC for anyone sending more than 5,000 emails per day. Microsoft started enforcing similar requirements in 2025. But even if you're sending well under those thresholds, having proper authentication significantly improves your inbox placement. Authenticated domains are 2.7x more likely to reach the inbox.

Before You Start: What You'll Need

Before touching DNS records, make sure you have these things ready:

  • Access to your DNS provider - This is wherever your domain's nameservers point. Common providers include Cloudflare, GoDaddy, Namecheap, and Google Domains. If you're not sure, check your domain registrar's settings.
  • Access to your email provider's admin panel - Google Workspace Admin Console, Microsoft 365 Defender, or whatever platform you use for sending. You'll need to generate DKIM keys here.
  • A list of every service that sends email from your domain - This includes your email provider, your cold email tool, your marketing platform, and anything else that sends on your behalf. You need their SPF include values.

Important: Do This on Your Sending Domains

If you're sending cold email from dedicated sending domains (like "getacme.com" instead of "acme.com"), set up authentication on those domains. Every domain you send from needs its own SPF, DKIM, and DMARC records. For more on why you should use separate domains for cold email, see our complete deliverability guide.

Implementation Order

Set them up in this order: SPF first, then DKIM, then DMARC. SPF is the simplest and gives you immediate protection. DKIM takes slightly longer because you need to generate keys through your email provider. DMARC should come last because it depends on SPF and DKIM already being in place.

After adding SPF and DKIM records, wait 24-48 hours for DNS propagation before enabling DMARC. This gives the records time to spread across the internet.

Setting Up SPF (Step by Step)

How SPF Works

An SPF record is a single TXT record on your domain that lists every IP address and server authorized to send email from that domain. When Gmail receives an email claiming to be from "getacme.com," it looks up the SPF record for getacme.com and checks whether the sending server is on the list.

Building Your SPF Record

Every SPF record follows the same format:

DNS TXT Record v=spf1 include:_spf.google.com include:sendgrid.net ~all

Let's break that down:

  • v=spf1 - Required. Tells the server this is an SPF record. Must appear first.
  • include:_spf.google.com - Authorizes Google Workspace to send from your domain.
  • include:sendgrid.net - Authorizes SendGrid to send from your domain.
  • ~all - Soft fail. Tells receiving servers to flag (but not reject) emails from unauthorized servers. Use -all (hard fail) once you're confident everything is working.

Step-by-Step Instructions

1

List every service that sends email from this domain

Check your email provider (Google Workspace, Microsoft 365), your cold email tool, any marketing platforms, and any transactional email services. Write down each one.

2

Find the SPF include value for each service

Each provider has a specific include value. See the reference table below for common providers. If your tool isn't listed, check their documentation for "SPF setup" or "DNS authentication."

3

Build your SPF record string

Combine all includes into a single record. If you use Google Workspace and a cold email tool, it might look like: v=spf1 include:_spf.google.com include:sendgrid.net ~all

4

Add the TXT record in your DNS provider

Log into your DNS provider. Create a new TXT record with: Host/Name set to @ (root domain), Value set to your SPF string, TTL set to Auto or 3600.

5

Verify there's only ONE SPF record

This is critical. Your domain must have exactly one SPF TXT record. If you already have one, edit it to add the new includes. Do not create a second SPF record. Multiple SPF records cause a PermError and break authentication entirely.

The 10-Lookup Limit

SPF records are limited to 10 DNS lookups (per RFC 7208). Every include: counts as at least one lookup, and nested includes add more. If you exceed 10, the entire SPF check fails with a PermError, which is treated the same as having no SPF at all. If you're running out of lookups, remove any services you no longer use, or look into SPF flattening (which replaces includes with static IP addresses).

Setting Up DKIM (Step by Step)

How DKIM Works

When you enable DKIM, your email server signs every outgoing email with a private key. The receiving server then checks the signature against a public key published in your DNS. If the signature matches, the server knows the email is legitimate and hasn't been modified.

The setup has two parts: generating the key pair in your email provider, then publishing the public key as a DNS record.

For Google Workspace

1

Open Google Workspace Admin Console

Go to admin.google.com. Navigate to Apps, then Google Workspace, then Gmail, then "Authenticate email."

2

Select your domain and generate a new DKIM key

Choose 2048-bit key length. The default selector is google. You can leave it as-is unless you have a reason to change it.

3

Copy the DNS record value Google provides

Google gives you a TXT record value that starts with v=DKIM1; k=rsa; p=... followed by a long string of characters. Copy the entire value.

4

Add the TXT record in your DNS provider

Create a new TXT record with Host/Name set to google._domainkey and Value set to the key Google provided. Set TTL to Auto or 3600.

5

Go back to Google Admin and click "Start authentication"

Wait at least 48 hours after adding the DNS record before clicking this button. Google needs time to verify the record has propagated.

For Microsoft 365

Microsoft 365 uses CNAME records instead of TXT for DKIM. You need to create two CNAME records:

CNAME Record 1 Host: selector1._domainkey Points to: selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com
CNAME Record 2 Host: selector2._domainkey Points to: selector2-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

Replace "yourdomain-com" with your actual domain using hyphens instead of dots. After adding both CNAMEs, go to Microsoft Defender for Office 365 and enable DKIM signing for your domain. Always copy the exact values from the Defender portal rather than constructing them manually.

DKIM for Cold Email Tools

Most cold email platforms (Instantly, Smartlead, Saleshandy, etc.) handle DKIM through your connected email account. If you connect a Google Workspace or Microsoft 365 account, the DKIM signing happens through that provider. You don't need a separate DKIM record for the cold email tool itself. Check your tool's documentation to confirm.

Setting Up DMARC (Step by Step)

How DMARC Works

DMARC checks whether incoming emails pass SPF or DKIM (or both) and whether the domain in the "From" header aligns with the domain checked by SPF/DKIM. If alignment fails, DMARC tells the receiving server what to do: nothing (monitor), quarantine (send to spam), or reject (block entirely).

Your First DMARC Record

Start with a monitoring-only policy. This lets you collect data about who's sending email from your domain without affecting delivery.

DNS TXT Record Host: _dmarc Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Breaking that down:

  • v=DMARC1 - Required. Must appear first. Identifies this as a DMARC record.
  • p=none - Policy is monitoring only. No emails get blocked or quarantined.
  • rua=mailto:... - Where to send aggregate DMARC reports. Use a dedicated email address or a DMARC monitoring service.

DMARC Report Monitoring

Raw DMARC reports are XML files that are painful to read manually. Use a free service to parse them:

  • Postmark DMARC (dmarc.postmarkapp.com) - Free weekly digests. Simple and clean.
  • EasyDMARC - Free tier with up to 1,000 emails/month. Good dashboard.
  • dmarcian - Free tier available. More detailed analytics for larger senders.

If you use a monitoring service, you can add their reporting address alongside yours:

DMARC with Postmark reporting v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com,mailto:re+yourtoken@dmarc.postmarkapp.com

Tightening Your Policy Over Time

After 2-4 weeks of monitoring with p=none, review your DMARC reports. If SPF and DKIM are passing consistently and no legitimate email is failing alignment, move to p=quarantine. This sends failing emails to spam instead of the inbox.

Once you're fully confident (usually after another 2-4 weeks at quarantine), move to p=reject. This blocks unauthenticated email entirely. The full progression looks like this:

Week 1-4: Monitor v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
Week 5-8: Quarantine v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com
Week 9+: Reject v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

How to Verify Everything Works

After adding all three records, you need to confirm they're actually working. DNS changes can take up to 48 hours to propagate, so give it at least a day before testing.

Free Verification Tools

  • MXToolbox (mxtoolbox.com) - The industry standard. Has separate checkers for SPF, DKIM, and DMARC. Enter your domain and it shows the record, any errors, and a pass/fail status.
  • Google Admin Toolbox (toolbox.googleapps.com/apps/checkmx) - Free MX and authentication checker from Google.
  • Red Sift Investigate (redsift.com/tools/investigate) - Checks all three protocols in one scan. No account required.

The Email Header Test

The most reliable test is sending an email and checking the headers. Send a message from your domain to a Gmail address you control. Open the email, click the three dots, and select "Show original." Look for these lines:

What you want to see in email headers SPF: PASS DKIM: PASS DMARC: PASS

If any of these show FAIL, go back and check the corresponding DNS record. Common issues: a typo in the SPF include, a selector mismatch in DKIM, or the DMARC record placed on the wrong host (it must be on _dmarc.yourdomain.com).

Check your domain's authentication right now

Use our free SPF/DKIM/DMARC checker to see if your DNS records are configured correctly.

Check Your Domain

The 10 Most Common Mistakes

We've seen hundreds of domains misconfigure their authentication. These are the mistakes that come up again and again.

  1. Multiple SPF records. Your domain must have exactly one SPF TXT record. Two SPF records cause a PermError. If you need to authorize a new service, edit your existing record to add the include.
  2. Exceeding the 10 DNS lookup limit. Every include: in your SPF record counts toward the limit. Nested includes count too. Exceed 10 and the entire SPF check fails silently.
  3. Missing v=spf1 prefix. If your SPF record doesn't start with v=spf1, receiving servers ignore it entirely.
  4. DKIM key not activated. Adding the DNS record isn't enough. You also need to enable DKIM signing in your email provider's admin panel. The record and the signing are two separate steps.
  5. Selector mismatch. The DKIM selector in your DNS record must match the selector your email provider uses to sign messages. Copy directly from your provider's admin panel.
  6. DKIM key truncation. DKIM public keys are long. Some DNS providers cut off values over 255 characters. If your key looks incomplete, split it into quoted strings or check if your provider has a workaround.
  7. DMARC on the wrong host. The DMARC record must be a TXT record on _dmarc.yourdomain.com. A common mistake is putting it on the root domain without the _dmarc prefix.
  8. Staying on p=none forever. Monitoring is the starting point, not the destination. A p=none DMARC policy doesn't actually protect your domain. Move to p=quarantine and eventually p=reject once your reports are clean.
  9. Not checking alignment. DMARC requires that either SPF or DKIM aligns with the domain in your "From" header. If your sending service uses a different return-path domain, SPF won't align even if it passes. Make sure at least DKIM aligns.
  10. Forgetting secondary domains. If you use sending domains for cold email (and you should), each one needs its own SPF, DKIM, and DMARC records. Setting these up on your primary domain doesn't cover your sending domains.

SPF Include Values for Popular Providers

Here's a quick reference table for the most common email services. Use these values in your SPF record.

Provider SPF Include Value
Google Workspace include:_spf.google.com
Microsoft 365 include:spf.protection.outlook.com
Zoho Mail include:zoho.in
SendGrid include:sendgrid.net
Mailgun include:mailgun.org
Mailchimp / Mandrill include:servers.mcsv.net
Amazon SES include:amazonses.com
Postmark include:spf.mtasv.net

What About Cold Email Tools?

Most cold email tools (Instantly, Smartlead, Saleshandy, Lemlist, etc.) send through your connected Google Workspace or Microsoft 365 account. They don't need a separate SPF include because they use your email provider's servers. However, some tools that use their own SMTP infrastructure will require an additional include. Always check your specific tool's setup documentation.

Example: Google Workspace + SendGrid

Complete SPF Record v=spf1 include:_spf.google.com include:sendgrid.net ~all

Example: Microsoft 365 + Mailgun + Mailchimp

Complete SPF Record v=spf1 include:spf.protection.outlook.com include:mailgun.org include:servers.mcsv.net ~all

Final Verification Checklist

  • ✓ SPF record starts with v=spf1 and ends with ~all or -all
  • ✓ Only ONE SPF record exists for the domain
  • ✓ Total DNS lookups are 10 or fewer
  • ✓ DKIM key published at correct selector (e.g., google._domainkey)
  • ✓ DKIM signing enabled in email provider admin panel
  • ✓ DMARC record published at _dmarc.yourdomain.com
  • ✓ DMARC starts with p=none and includes rua=mailto: for reports
  • ✓ Test email shows PASS for SPF, DKIM, and DMARC in headers
  • ✓ All sending domains have their own separate records