SPF, DKIM & DMARC Setup Guide for Cold Email Senders
If you are sending cold emails without properly configured SPF, DKIM, and DMARC records, you are handicapping your deliverability from the start. These three email authentication protocols are the foundation of email trust on the internet. Without them, receiving email servers have no way to verify that your emails are legitimately from you - and their default response is to treat unverified senders as suspicious.
This guide explains what each protocol does, why it matters specifically for cold email senders, and gives you step-by-step instructions to set everything up correctly on Google Workspace - the most popular email provider for cold outreach. Even if you are not technical, you can follow these steps and have everything configured in under 30 minutes.
Why Email Authentication Matters for Cold Email
Email authentication matters for everyone who sends email, but it is especially critical for cold email senders. Here is why:
You have no existing relationship with your recipients. When you send a cold email, the receiving server has no history with you. It cannot rely on past positive interactions to decide whether your email is trustworthy. Authentication records are the first thing it checks to establish baseline legitimacy.
Cold email is higher risk by nature. Email providers know that a large percentage of spam comes in the form of unsolicited email. Proper authentication helps you separate yourself from the bad actors and signal that you are a legitimate sender.
Authentication failures compound. If your SPF record is misconfigured and some of your emails fail authentication, those failures damage your domain reputation. A damaged reputation means worse deliverability, which means lower engagement, which further damages reputation. The spiral is hard to reverse.
Major providers are getting stricter. Google and Yahoo both implemented stricter authentication requirements in 2024, and enforcement has only tightened since. Emails from domains without proper SPF, DKIM, and DMARC are increasingly likely to be rejected outright, not just filtered to spam.
What Is SPF (Sender Policy Framework)?
SPF is a DNS record that tells the world which email servers are authorized to send email on behalf of your domain. Think of it as a guest list for your domain's email - if a server is not on the list, email providers know the email is either forwarded or potentially forged.
How SPF Works
When you send an email from your domain (e.g., you@yourdomain.com), the receiving server looks up your domain's SPF record in DNS. The SPF record contains a list of authorized IP addresses and services. If the sending server's IP matches one on the list, the SPF check passes. If not, it fails.
An SPF record looks like this in your DNS settings:
Type: TXT
Host: @ (or your domain name)
Value: v=spf1 include:_spf.google.com ~all
This record says: "Only Google's email servers are authorized to send email for this domain. Emails from any other server should be treated with suspicion (~all means soft fail)."
Setting Up SPF for Google Workspace
- Log in to your domain registrar's DNS management panel (GoDaddy, Namecheap, Cloudflare, etc.).
- Navigate to DNS settings for your sending domain.
- Look for an existing TXT record with "v=spf1" in the value. If one exists, you will need to modify it rather than create a new one. You can only have one SPF record per domain.
- If no SPF record exists, create a new TXT record with host "@" and value: v=spf1 include:_spf.google.com ~all
- If an SPF record already exists (e.g., from another email service), add Google's include before the ~all. For example: v=spf1 include:_spf.google.com include:sendgrid.net ~all
- Save the record. DNS changes can take up to 48 hours to propagate, though most propagate within 1-4 hours.
Common SPF mistake: Creating multiple SPF records instead of one record with multiple includes. Having two TXT records that both start with "v=spf1" will cause both to fail. Always merge into a single record.
What Is DKIM (DomainKeys Identified Mail)?
DKIM is a cryptographic authentication method that adds a digital signature to every email you send. The receiving server uses a public key published in your DNS to verify that the email was actually sent by you and that the content was not modified in transit.
How DKIM Works
When you send an email, your email server uses a private key to create a unique signature based on the email's content. This signature is added to the email's headers. When the receiving server gets the email, it retrieves your public key from your DNS records and uses it to verify the signature. If the signature matches, the email passes DKIM. If the content was altered in any way, the signature will not match and the check fails.
DKIM provides two assurances: the email genuinely came from your domain, and the content has not been tampered with between sending and delivery.
Setting Up DKIM for Google Workspace
- Log in to Google Admin console (admin.google.com).
- Navigate to Apps, then Google Workspace, then Gmail.
- Click on "Authenticate email" (under the "Compliance" or "Authentication" section, depending on your admin console version).
- Select your domain and click "Generate New Record."
- Choose your DKIM key bit length. Select 2048-bit if your DNS provider supports it (most modern providers do). If not, use 1024-bit.
- Google will generate a TXT record value. Copy it.
- Go to your domain registrar's DNS management panel.
- Create a new TXT record with the host name that Google specifies (typically google._domainkey) and paste the generated value.
- Save the DNS record and wait for propagation (1-48 hours).
- Return to Google Admin console and click "Start Authentication." Google will verify that the DNS record exists and matches.
Common DKIM mistake: Not clicking "Start Authentication" in Google Admin after adding the DNS record. The record must be both published in DNS and activated in Google Workspace. Missing either step means DKIM will not work.
What Is DMARC (Domain-based Message Authentication, Reporting, and Conformance)?
DMARC ties SPF and DKIM together and adds a policy layer. It tells receiving servers what to do when an email fails SPF and DKIM checks, and it provides reporting so you can monitor who is sending email from your domain.
How DMARC Works
When a receiving server gets an email from your domain, it checks SPF and DKIM. Then it looks at your DMARC record to see:
- Policy: What should the receiving server do if both SPF and DKIM fail? Options are "none" (do nothing, just report), "quarantine" (send to spam), or "reject" (block the email entirely).
- Alignment: DMARC checks that the domain in the "From" header matches the domains used in SPF and DKIM checks. This prevents attackers from passing SPF with one domain while spoofing another in the "From" field.
- Reporting: DMARC can send you daily reports showing which servers sent email using your domain, and whether those emails passed or failed authentication. This helps you identify unauthorized use of your domain.
Setting Up DMARC
DMARC is set up by adding a TXT record to your DNS:
- Go to your domain registrar's DNS management panel.
- Create a new TXT record with host: _dmarc
- For the value, start with a monitoring-only policy: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
- Save the record.
The "p=none" policy means receiving servers will not take action on failed emails, but they will send you reports. This is the right starting point because it lets you verify everything is working correctly before enforcing a stricter policy.
After 2-4 weeks of monitoring (and confirming that your legitimate emails pass SPF and DKIM consistently), upgrade to a quarantine policy:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com
And eventually, for maximum protection, move to reject:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com
Common DMARC mistake: Starting with p=reject before verifying that all legitimate email services pass SPF and DKIM. If you use any third-party services to send email (marketing tools, CRM, cold email platforms), make sure their sending servers are included in your SPF record before enforcing a reject policy. Otherwise, you will block your own legitimate emails.
How to Verify Your Setup
After configuring all three records, you need to verify everything is working correctly. Here are the tools to use:
Online Verification Tools
- MXToolbox (mxtoolbox.com) - Check SPF, DKIM, and DMARC records individually. Use their "Email Health" report for a comprehensive overview.
- Google Admin Toolbox (toolbox.googleapps.com/apps/checkmx/) - Specifically designed for Google Workspace domains. Checks DNS configuration and identifies issues.
- Mail-tester (mail-tester.com) - Send an email to their test address and get a deliverability score with detailed feedback on authentication, content, and blacklist status.
- DMARC Analyzer - Services like DMARCian or Postmark's DMARC tools help you read and interpret the DMARC reports you receive.
Manual Verification
Send a test email from your cold outreach account to a Gmail address you control. Open the email in Gmail, click the three dots menu, and select "Show original." This shows the raw email headers including SPF, DKIM, and DMARC results. You should see "PASS" next to all three.
If any show "FAIL" or "SOFTFAIL," go back and check your DNS records. The most common issues are typos in DNS record values, multiple SPF records instead of one, DKIM not activated in Google Admin, and DNS propagation still in progress.
Common Mistakes Cold Email Senders Make
After helping hundreds of users configure their email infrastructure, these are the mistakes we see most frequently:
- Multiple SPF records. You can only have ONE SPF TXT record per domain. If you need to authorize multiple sending services, include them all in a single record. Two separate SPF records will cause both to fail.
- Forgetting the cold email platform. If you use any tool that sends email on your behalf, that tool's sending servers need to be included in your SPF record. Check your cold email platform's documentation for the correct SPF include.
- Not waiting for DNS propagation. DNS changes can take up to 48 hours to fully propagate. Testing immediately after making changes may show false failures. Wait at least 4 hours before testing, and up to 48 hours if you see inconsistent results.
- Ignoring DMARC reports. The reports DMARC generates are invaluable for catching issues early. Set up a dedicated email address for reports and review them weekly, at least during the first month.
- Setting p=reject too early. As mentioned above, jumping to a reject policy before you have confirmed all legitimate senders pass authentication will block your own emails. Start with p=none, monitor, then gradually tighten.
- Using the wrong domain for outreach. Many senders correctly set up authentication for their main domain but then send cold emails from a separate outreach domain that has no authentication configured. Every domain you send from needs its own SPF, DKIM, and DMARC records.
- Exceeding the SPF lookup limit. SPF has a 10 DNS lookup limit. Each "include" in your SPF record counts as at least one lookup, and nested includes count too. If you exceed 10 lookups, SPF will fail. Use an SPF flattening tool if you need to authorize many services.
How This Relates to Cold Email Tools
When you use a cold email tool like ScrapenSend, the tool sends emails through your own email account (via SMTP or API connection). This means the emails come from your domain, and your SPF, DKIM, and DMARC records are what receiving servers check.
This is actually better for deliverability than tools that send from their own servers on your behalf. When emails come directly from your Google Workspace or Microsoft 365 account, they inherit the trust that email providers place in those platforms. The authentication chain is clean: your domain's SPF authorizes Google's servers, Google's DKIM signs the email, and DMARC verifies the alignment.
ScrapenSend connects to your Gmail or Google Workspace account and sends emails directly through Google's servers. This means:
- Your standard Google SPF record (include:_spf.google.com) covers all emails sent through ScrapenSend.
- DKIM is automatically applied by Google's servers when the email is sent.
- DMARC alignment works naturally because the sending domain matches across SPF, DKIM, and the From header.
You do not need any additional SPF includes or special DNS configurations specifically for ScrapenSend. Just make sure your standard Google Workspace authentication is set up correctly using the steps above.
Checklist: Email Authentication for Cold Outreach
Use this checklist to verify your setup is complete:
- SPF record exists with include:_spf.google.com (for Google Workspace)
- Only one SPF record exists for the domain
- SPF record does not exceed 10 DNS lookups
- DKIM key generated in Google Admin console
- DKIM TXT record added to DNS
- DKIM authentication started (activated) in Google Admin
- DMARC record exists at _dmarc.yourdomain.com
- DMARC policy starts at p=none for monitoring
- DMARC reporting email address is monitored
- Test email sent and all three checks show PASS in email headers
- Mail-tester.com score is 9/10 or higher
- Separate outreach domain (if used) has its own complete authentication setup
Email authentication is one of those tasks that takes 30 minutes to set up but protects every email you send for as long as you use the domain. If you are about to launch cold outreach campaigns, do not skip this step - it is the foundation everything else builds on.
Ready to start sending? Create your free ScrapenSend account, connect your authenticated email account, and launch your first campaign with confidence that your emails will actually reach the inbox.