SPF, DKIM, DMARC Explained: The Technical Email Authentication Guide

SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting, and Conformance) are three email authentication protocols that work together to verify that an email was sent by an authorized sender and hasn't been tampered with in transit. Together, they form the foundation of email deliverability - without properly configured SPF, DKIM, and DMARC, your emails are significantly more likely to be filtered as spam or rejected entirely by receiving mail servers.

These three protocols solve a fundamental problem with email: the SMTP protocol (which powers all email) was designed in the 1980s with no built-in authentication. Anyone can send an email claiming to be from any address. SPF verifies the sending server, DKIM verifies the message integrity, and DMARC ties them together with policy enforcement. Understanding how they work isn't optional for anyone running cold email at scale - it's the difference between landing in the inbox and landing in spam.

How Email Authentication Works: The Big Picture

Before diving into each protocol, let's understand how they work together when you send an email.

The Email Authentication Flow

Here's what happens when you send an email from jeff@getcompany.com to sarah@prospect.com:

Step 1: You hit send. Your email client (Gmail, Outlook) hands the email to your mail server (e.g., Google Workspace's SMTP server at smtp.gmail.com).

Step 2: Your mail server adds DKIM signature. Before sending, your server creates a cryptographic hash of the email body and headers, encrypts it with your private DKIM key, and adds the encrypted hash as a header to the email.

Step 3: Email travels to the recipient's mail server. The email routes through the internet via SMTP to the recipient's mail server (e.g., prospect.com's server).

Step 4: Recipient's server checks SPF. The receiving server looks at the "envelope from" address (the server that sent the email), then queries your domain's DNS for the SPF record. It checks: "Is the sending server's IP address listed as an authorized sender for getcompany.com?" Result: SPF Pass or SPF Fail.

Step 5: Recipient's server checks DKIM. The receiving server reads the DKIM signature header from the email, fetches your public DKIM key from DNS, decrypts the hash, and compares it to its own hash of the email body. If they match, the email hasn't been modified. Result: DKIM Pass or DKIM Fail.

Step 6: Recipient's server checks DMARC. The receiving server fetches your DMARC record from DNS. DMARC checks two things: (a) did either SPF or DKIM pass? and (b) does the "From" domain in the email header align with the domain that passed SPF or DKIM? Based on your DMARC policy (none, quarantine, or reject), the server decides what to do with the email.

Step 7: Delivery decision. Based on the combined results of SPF, DKIM, and DMARC, plus other signals (sender reputation, content analysis, recipient behavior), the receiving server delivers the email to the inbox, spam folder, or rejects it entirely.

Authentication Results Summary

Scenario: Everything configured correctly | SPF: Pass | DKIM: Pass | DMARC: Pass | Likely Outcome: Inbox

Scenario: SPF fails, DKIM passes | SPF: Fail | DKIM: Pass | DMARC: Pass (if DKIM aligned) | Likely Outcome: Inbox (usually)

Scenario: SPF passes, DKIM fails | SPF: Pass | DKIM: Fail | DMARC: Pass (if SPF aligned) | Likely Outcome: Inbox (usually)

Scenario: Both fail | SPF: Fail | DKIM: Fail | DMARC: Fail | Likely Outcome: Spam or Rejected

Scenario: No DMARC record | SPF: Pass/Fail | DKIM: Pass/Fail | DMARC: N/A | Likely Outcome: Depends on provider

Scenario: DMARC reject policy, both fail | SPF: Fail | DKIM: Fail | DMARC: Fail + Reject | Likely Outcome: Rejected (bounced)

SPF: Sender Policy Framework

What SPF Does

SPF tells the world which mail servers are allowed to send email on behalf of your domain. It's a DNS TXT record that lists every IP address or service authorized to send from your domain.

Think of it like a guest list at a building's front desk. The SPF record is the list. When an email arrives claiming to be from your domain, the receiving server checks the list: "Is this sending server on the approved list?" If yes, SPF passes. If no, SPF fails.

SPF Record Anatomy

An SPF record is a TXT record set on your domain's DNS. Here's a typical example:

`` v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:192.168.1.1 ~all ``

Let's break down each part:

Component: v=spf1 | Meaning: Declares this is an SPF record (version 1). Required.

Component: include:_spf.google.com | Meaning: Authorizes all Google Workspace mail servers

Component: include:servers.mcsv.net | Meaning: Authorizes Mailchimp's servers

Component: ip4:192.168.1.1 | Meaning: Authorizes a specific IP address

Component: ~all | Meaning: Soft fail: treat emails from unauthorized servers as suspicious (but don't reject)

SPF Mechanisms

Mechanism: include: | What It Does: Includes another domain's SPF record | Example: include:_spf.google.com

Mechanism: ip4: | What It Does: Authorizes a specific IPv4 address or range | Example: ip4:203.0.113.0/24

Mechanism: ip6: | What It Does: Authorizes a specific IPv6 address or range | Example: ip6:2001:db8::/32

Mechanism: a | What It Does: Authorizes the IP that your domain's A record points to | Example: a

Mechanism: mx | What It Does: Authorizes the IPs that your domain's MX records point to | Example: mx

Mechanism: redirect= | What It Does: Redirects SPF checking to another domain | Example: redirect=otherdomain.com

SPF Qualifiers (The "all" Tag)

The all mechanism at the end of your SPF record defines what happens to emails from servers NOT in your list:

Qualifier: Pass | Syntax: +all | Meaning: Allow all servers (defeats the purpose) | Recommendation: Never use

Qualifier: Soft Fail | Syntax: ~all | Meaning: Accept but mark as suspicious | Recommendation: Use during setup

Qualifier: Hard Fail | Syntax: -all | Meaning: Reject emails from unauthorized servers | Recommendation: Use in production

Qualifier: Neutral | Syntax: ?all | Meaning: No opinion either way | Recommendation: Avoid

Our recommendation: Start with ~all (soft fail) during initial setup. Move to -all (hard fail) once you've confirmed all legitimate sending sources are included.

How to Set Up SPF

Step 1: Identify every service that sends email from your domain:

• Your email provider (Google Workspace, Microsoft 365)
• Marketing email (Mailchimp, HubSpot, SendGrid)
• Transactional email (SendGrid, Postmark, Amazon SES)
• Cold email (if sending from this domain directly)
• Any other service (helpdesk, notification systems)

Step 2: Look up the SPF include for each service:

• Google Workspace: include:_spf.google.com
• Microsoft 365: include:spf.protection.outlook.com
• Mailchimp: include:servers.mcsv.net
• HubSpot: include:email.hubspot.com
• SendGrid: include:sendgrid.net
• Amazon SES: include:amazonses.com

Step 3: Combine them into one SPF record: `` v=spf1 include:_spf.google.com include:sendgrid.net include:email.hubspot.com -all ``

Step 4: Add this as a TXT record on your domain at the root (@) level.

Step 5: Verify using MXToolbox SPF lookup or dig TXT yourdomain.com.

Common SPF Mistakes

Multiple SPF records: You can only have ONE SPF record per domain. If you add a second one, both fail. Combine all includes into a single record.

Exceeding the 10-lookup limit: SPF allows a maximum of 10 DNS lookups. Each include: counts as one lookup, and the included domain's record might include additional includes. Use an SPF flattening tool (like AutoSPF or SPF Toolbox) if you hit this limit.

Forgetting a sending source: If any legitimate service isn't in your SPF record, emails from that service will fail SPF. Audit all sending sources before configuring.

Using `+all`: This authorizes every server in the world to send email from your domain. It's the same as having no SPF record. Never use it.

DKIM: DomainKeys Identified Mail

What DKIM Does

DKIM adds a digital signature to every email you send, proving two things: (1) the email was authorized by the domain owner, and (2) the email content wasn't modified in transit.

Think of it like a wax seal on a letter. The seal proves who sent it, and if the seal is broken, you know someone tampered with the letter. DKIM is the digital equivalent - a cryptographic signature that verifies authenticity and integrity.

How DKIM Works Technically

DKIM uses public-key cryptography (the same type used in HTTPS):

Signing (your server):

1. When you send an email, your server selects specific headers and the email body
2. It creates a hash (a mathematical fingerprint) of those components
3. It encrypts the hash using your domain's private DKIM key (stored on your server)
4. It adds the encrypted hash as a DKIM-Signature header to the email

Verification (receiving server):

1. The receiving server reads the DKIM-Signature header
2. It extracts the selector and domain from the header
3. It fetches the public DKIM key from your DNS: selector._domainkey.yourdomain.com
4. It decrypts the hash using the public key
5. It creates its own hash of the email headers and body
6. If the decrypted hash matches the independently calculated hash: DKIM passes
7. If they don't match (email was modified in transit): DKIM fails

DKIM Record Anatomy

A DKIM record is a TXT record set at a specific subdomain of your domain. Here's an example:

DNS location: google._domainkey.yourdomain.com

Record value: `` v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ... ``

Component: v=DKIM1 | Meaning: DKIM version 1

Component: k=rsa | Meaning: Key type (RSA is standard)

Component: p=MIGf... | Meaning: The public key (base64 encoded)

The selector (e.g., "google") is an identifier that tells receiving servers which DKIM key to look up. Different sending services use different selectors, so you can have multiple DKIM keys per domain.

How to Set Up DKIM

For Google Workspace:

1. Go to Google Admin Console > Apps > Google Workspace > Gmail > Authenticate email
2. Click "Generate New Record"
3. Select your domain and DKIM key bit length (2048-bit recommended)
4. Copy the generated TXT record
5. Add it to your DNS at the specified subdomain (e.g., google._domainkey.yourdomain.com)
6. Wait 24-48 hours for DNS propagation
7. Return to Google Admin and click "Start Authentication"

For Microsoft 365:

1. Go to Microsoft 365 Defender > Email & Collaboration > Policies > Threat Policies > Email Authentication
2. Select your domain
3. Copy the two CNAME records provided
4. Add them to your DNS
5. Return to Microsoft and enable DKIM signing

For third-party sending services (SendGrid, Mailchimp, HubSpot):

• Each service provides their own DKIM setup instructions
• Typically involves adding a CNAME or TXT record to your DNS
• The service handles the signing; you just need to publish the public key

How to Verify DKIM

Method 1: Send a test email to mail-tester.com

• It will show whether DKIM is passing and display the signature details

Method 2: Check email headers

• Send an email to a Gmail account
• Open the email > Click the three dots > "Show original"
• Look for dkim=pass in the Authentication-Results header

Method 3: DNS lookup

• Use MXToolbox DKIM lookup
• Enter your domain and selector (e.g., "google" for Google Workspace)
• It should return your public key

Common DKIM Mistakes

Not enabling DKIM at all: Many email providers don't enable DKIM by default. You have to manually generate the key, add the DNS record, and activate signing.

Wrong DNS record type: DKIM records should be TXT records. Some DNS providers have a specific "DKIM" record type - use TXT unless your provider specifically requires otherwise.

Key rotation neglect: DKIM keys should be rotated annually for security. Most providers handle this automatically, but if you're managing keys manually, set a calendar reminder.

DNS propagation delays: After adding the DKIM DNS record, wait 24-48 hours before activating DKIM signing in your email provider. If you activate before the record propagates, emails will fail DKIM validation.

DMARC: Domain-based Message Authentication, Reporting, and Conformance

What DMARC Does

DMARC is the policy layer that ties SPF and DKIM together. It does three things:

1. Alignment check: Verifies that the domain in the "From" header matches the domain that passed SPF or DKIM. This prevents attackers from passing SPF with their own domain while spoofing yours in the From header.
2. Policy enforcement: Tells receiving servers what to do when authentication fails - nothing (none), quarantine (spam folder), or reject (bounce the email).
3. Reporting: Sends you daily reports about authentication results for your domain, so you can see who's sending email as you (legitimate services and attackers).

DMARC Alignment Explained

Alignment is the key concept that makes DMARC more powerful than SPF and DKIM alone.

Without DMARC: An attacker could set up their own server, configure SPF and DKIM for their own domain (attacker.com), but send emails with a "From" header of jeff@yourcompany.com. SPF passes (for attacker.com), DKIM passes (for attacker.com), but the recipient sees the email as from yourcompany.com. The protocols pass, but the spoofing succeeds.

With DMARC: The receiving server checks alignment - does the domain that passed SPF or DKIM match the domain in the "From" header? If the email claims to be from yourcompany.com but SPF/DKIM passed for attacker.com, alignment fails, and DMARC fails. The spoofed email gets quarantined or rejected.

Alignment modes:

• Strict alignment: The domains must match exactly. From: jeff@yourcompany.com must match SPF/DKIM for yourcompany.com exactly.
• Relaxed alignment: The organizational domain must match. From: jeff@mail.yourcompany.com can align with SPF/DKIM for yourcompany.com (subdomains are OK). This is the default and recommended mode.

DMARC Record Anatomy

A DMARC record is a TXT record set at _dmarc.yourdomain.com. Here's a full example:

`` v=DMARC1; p=quarantine; sp=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; adkim=r; aspf=r; pct=100; ri=86400 ``

Tag: v=DMARC1 | Required: Yes | Meaning: DMARC version | Values: Always DMARC1

Tag: p= | Required: Yes | Meaning: Policy for your domain | Values: none / quarantine / reject

Tag: sp= | Required: No | Meaning: Policy for subdomains | Values: none / quarantine / reject (defaults to p= value)

Tag: rua= | Required: Recommended | Meaning: Where to send aggregate reports | Values: mailto: address

Tag: ruf= | Required: Optional | Meaning: Where to send forensic (failure) reports | Values: mailto: address

Tag: adkim= | Required: No | Meaning: DKIM alignment mode | Values: r (relaxed) / s (strict)

Tag: aspf= | Required: No | Meaning: SPF alignment mode | Values: r (relaxed) / s (strict)

Tag: pct= | Required: No | Meaning: Percentage of messages to apply policy to | Values: 0-100 (default 100)

Tag: ri= | Required: No | Meaning: Reporting interval in seconds | Values: Default 86400 (24 hours)

DMARC Policy Options

Policy: None | Tag: p=none | What Happens: Nothing - just monitor and report | When to Use: Initial setup (learning phase)

Policy: Quarantine | Tag: p=quarantine | What Happens: Failed emails go to spam folder | When to Use: After verifying all legitimate sources pass

Policy: Reject | Tag: p=reject | What Happens: Failed emails are bounced (not delivered) | When to Use: Maximum protection, fully verified setup

How to Set Up DMARC

Step 1: Start with monitoring (p=none)

Add this TXT record at _dmarc.yourdomain.com: `` v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com ``

This doesn't affect email delivery - it just starts collecting reports about who is sending email from your domain and whether they pass authentication.

Step 2: Analyze reports for 2-4 weeks

DMARC reports are XML files that arrive daily. They're dense and difficult to read manually. Use a DMARC report analyzer:

• Free: DMARC Analyzer (free tier), Postmark DMARC tool
• Paid: Valimail, dmarcian, EasyDMARC

In the reports, look for:

• Which services are sending email from your domain (legitimate and unauthorized)
• Which legitimate services are failing SPF or DKIM (fix these before changing policy)
• Any unauthorized senders (these will be blocked when you enforce policy)

Step 3: Fix any failing legitimate sources

If your reports show that HubSpot is sending emails from your domain but failing DKIM, set up DKIM for HubSpot before moving to quarantine. If a legacy system is sending from your domain without SPF authorization, add it to your SPF record.

Step 4: Move to quarantine gradually

Update your DMARC record: `` v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com ``

The pct=25 means only 25% of failing emails get quarantined. Monitor for 1-2 weeks. If no legitimate emails are being quarantined, increase to pct=50, then pct=100.

Step 5: Move to reject (optional)

For maximum security: `` v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com ``

This tells receiving servers to reject (bounce) any email that fails DMARC. Only move to reject when you're 100% confident all legitimate sending sources pass authentication.

Common DMARC Mistakes

Jumping straight to p=reject: If any legitimate service fails authentication, those emails will be bounced. Always start with p=none, analyze reports, fix issues, then gradually enforce.

Not monitoring reports: Setting p=none and ignoring the reports defeats the purpose. The reports tell you what's happening with your domain's email authentication.

Forgetting subdomains: DMARC policy applies to your root domain by default. If you also send email from subdomains (mail.yourdomain.com, news.yourdomain.com), consider the sp= tag to set a separate subdomain policy.

Not setting up RUA (reporting): Without the rua= tag, you won't receive any reports. You're flying blind.

Protocol Comparison Table

Feature: What it verifies | SPF: Sending server is authorized | DKIM: Email content hasn't been modified | DMARC: Policy enforcement + alignment

Feature: DNS record type | SPF: TXT at root (@) | DKIM: TXT at selector._domainkey.domain | DMARC: TXT at _dmarc.domain

Feature: Works independently | SPF: Yes | DKIM: Yes | DMARC: No (requires SPF and/or DKIM)

Feature: Survives email forwarding | SPF: No (forwarding changes sending IP) | DKIM: Yes (signature stays with the email) | DMARC: Depends on which protocol passes

Feature: Prevents spoofing | SPF: Partially (server-level only) | DKIM: Partially (content-level only) | DMARC: Yes (combines both with alignment)

Feature: Provides reporting | SPF: No | DKIM: No | DMARC: Yes (aggregate and forensic reports)

Feature: Complexity | SPF: Low | DKIM: Medium | DMARC: Medium-High

Feature: Time to implement | SPF: 15 minutes | DKIM: 30-60 minutes | DMARC: Ongoing (start monitoring, gradually enforce)

DNS Record Quick Reference

Here's every DNS record you need for complete email authentication on a domain:

Record Type: TXT | Host/Name: @ | Value: v=spf1 include:_spf.google.com -all | Purpose: SPF - authorized senders

Record Type: TXT | Host/Name: google._domainkey | Value: v=DKIM1; k=rsa; p=MIGf... | Purpose: DKIM - public signing key

Record Type: TXT | Host/Name: _dmarc | Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@domain.com | Purpose: DMARC - policy and reporting

Record Type: MX | Host/Name: @ | Value: Priority 1: aspmx.l.google.com (etc.) | Purpose: Mail server for receiving

Record Type: CNAME | Host/Name: track | Value: points to tracking server | Purpose: Custom tracking domain (for email tools)

Verification Checklist

After setting up all three protocols, verify everything is working:

SPF Verification

1. Run: MXToolbox SPF Lookup for your domain
2. Confirm: Only one SPF record exists
3. Confirm: All legitimate sending services are included
4. Confirm: Record ends with -all or ~all
5. Confirm: Total DNS lookups are 10 or fewer
6. Test: Send an email to mail-tester.com and check SPF result

DKIM Verification

1. Run: MXToolbox DKIM Lookup with your selector
2. Confirm: Public key is published and valid
3. Test: Send an email and check headers for dkim=pass
4. Test: Send to mail-tester.com and verify DKIM passes
5. Confirm: Each sending service has its own DKIM key configured

DMARC Verification

1. Run: MXToolbox DMARC Lookup for your domain
2. Confirm: Record exists at _dmarc.yourdomain.com
3. Confirm: rua= tag is set to receive reports
4. Confirm: Policy matches your intended level (none/quarantine/reject)
5. Verify: Reports are being received and analyzed (check after 24-48 hours)

End-to-End Test

1. Send an email from each sending service to mail-tester.com
2. Score should be 9/10 or higher
3. SPF, DKIM, and DMARC should all show "Pass"
4. Send to a Gmail account and check "Show original" for authentication results
5. Send to an Outlook account and check headers for authentication results

SPF, DKIM, DMARC for Cold Email

For cold email specifically, here are additional considerations:

Dedicated Sending Domains

Each of your cold email sending domains needs its own complete set of authentication records:

• getcompany.com: SPF + DKIM + DMARC
• trycompany.com: SPF + DKIM + DMARC
• companyapp.com: SPF + DKIM + DMARC

Don't share authentication between your primary domain and sending domains. Each domain is independent.

Cold Email Provider SPF Includes

If you're using Google Workspace mailboxes for cold email (common with Instantly/Smartlead): `` v=spf1 include:_spf.google.com -all ``

If using Microsoft 365: `` v=spf1 include:spf.protection.outlook.com -all ``

If using a dedicated sending service: `` v=spf1 include:_spf.google.com include:sendgrid.net -all ``

DMARC for New Sending Domains

For cold email sending domains, we recommend:

Week 1-2 (warmup phase): `` v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com ``

Week 3+ (sending phase): `` v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com ``

Moving to p=quarantine relatively quickly on sending domains is fine because you control all sending from these domains (they're purpose-built for cold email, not used by multiple services).

Monitoring Multiple Domains

When managing 3-5+ sending domains, manual DMARC monitoring becomes tedious. Use a DMARC monitoring tool that aggregates reports across all your domains:

• dmarcian - Multi-domain dashboard, good visualization
• Valimail - Enterprise-grade, automated enforcement
• EasyDMARC - Simple UI, good for small teams
• Postmark DMARC - Free, basic but functional

Troubleshooting Common Issues

"SPF PermError" in Email Headers

Cause: Your SPF record has a syntax error or exceeds 10 DNS lookups. Fix: Use MXToolbox to validate your SPF record. Count total lookups (each include: is one, plus nested includes). Flatten your record if over 10.

"DKIM Fail" Despite Configuration

Cause: Usually a DNS propagation delay (record added but not yet visible) or a mismatch between the selector in the email header and the selector in DNS. Fix: Verify the DKIM record is published with the correct selector. Wait 48 hours after adding the DNS record. Ensure the email provider has DKIM signing enabled (not just the DNS record).

"DMARC Fail" When SPF and DKIM Both Pass

Cause: Alignment failure. The domain in the "From" header doesn't match the domain that passed SPF or DKIM. Fix: Ensure the "From" address domain matches your sending domain. This commonly happens when using a third-party service that sends from their own domain but with your "From" address. Set up custom DKIM for that service using your domain.

Emails Going to Spam Despite All Authentication Passing

Cause: Authentication is one factor. Content quality, sender reputation, sending volume, and recipient engagement all affect inbox placement. Fix: Authentication alone doesn't guarantee inbox placement. Review the other items in the deliverability checklist: warmup, volume, content, and reputation monitoring.

DMARC Reports Showing Unknown Senders

Cause: Someone is spoofing your domain (common), or a legitimate service is sending from your domain that you forgot about. Fix: Check if the IP addresses in the report match any of your services. If they're unauthorized, this is exactly what DMARC is designed to catch. Moving to p=quarantine or p=reject will block these unauthorized emails.

FAQ

Do I need all three protocols (SPF, DKIM, DMARC), or is one enough?

You need all three. SPF alone can be bypassed by email forwarding (which changes the sending IP). DKIM alone doesn't tell receiving servers what to do when authentication fails. DMARC alone doesn't work without SPF and/or DKIM to provide the authentication results it evaluates. Together, they provide a complete authentication framework. Google, Microsoft, and Yahoo all recommend or require all three for bulk senders, and their spam filters weigh all three when making delivery decisions.

How long does it take to set up SPF, DKIM, and DMARC?

Initial setup takes 1-2 hours: 15 minutes for SPF (identify services, create the record), 30-60 minutes for DKIM (generate keys per service, add DNS records, enable signing), and 15 minutes for DMARC (create the monitoring record). However, the full DMARC implementation process takes 4-8 weeks because you need to monitor reports in "none" mode, fix any issues, and gradually enforce policy. Don't rush the enforcement phase.

Will setting up email authentication guarantee my emails reach the inbox?

No. Email authentication is necessary but not sufficient for good deliverability. It's one of many signals that receiving servers evaluate. Even with perfect SPF, DKIM, and DMARC, you can still land in spam if your sending reputation is poor (high bounce rates, spam complaints), your content triggers spam filters (spam words, too many links), or your sending volume is too high for a new domain. Authentication is the foundation; reputation and content quality are built on top.

What happens if my SPF record exceeds 10 DNS lookups?

The SPF specification (RFC 7208) limits SPF records to 10 DNS lookups. If your record exceeds this limit, SPF evaluation returns a "PermError" (permanent error), which is treated as an SPF failure by most receiving servers. Solutions: (1) use an SPF flattening service that resolves includes to direct IP addresses, reducing lookups, (2) consolidate sending services to reduce the number of includes needed, or (3) use a subdomain for some services to spread lookups across multiple SPF records.

Should I set my DMARC policy to "reject" for cold email sending domains?

For dedicated cold email sending domains, p=quarantine is usually sufficient and safer than p=reject. Since you control all sending from these domains, authentication failures typically indicate a configuration issue rather than spoofing. With p=quarantine, misconfigured emails go to spam (where you might catch the issue) rather than being rejected entirely (where the email disappears silently). Use p=reject only on your primary business domain after thorough validation.