Every startup founder who has built a cold outreach sequence eventually runs into the same wall. Open rates crater. Replies stop arriving. The sequence that worked for three weeks suddenly produces nothing. The common assumption is that the copy is wrong or the targeting is off. In most cases, the real culprit is invisible: the domain's email authentication records are broken, incomplete, or missing entirely.

SPF, DKIM, and DMARC are three DNS-based protocols that together prove to receiving mail servers that a message is genuinely coming from the domain it claims to come from. They are not optional features. They are the foundation on which every outbound campaign, every investor update, every customer email, and every transactional notification sits. A startup without these records properly configured is essentially sending mail on unmarked letterhead — servers are right to be suspicious, and a substantial percentage of those messages will never reach an inbox.

This guide explains what each protocol does, how they interact as a system, and provides an exact step-by-step setup sequence any founder or growth operator can follow. It also covers the monitoring workflow that keeps a domain healthy over time, including the rotation practices and DMARC ramp sequence that distinguish teams who sustain strong deliverability from those who fix it once and watch it decay.

The goal is not just technical compliance. It is operational reliability — the confidence that when a message leaves a company's sending infrastructure, the downstream path to the recipient's inbox is as frictionless as physics will allow.

‍

Intro and Theory — What Each Protocol Actually Does

SPF: Sender Policy Framework

SPF answers one question: is this IP address allowed to send mail on behalf of this domain?

When a founder sends an email from their custom domain, the message travels through a mail server — whether that is Google Workspace, Microsoft 365, Postmark, SendGrid, or a custom SMTP server. The receiving server needs a way to check whether that sending server is authorized. SPF provides that check through a DNS TXT record published on the domain.

The SPF record is a plain-text string that lists every IP address and third-party service allowed to send on behalf of the domain. A receiving server performs a DNS lookup for the sender's domain, reads the SPF record, and compares the IP of the sending server against the authorized list. If the IP matches, SPF passes. If it does not, the message is flagged or rejected depending on how the record is configured.

The critical constraint most founders discover too late: an SPF record must fit within 255 characters per string and must not trigger more than 10 DNS lookups. Every include: tag in the record counts as one lookup. A growing startup that adds SendGrid for marketing, Postmark for transactional email, HubSpot for sequences, and Google Workspace for day-to-day communication can easily hit the ten-lookup limit, silently breaking SPF for a large portion of outbound volume.

DKIM: DomainKeys Identified Mail

DKIM answers a different question: has this message been tampered with in transit, and can the sending organization prove they signed it?

Where SPF validates the sending server's IP address, DKIM validates the message itself. When a sending server dispatches a message, it generates a cryptographic signature using a private key held by the sending organization. That signature is embedded in the message header. The receiving server performs a DNS lookup to retrieve the public key published by the sending domain and uses it to verify the signature. If the message was altered in any way after signing, the signature fails.

This matters for two reasons. First, it provides genuine proof that the message content is intact. Second, it establishes a persistent identity signal that inbox providers use to build domain reputation over time. A domain with consistently valid DKIM signatures and clean engagement history earns progressively better inbox placement. A domain that sends without DKIM has no reputation to build on — it starts from zero with every batch.

DKIM keys are tied to "selectors" — unique identifiers that allow a domain to maintain multiple active keys simultaneously. This is important for key rotation: swapping out an old key without breaking in-flight messages requires having the new key active and DNS-propagated before the old key is retired.

In 2025, 2048-bit DKIM keys are the appropriate standard. Earlier 1024-bit keys can still technically pass, but major inbox providers signal lower confidence in them.

DMARC: Domain-based Message Authentication, Reporting and Conformance

DMARC is the policy layer that ties SPF and DKIM together and tells receiving servers what to do when a message fails either or both checks.

A DMARC record is published as a DNS TXT record and contains three key components. The first is the policy: p=none (monitor only), p=quarantine (move to spam), or p=reject (block entirely). The second is the reporting directive, which tells receiving servers where to send aggregate and forensic reports on authentication results. The third is an alignment setting, which controls whether the domain in the "From" header must match the domain used in SPF or DKIM validation.

The reporting function is what makes DMARC genuinely powerful beyond just enforcement. Before a founder tightens a DMARC policy to quarantine or reject, they should spend at minimum two to four weeks at p=none reading the aggregate reports that arrive at the designated email address. Those reports reveal every service sending mail on behalf of the domain, including services the founder may have forgotten about or never configured intentionally.

Jumping to p=reject before completing that inventory is one of the most common deliverability mistakes early-stage teams make. It can silently block legitimate mail sent by services not yet added to the SPF record.

System Mechanics — How the Three Protocols Work Together

The Authentication Stack

SPF, DKIM, and DMARC do not operate independently. They function as a layered stack, and each layer amplifies or undermines the layers above and below it.

When a receiving server processes an incoming message, it runs SPF and DKIM checks in parallel. It then evaluates DMARC alignment: it checks whether the domain authenticated by SPF matches the "From" domain, and whether the domain covered by the DKIM signature matches the "From" domain. DMARC requires at least one of these alignments to pass. If both SPF and DKIM fail alignment, DMARC fails, and the policy in the DMARC record determines the outcome.

This alignment requirement is where many sending-service configurations break. Some third-party tools send mail with their own domain in the envelope "From" (the technical sending address) while showing a custom domain in the visible "From" header. This causes SPF alignment to fail even when SPF technically passes. The fix is to ensure the third-party tool is configured to use the sending domain in both the envelope and header, or to set up DKIM signing with the custom domain via the tool's platform.

Reputation Inheritance and Domain Warming

Inbox providers — Google, Microsoft, Yahoo, and others — maintain reputation scores for sending domains and sending IPs. DKIM is the primary mechanism through which a domain accumulates this reputation over time, because it creates a persistent identity signal that travels with every message.

A new domain has no reputation at all. A domain that has been actively sending clean, authenticated mail for six months or more has a substantially different starting position when a new campaign launches. This is why domain warming — the practice of gradually increasing send volume on a new domain to build reputation before scaling outbound — depends on having DKIM properly configured from day one.

SPF and DMARC do not directly build reputation the way DKIM does, but they do protect against spoofing attacks that could damage a domain's reputation. A domain without DMARC enforcement is a target for impersonation. Threat actors can send phishing emails that appear to come from the unprotected domain, generate spam complaints and abuse reports that attach to the domain's reputation, and degrade deliverability for the legitimate organization without the founder ever knowing it is happening.

The Cascading Effect of a Single Missing Record

It is worth making explicit what happens to a campaign when authentication is broken or absent:

If SPF is missing or has too many lookups, a portion of outbound mail fails the IP authorization check. The percentage depends on which receiving server is processing the message and its specific policies, but enterprise Microsoft 365 domains tend to be aggressive: failing SPF for a cold outreach message to an enterprise contact is often a direct path to the spam folder.

If DKIM is missing, the domain has no cryptographic identity. Inbox providers treat these messages with minimal historical trust, which increases the likelihood of spam filtering even when the content is clean and the sender has good intentions.

If DMARC is missing, there is no policy governing what happens when SPF or DKIM fail. Some inbox providers will apply their own internal policies; others will let messages through regardless. More importantly, the organization receives no reports, has no visibility into who is sending on its behalf, and cannot detect spoofing activity.

All three records operating correctly, with proper alignment and regular monitoring, produce significantly better outcomes than any single record alone.

Implementation and Checklists — The Exact Setup Sequence

Pre-Setup Inventory

Before writing a single DNS record, a complete inventory of every service sending mail on behalf of the domain is necessary. This list typically includes:

• The primary email client (Google Workspace, Microsoft 365, Zoho Mail).
• The transactional email service (Postmark, Mailgun, SendGrid, AWS SES).
• The marketing or outbound platform (HubSpot, Apollo, Lemlist, Instantly, Smartlead).
• Any CRM that sends automated notifications (Salesforce, Pipedrive).
• Any support platform that sends customer-facing email (Intercom, HelpScout, Front).
• Any billing or payment platform that sends receipts (Stripe, Paddle, Chargebee).

Every item on this list needs to be represented in either the SPF record or DKIM configuration before DMARC is tightened beyond p=none.

Step-by-Step: Setting Up SPF

SPF setup happens entirely through the domain's DNS management panel. The record type is TXT, and it is published at the root of the domain (not a subdomain, unless subdomain sending is involved).

Step 1: Log into the DNS management console for the domain. This is typically the domain registrar (Namecheap, GoDaddy, Cloudflare, Google Domains) or a dedicated DNS provider.

Step 2: Create a new TXT record with the host set to "@" (the root domain).

Step 3: Build the SPF record string. The record always begins with v=spf1 and ends with a mechanism that specifies what to do with mail from unauthorized sources. A conservative starting record for a Google Workspace user who also uses Postmark looks like this:

The all ending means "soft fail" — unauthorized sources are flagged but not rejected. This is appropriate during the initial setup phase. Once the record is verified and stable, some teams move to all (hard fail), though this can cause deliverability issues with certain forwarding scenarios and many teams leave it at all long-term.

Step 4: Save the record and wait for DNS propagation. This typically takes between 5 and 60 minutes but can take up to 48 hours on some registrars.

Step 5: Validate using a tool like MXToolbox SPF Lookup. The tool will show whether the record resolves correctly and how many DNS lookups it generates.

SPF Lookup Budget Management: If the DNS lookup count approaches ten, the record needs to be flattened. Flattening replaces include: tags with their actual underlying IP addresses. Tools like dmarcian and EasyDMARC offer SPF flattening features that handle this automatically and keep the record within limits.

Step-by-Step: Setting Up DKIM

DKIM setup starts inside the sending service, not in DNS. Each service generates its own key pair, provides the public key, and the public key is published in DNS.

Step 1: Inside Google Workspace (or the primary email provider), navigate to the Admin Console, then Apps, then Google Workspace, then Gmail, then Authenticate Email. Generate a new DKIM key. Google will provide a DNS record name (the selector) and a DNS TXT value (the public key).

Step 2: In the DNS console, create a new TXT record. The host field is the selector name provided by Google, typically formatted as google._domainkey for Google Workspace. The value is the public key string provided.

Step 3: For each additional sending service (Postmark, SendGrid, HubSpot, etc.), locate the DKIM setup section within that platform's domain authentication or sender settings. Each service will provide its own selector and public key. Repeat the DNS record creation for each.

Step 4: Return to each sending service and trigger the verification step. Most platforms have a button that says "Verify" or "Authenticate" that performs a DNS lookup to confirm the record is live.

Step 5: Validate using MXToolbox DKIM Lookup or a test send to mail-tester.com.

Key Rotation: Document each DKIM selector and the date it was created. Set a calendar reminder to rotate keys annually, or immediately if there is any suspicion of key compromise. Rotation requires publishing the new key before removing the old one, with at least 72 hours of overlap to allow in-transit messages signed with the old key to be verified.

Step-by-Step: Setting Up DMARC

DMARC is also a DNS TXT record, published at the subdomain _dmarc of the root domain.

Step 1: Create a dedicated email address or email alias to receive DMARC reports. Something like dmarc-reports@[domain.com] works. Alternatively, use a dedicated DMARC reporting platform such as dmarcian, Valimail, or EasyDMARC, which parse and visualize aggregate reports automatically.

Step 2: In the DNS console, create a new TXT record. The host is _dmarc and the value is the DMARC policy record. The starting record should use p=none with reporting enabled:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-reports@yourdomain.com; fo=1;

• 
  rua is the address for aggregate reports.
• ruf is the address for forensic (message-level) reports.
• fo=1 requests reports whenever any authentication mechanism fails, which provides the most comprehensive visibility.

Step 3: After two to four weeks of running p=none, review the aggregate reports. The reports show every IP address and sending service that has sent mail claiming to come from the domain, along with pass/fail results for SPF and DKIM. Any legitimate service that is failing authentication needs to be remediated before proceeding.

Step 4: Once all legitimate senders are authenticated and the reports show clean results, advance to p=quarantine:

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@yourdomain.com;

The pct=10 tag means the quarantine policy applies to only 10% of failing messages initially. This provides a safety valve while the policy is being validated.

Step 5: Over the following two to four weeks, raise pct to 25%, then 50%, then 100% as the reports remain clean. Once at 100% quarantine with no legitimate mail failures, advance to p=reject.

Step 6: Final DMARC record at full enforcement:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

Implementation Checklist

Use this checklist before launching any cold outbound campaign on a new domain or after any infrastructure change:

SPF:

• [ ] Single SPF record published at root domain
• [ ] All sending services represented with include: tags or IP ranges
• [ ] DNS lookup count verified at 10 or fewer
• [ ] Record ends with ~all or -all
• [ ] Verified working with a test send to mail-tester.com

DKIM:

• [ ] DKIM key generated and activated in primary email provider
• [ ] DKIM DNS record published and verified for primary provider
• [ ] DKIM records published for each additional sending service
• [ ] All DKIM selectors documented with creation dates
• [ ] Key rotation schedule calendared (annual minimum)

DMARC:

• [ ] _dmarc TXT record published with p=none and rua address
• [ ] DMARC aggregate reports being received and reviewed
• [ ] All legitimate sending services passing SPF or DKIM with alignment
• [ ] DMARC policy advanced to quarantine after clean monitoring period
• [ ] DMARC policy advanced to reject at full enforcement

Ongoing Monitoring:

• [ ] DMARC reports reviewed at minimum monthly
• [ ] MXToolbox email health monitor set up for domain
• [ ] Any new sending service added to SPF and DKIM before first send

‍

Common Mistakes That Undermine Months of Setup Work

Adding a sending service after the campaign starts. Every time a new tool is added to the outbound stack without updating SPF and DKIM first, a portion of that tool's outbound volume will fail authentication. The failure may not surface immediately if the tool's IP is not on major blocklists, but it will show up in DMARC reports and quietly accumulate as a reputation drag.

Running multiple SPF records. DNS only allows one SPF record per domain. If two records exist, receiving servers will choose one arbitrarily or reject both. When moving from one ESP to another, the old record must be removed and the new one added in a single transaction, not staged.

Skipping the subdomain strategy for high-volume sending. Many B2B founders use their primary domain (company.com) for both day-to-day email and outbound sequences. This exposes the primary domain's reputation to the deliverability outcomes of cold outreach. A cleaner architecture uses a sending subdomain (mail.company.com or outbound.company.com) with its own SPF, DKIM, and DMARC configuration, keeping campaign performance isolated from the main domain's reputation.

Not configuring DMARC on parked or forwarding domains. A parked domain that is not actively used for sending is still a spoofing target. Any domain the organization owns should have at minimum a p=reject DMARC record published to prevent it from being impersonated.

‍

Monitoring and Maintaining Authentication Health Over Time

The most common pattern in teams that maintain strong deliverability is weekly or monthly review of DMARC aggregate reports. Tools like dmarcian, EasyDMARC, and Valimail convert the raw XML reports into readable dashboards that surface new senders, failing authentication events, and changes in sending volume by source.

Beyond DMARC reports, a monthly check of sender reputation through tools like Google Postmaster Tools (for domains sending to Gmail) and Microsoft SNDS (for domains sending to Outlook.com and Office 365) provides a direct signal of how the major inbox providers are currently scoring the domain. A drop in reputation score almost always precedes a drop in inbox placement, giving a two-to-four week window to diagnose and remediate before campaign performance is visibly impacted.

The founders and growth operators who treat email infrastructure as a living system rather than a one-time setup project are the ones who sustain reliable inbox placement across scaling outbound volume, organizational changes, and the periodic tightening of inbox provider standards that has characterized every year from 2023 through 2025.

‍