SPF, DKIM, and DMARC are the three DNS records that prove your emails are legitimate. Together, they answer three questions every receiving server asks: who is allowed to send for this domain, was the message tampered with in transit, and what should we do if either check fails?
Since February 2024, Google and Yahoo require all three for any sender pushing more than a few hundred messages per day from one mailbox. In cold email you'll rarely send more than 20-30 a day from a single account anyway, so the volume threshold itself isn't the point. The point is that the rules are tightening across the board: a clean technical setup is no longer "nice to have", it's a MUST. Without SPF, DKIM, and DMARC your campaigns will land in spam, or be rejected outright.
The good news: setup is a one-time task per domain, and most of the work depends on which Email Service Provider (ESP) you use. SPF and DKIM are configured per provider. DMARC is configured once, regardless of provider.
This guide walks through both halves.
SPF publishes the list of mail servers authorized to send on behalf of your domain. Receivers check the sending IP against this list.
DKIM attaches a cryptographic signature to every outgoing email. Receivers verify the signature against a public key in your DNS, proving the message came from you and was not modified.
DMARC tells receivers what to do when SPF or DKIM fails (allow, quarantine, or reject) and where to send authentication reports.
SPF and DKIM are the proof. DMARC is the policy that turns that proof into action.
Each ESP has its own settings for SPF and DKIM. The general flow is the same everywhere: generate keys in the ESP's admin panel, then publish DNS records on your domain. Specific values differ. Pick your provider below.
Official docs: Authorize email senders with SPF and Turn on DKIM for your domain (Google Workspace Admin Help).
SPF. Add a TXT record on your root domain.
Host / Name: @ (root)
Type: TXT
Value: v=spf1 include:_spf.google.com ~all
DKIM.
Go to Google Admin Console.
Navigate to Apps > Google Workspace > Gmail > Authenticate Email.
Select your domain and click Generate New Record. Choose 2048-bit key length.
Copy the TXT record value Google provides.
Add a TXT record to your DNS:
Host / Name: google._domainkey
Value: the TXT value from Google
Return to Google Admin Console and click Start Authentication.
Important: The DNS record alone is not enough. You must click Start Authentication in Google Admin or Google will not sign your outgoing mail.
Official docs: Set up SPF for Microsoft 365 and Use DKIM for email in your custom domain (Microsoft Learn).
SPF. Add a TXT record on your root domain.
Host / Name: @ (root)
Type: TXT
Value: v=spf1 include:spf.protection.outlook.com -all (Microsoft recommends -all over ~all once DKIM and DMARC are in place)
DKIM.
Go to the Microsoft Defender portal.
Navigate to Email & collaboration > Policies & rules > Threat policies > Email Authentication Settings > DKIM.
Select your domain and click Create DKIM keys.
Microsoft gives you two CNAME records, add both to your DNS:
selector1._domainkey.yourdomain.com -> selector1-yourdomain-com._domainkey.<initial>.<x>-v1.dkim.mail.microsoft
selector2._domainkey.yourdomain.com -> selector2-yourdomain-com._domainkey.<initial>.<x>-v1.dkim.mail.microsoft
The exact target values are shown in the Publish CNAMEs flyout. As of May 2025, new tenants get the updated <x>-v1.dkim.mail.microsoft format with a dynamic partition character. Older tenants still use the legacy <initial>.onmicrosoft.com format. Always copy the values shown in the portal, not from a template.
After DNS propagation, return to Microsoft Defender and toggle Enable for DKIM.
The pattern is the same for every ESP. Common ones, with links to their official setup docs:
Provider | SPF Include | Official DKIM/SPF Docs |
|---|---|---|
Zoho Mail |
| |
Namecheap Private Email |
| |
GoDaddy Email |
| |
SendGrid |
| |
Mailgun |
| |
Amazon SES |
|
The flow:
Find your ESP's SPF include value and add a TXT record on your root domain.
Generate a DKIM key in your ESP's admin panel, then publish the CNAME or TXT record they provide.
Enable DKIM signing in the ESP's settings. This is a separate step from publishing the DNS record. Most providers require explicit activation.
If you send through multiple providers from the same domain, combine all SPF includes into a single record:
v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~allCritical: Only one SPF record per domain. Two v=spf1 TXT records will break authentication entirely. Combine includes, never duplicate.
Official docs: Set up DMARC for Google Workspace and Set up DMARC for Microsoft 365. The protocol itself is defined in RFC 7489.
Unlike SPF and DKIM, DMARC is identical regardless of your ESP. It is a single TXT record, published once.
Go to your DNS provider.
Add a new TXT record:
Host / Name: _dmarc (some registrars require _dmarc.yourdomain.com)
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:[email protected];
Save and wait for propagation (15 to 60 minutes typically).
Replace [email protected] with an inbox where you actually want to receive aggregate reports. If you don't want reports, drop the rua parameter:
v=DMARC1; p=none;That's it. There is no provider-specific step. DMARC is a policy declaration, not a signing mechanism.
Tip: Free DMARC report parsers like dmarcian or Postmark's DMARC Digests turn the raw XML reports into a readable dashboard. Recommended once you start collecting rua data.
The p= parameter controls what receivers do when an email fails SPF or DKIM:
Policy | What It Does |
|---|---|
| Monitor only. Collect reports, no impact on delivery. |
| Failing emails go to spam. |
| Failing emails are dropped at the gateway. |
Always start with p=none. Monitor reports for 2 to 4 weeks to confirm no legitimate sending source is failing authentication. Only then move to p=quarantine, and eventually p=reject for maximum protection. For cold outreach, p=none is enough to satisfy Google and Yahoo's bulk sender requirements. You don't need to escalate to p=reject to get good deliverability. What matters is that the record exists and SPF/DKIM are passing.
DKIM records live at <selector>._domainkey.yourdomain.com. The selector identifies which key to use, since one domain can carry multiple DKIM keys (one per ESP).
MailBeast automatically scans for DKIM records using these 8 common selectors:
default, mail, dkim, selector1, selector2, k1, google, email
If your DKIM uses one of these, MailBeast finds and verifies it automatically. Multiple selectors on the same domain are fine. MailBeast accepts the first one it finds.
Two SPF records. There must be exactly one TXT record starting with v=spf1. If you have two, delete the old one and merge all includes into one record.
+all at the end of SPF. This authorizes every server in the world to send as your domain and completely defeats SPF. Always use ~all (softfail) or -all (hardfail).
Exceeding the 10 DNS lookup limit. Each include: chains into more lookups. If the total exceeds 10, the SPF record fails with permerror. See Microsoft's troubleshooting notes for the gory detail and Kitterman's free SPF checker to count yours.
Forgetting to enable DKIM in the ESP. Adding the DNS record is half the work. Google requires Start Authentication, Microsoft requires the Enable toggle. Without that step, your mail is not signed.
DMARC before SPF and DKIM. DMARC enforces policy on top of SPF/DKIM. If neither is configured, DMARC has nothing to enforce. Set up SPF and DKIM first.
Jumping to p=reject. Without monitoring p=none reports first, a strict policy will silently block legitimate mail from forgotten sending sources (transactional services, forwarders, third-party tools).
Cloudflare proxy on DKIM CNAME. Set the DKIM CNAME to DNS Only (grey cloud). Orange-cloud proxying intercepts the lookup and breaks verification. See Cloudflare's DNS record proxy docs.
Wrong host for DMARC. The record goes on _dmarc (with underscore), not dmarc. Most registrars auto-append the domain.
Multiple DMARC records. Like SPF, only one DMARC record per domain.
After publishing all three records:
Open the email account in MailBeast.
Go to the Overview tab in the account detail sheet.
MailBeast verifies SPF, DKIM, and DMARC automatically, both at connection time and on a regular schedule.
Each record shows a green Verified badge once the lookup succeeds.
DNS changes typically propagate in 15 to 60 minutes, but in rare cases can take up to 48 hours. If a record stays unverified, double-check the host name and value against your ESP's instructions. External validators are useful for a quick sanity check:
MXToolbox SuperTool - SPF, DKIM, DMARC, MX in one place
Google Admin Toolbox - Check MX - Google's own validator
Microsoft shared domains (outlook.com, hotmail.com, live.com): Microsoft manages SPF for these, you cannot modify it. MailBeast treats SPF softfail as verified for shared Microsoft domains.
Google OAuth accounts: MailBeast also treats SPF softfail as verified, since Google's outbound infrastructure may use IPs that aren't directly listed in your domain's SPF record.
Understanding Your DNS Health Score - see how SPF, DKIM, and DMARC contribute to your account's health score.
Cloudflare DNS Setup - if your DNS is on Cloudflare, the orange-cloud / grey-cloud distinction matters for DKIM and tracking domain CNAMEs. For other registrars (GoDaddy, Namecheap, Squarespace, cPanel, Route 53, etc.) the actual values you publish are identical - use your registrar's own DNS docs to find the "Add TXT/CNAME record" UI, then paste the values from the relevant section above.
Custom Tracking Domain Setup - improve deliverability further with a branded tracking domain.