SPF, DKIM, and DMARC are the three DNS records that prove you actually own the domain you send email from. Since Google and Yahoo's February 2024 sender rules took effect, all three are non-negotiable for any cold outreach domain. This guide gives you the exact DNS records to copy for Google Workspace, Microsoft 365, and your own SMTP, plus the policy escalation path that gets you from "monitor only" to full enforcement without breaking legitimate mail.
Short answer: Add three DNS TXT records to your sending domain. SPF lists the servers allowed to send for you. DKIM signs every outgoing email with a cryptographic key. DMARC tells receiving servers what to do with mail that fails SPF or DKIM, and where to send reports. Set DMARC to p=none first, monitor reports for 2 to 4 weeks, then escalate to p=quarantine and eventually p=reject.
Why email authentication is non-negotiable in 2026
Until 2024, you could get away with a half-configured SPF record and skip DMARC entirely. That window closed when Google and Yahoo introduced their bulk sender requirements: any domain sending more than 5,000 emails per day to their users must have SPF, DKIM, and DMARC configured. Microsoft followed with similar enforcement guidance. The threshold keeps drifting downward in practice. Cold outbound senders hitting Gmail addresses at any volume are being filtered as if they were bulk senders.
The mechanics are simple. When a receiving server gets an email from you, it pulls your domain's DNS records and asks three questions. Did the sending IP appear in your SPF record? Does the DKIM signature on the message verify against your published public key? And if either fails, what does your DMARC policy say should happen?
Get all three right and you start with a clean reputation. Get any one wrong and you start in the spam folder, with no path out until you fix the underlying authentication.
Email authentication is the set of DNS-based standards (SPF, DKIM, DMARC, and increasingly ARC and BIMI) that let receiving mail servers verify the identity of the sender and detect spoofing. Without authentication, anyone can forge mail "from" your domain. With it, receiving servers can reliably distinguish legitimate mail from spoofed mail and apply policy accordingly.
Step 1: SPF record setup
SPF (Sender Policy Framework) is a single TXT record on your root domain listing every server, service, or IP allowed to send email as you. When a receiving server gets a message claiming to come from you@yourdomain.com, it checks the sending IP against this list. If the IP isn't authorized, SPF fails.
You only get one SPF record per domain. Publishing two breaks SPF entirely. If you use multiple services to send mail, combine them into a single record with multiple include: directives.
SPF for Google Workspace
Add this TXT record to the root of your domain (host: @ or your domain name, depending on registrar):
v=spf1 include:_spf.google.com ~allThe ~all at the end is a soft fail. It tells receivers "if you see mail from somewhere not in this list, treat it suspiciously but don't outright reject." For most senders this is the right setting while you stabilize the rest of your authentication.
SPF for Microsoft 365
v=spf1 include:spf.protection.outlook.com ~allIf you send through both Microsoft 365 and a third-party (say, a newsletter tool), chain them:
v=spf1 include:spf.protection.outlook.com include:sendgrid.net ~allSPF for BYO SMTP (your own server or VPS)
If you operate your own SMTP relay with a fixed IP address:
v=spf1 ip4:203.0.113.45 ~allFor an IPv4 range:
v=spf1 ip4:203.0.113.0/24 ~allCombine with other services as needed:
v=spf1 ip4:203.0.113.45 include:_spf.google.com include:mailgun.org ~allThe 10-lookup limit
SPF allows a maximum of 10 DNS lookups when evaluating your record. Every include:, a, mx, ptr, and exists mechanism counts as a lookup. Some include: directives themselves trigger nested lookups (Google's _spf.google.com currently uses 3 of your 10). Exceed 10 and SPF returns a PermError, which most receivers treat as an SPF failure regardless of whether the sending IP is actually authorized.
If you bump up against the limit, use a SPF flattening service that resolves your includes into a static list of IPs, or trim down to only the services you actively use.
Step 2: DKIM record setup
DKIM (DomainKeys Identified Mail) is a cryptographic signature added to the headers of every outbound email. The receiving server fetches your public key from DNS, uses it to verify the signature, and confirms that the message body and key headers haven't been tampered with in transit and actually originated from a server holding your private key.
Unlike SPF, DKIM lives on a subdomain selector. The selector lets you rotate keys without breaking older mail and lets multiple services each publish their own key under the same domain.
DKIM for Google Workspace
- Go to Admin Console > Apps > Google Workspace > Gmail > Authenticate email.
- Select your domain and click Generate new record. Choose 2048-bit key length.
- Google gives you a DNS hostname (typically
google._domainkey) and a long TXT value starting withv=DKIM1; k=rsa; p=.... - Add that TXT record to your DNS exactly as provided.
- Wait 5 to 30 minutes for DNS propagation, then return to the admin console and click Start authentication.
DKIM for Microsoft 365
- Go to Microsoft 365 Defender > Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM.
- Select your domain. Microsoft 365 requires two CNAME records, not TXT records. Add both:
selector1._domainkey.yourdomain.com CNAME selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com
selector2._domainkey.yourdomain.com CNAME selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.comReplace yourtenant with your actual tenant name (visible in the admin portal). Once both CNAMEs resolve, toggle DKIM signing to Enabled in the portal.
Note on Microsoft 365 sending: these DNS records are unaffected by Microsoft's SMTP authentication changes, but how your tool connects to the mailbox is. Basic auth for SMTP AUTH still works today and stays unchanged through December 2026, after which it is disabled by default for existing tenants. If you are setting up M365 for outbound now, connect via OAuth or Microsoft Graph rather than a password. See Microsoft 365 SMTP basic auth: what actually changed.
DKIM for BYO SMTP
If you run your own mail server, generate a 2048-bit RSA key pair using OpenSSL:
openssl genrsa -out private.key 2048
openssl rsa -in private.key -pubout -out public.keyPublish the public key as a TXT record at selector1._domainkey.yourdomain.com:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...your-public-key...IDAQABConfigure your MTA (Postfix with OpenDKIM, Haraka, or similar) to sign outbound mail using the private key. The selector in your signature header (s=selector1) must match the DNS subdomain.
Key length matters: 1024-bit DKIM keys are now treated as weak by most major receivers. Google, Microsoft, and Yahoo recommend 2048-bit minimum. In our experience, upgrading a 1024-bit key to 2048-bit on a previously throttled domain produces a measurable lift in inbox placement within 7 to 14 days, simply because the message no longer trips the "weak crypto" signal on receiving filters.
Step 3: DMARC record setup
DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer that sits on top of SPF and DKIM. It tells receiving servers what to do when a message claiming to be from your domain fails authentication, and where to send aggregate reports so you can see what's happening.
DMARC lives at _dmarc.yourdomain.com as a single TXT record. Start permissive, monitor reports, then escalate.
Stage 1: Monitor only (weeks 1 to 4)
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r; pct=100Breakdown:
v=DMARC1- version identifier, always this exact string.p=none- policy. "None" means observe and report, take no enforcement action. Always start here.rua=mailto:- aggregate report inbox. You'll get daily XML reports from every receiver that processed mail from your domain.ruf=mailto:- forensic report inbox for individual failure samples (some receivers send these, many don't).fo=1- send forensic reports when either SPF or DKIM fails.adkim=randaspf=r- relaxed alignment for DKIM and SPF. Usesfor strict alignment only after monitoring confirms it won't break anything.pct=100- apply policy to 100% of mail. While you're atp=nonethis doesn't matter; it becomes critical when you escalate.
Stage 2: Quarantine (weeks 4 to 8)
After 2 to 4 weeks of clean DMARC reports (no legitimate services failing alignment), escalate:
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=25Start with pct=25 to apply quarantine policy to only 25% of failing mail. Watch reports for a week. If nothing legitimate is being affected, raise to pct=50, then pct=100.
Stage 3: Reject (weeks 8+)
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; pct=100This is the destination state. Any mail claiming to be from your domain that fails both SPF and DKIM alignment will be rejected outright by compliant receivers. Required for Google and Yahoo bulk sender compliance.
Use p=none when: you just added DMARC, you're auditing what services send on your behalf, or you've just changed your SPF/DKIM and want to confirm no regressions before enforcing.
Use p=quarantine when: reports show only legitimate mail aligning, but you want a safety net during the transition to full enforcement.
Use p=reject when: you've validated 2+ weeks at p=quarantine with 100% pct, and you want maximum protection against spoofing of your domain.
Reading DMARC reports without losing your mind
The raw XML aggregate reports are unreadable by humans. Use a DMARC reporting service (Dmarcian, EasyDMARC, Postmark's free analyzer, or Valimail Monitor) that ingests the reports and shows you a dashboard of which services are sending on your behalf, which are aligning, and which are failing. You'll discover marketing tools, transactional senders, and forgotten contractors that have been sending as you for years.
Subdomain and sending account strategy
Cold outreach should never go through your primary domain. If you book demos at yourcompany.com, you do not send cold mail from yourcompany.com. The reputation risk is too asymmetric. One bad campaign and your CEO can't email a customer.
The standard pattern: register 2 to 4 secondary domains for outreach. For each, configure SPF, DKIM, and DMARC from day one before sending a single message. Common secondary domain patterns are get-yourcompany.com, yourcompany-team.com, and tryyourcompany.com. Then create 2 sending mailboxes per domain - that is the ceiling on the standard provider model, where each mailbox sends up to 30 cold emails per day. (Bulk-provisioned Microsoft 365 tenants invert this: up to 50 mailboxes on a single domain, but only 5 sends per mailbox per day, and one domain per tenant.)
Each secondary domain gets its own complete authentication stack. SPF authorizing the email provider, DKIM with a 2048-bit key, and DMARC starting at p=none for at least the first month while you warm up the inboxes.
How ACA validates authentication before you send
One of the most expensive mistakes in cold outreach is launching a campaign from a freshly-connected mailbox with broken authentication. You burn through your warm-up runway, your reputation, and your domain at the same time. By the time you notice the bounce rate climbing, the damage is done.
When you connect a sending mailbox to ACA, the platform runs a pre-flight authentication check on the sending domain before any campaign goes live. It pulls the SPF, DKIM, and DMARC records, verifies that SPF authorizes the actual sending provider for that mailbox, confirms DKIM is signing with a 2048-bit or stronger key, and checks that DMARC is published with a valid syntax. If any record is missing or misconfigured, the mailbox is flagged and the campaign launch is blocked until you fix it.
The check runs continuously, not just on connect. If you change DNS, rotate a DKIM key, or your DMARC policy drifts, ACA surfaces the change in the inbox health view so you catch it before reply rates start dropping. The same validation runs across every mailbox in a multi-inbox sending rotation, so a broken record on one of eight mailboxes doesn't quietly drag down the whole campaign.
Common mistakes that silently break authentication
- Two SPF records. Publishing a second SPF TXT (for example, when you add a new sender) invalidates SPF entirely. Always merge into one record.
- Wildcard or duplicate DMARC. Only one DMARC record at
_dmarc.yourdomain.com. Some registrars auto-create one; check before you add your own. - SPF flattened wrong. Hardcoding a provider's current IPs into your SPF record breaks the moment they add new IPs. Use
include:for managed providers. - DKIM selector mismatch. The selector in your signature header (
s=) must exactly match the DNS subdomain. Off-by-one typos here cause silent DKIM failures. - DMARC alignment failures hidden by SPF pass. SPF can pass while DMARC fails if the visible "From" header domain doesn't match the SPF-verified envelope sender. Check alignment, not just authentication.
- Setting
p=rejecttoo fast. Going from no DMARC top=rejectin week one will almost always block legitimate transactional or marketing mail from a forgotten subprocessor. Stage throughnoneandquarantine.
Verification tools you should actually use
- mail-tester.com - send a test email, get a 0-to-10 score covering SPF, DKIM, DMARC, content, and blacklists. Free, fast, no signup.
- MXToolbox SuperTool - check SPF syntax, DKIM lookup, DMARC lookup, blacklist status. Free tier covers everything you need for setup.
- Google Postmaster Tools - if you send any meaningful volume to Gmail, this is the source of truth for your domain reputation, authentication pass rates, and spam complaint rates.
- Microsoft SNDS / JMRP - the equivalent for Outlook and Hotmail addresses. Sign up if you send to Microsoft inboxes at volume.
- Dmarcian or EasyDMARC - human-readable DMARC report dashboards. Free tiers handle low-volume domains.
Frequently asked questions
How long does SPF, DKIM, and DMARC take to propagate?
DNS propagation for TXT records is typically 15 minutes to 4 hours, depending on your TTL setting and registrar. Most modern DNS providers (Cloudflare, Route 53, Google Domains) propagate globally within 5 minutes. Test using dig TXT yourdomain.com from the command line or MXToolbox SuperTool. Don't trust your registrar's UI to confirm propagation, query the public DNS directly.
Do I need DMARC if I already have SPF and DKIM?
Yes. Without DMARC, receiving servers have no instructions for what to do when SPF or DKIM fails, and Google and Yahoo's 2024 sender requirements explicitly require DMARC for bulk senders. Even at p=none, having DMARC published signals to receivers that you care about authentication and gives you the aggregate reports needed to spot problems.
Can I have SPF, DKIM, and DMARC on a subdomain only?
Yes, and this is the recommended pattern for cold outreach. If your primary domain is yourcompany.com, you can publish a complete authentication stack on a secondary domain like get-yourcompany.com and send all outreach from there. Your primary domain stays clean, and any reputation damage from outreach is isolated to the secondary.
What's the difference between SPF soft fail (~all) and hard fail (-all)?
Soft fail tells receivers "if this IP isn't on my list, treat the mail with suspicion but you can still deliver it." Hard fail says "if this IP isn't on my list, reject the mail." Start with ~all while you're confirming all your sending sources are listed. Move to -all only after DMARC is at p=reject and you've validated alignment for 30+ days.
Does DKIM signing slow down email delivery?
No, in any measurable sense. Signing adds a few milliseconds per message on the sending side. Receiving servers verify the signature against your published public key in DNS, which they cache aggressively. The throughput impact on modern MTAs is negligible compared to the deliverability benefit.
What happens if my DKIM private key leaks?
Rotate immediately. Generate a new key pair with a new selector (for example, selector2._domainkey), publish the new public key in DNS, reconfigure your MTA to sign with the new private key, then remove the old public key from DNS after 7 days. Until you rotate, anyone with the leaked key can forge signed mail from your domain that passes DKIM verification.
Can ACA set up SPF, DKIM, and DMARC for me?
ACA validates your authentication records and flags problems, but the DNS records themselves have to live on your domain at your registrar. You publish the records, ACA confirms they're correct and continues monitoring them. This separation is intentional, the records belong to your domain and your business, not to any single sending platform you might use.