SPF, DKIM, DMARC: The Complete Setup Guide for 2025

Why Email Authentication Is No Longer Optional

In February 2024, Google and Yahoo simultaneously announced new requirements for bulk email senders: proper SPF, DKIM, and DMARC authentication became mandatory for anyone sending more than 5,000 emails per day to Gmail or Yahoo addresses. Senders who fail to meet these requirements see their emails rejected outright — not filtered to spam, but bounced back entirely. Microsoft followed with similar requirements shortly after. Email authentication has gone from a best practice to an absolute requirement.

But even if you are a small sender well under the 5,000 email threshold, authentication directly impacts your inbox placement. Our data shows that emails with all three protocols correctly configured achieve 92% average inbox placement, compared to just 54% for emails missing even one authentication protocol. Think of SPF, DKIM, and DMARC as your email passport, visa, and boarding pass — you need all three to reach your destination.

Here is a simple analogy that explains how the three protocols work together. SPF is like a guest list at a building entrance: it tells the security guard which delivery people are authorized to drop off packages (emails) on your behalf. DKIM is like a tamper-proof seal on the package: it proves the contents have not been altered since the authorized sender shipped them. DMARC is the policy manual that tells security what to do when someone shows up with a suspicious package: let it through, set it aside for inspection, or reject it entirely.

Setting Up SPF: Syntax, Mechanisms, and Common Pitfalls

SPF (Sender Policy Framework) is a DNS TXT record published on your domain that lists every server authorized to send email on your behalf. The syntax follows a specific format. A basic SPF record looks like this: v=spf1 ip4:198.51.100.0/24 include:_spf.google.com include:spf.protection.outlook.com ~all. Let’s break this down piece by piece.

v=spf1 declares this is an SPF version 1 record. The ip4: mechanism authorizes a specific IP address or range (CIDR notation). The include: mechanism tells receiving servers to also check the SPF record of the specified domain — this is how you authorize third-party services like Google Workspace, Microsoft 365, Mailchimp, or SendGrid. The ~all at the end is the default policy for servers not listed: the tilde (~) means soft fail (accept but flag), while a hyphen (-) means hard fail (reject).

The single most dangerous pitfall with SPF is the 10 DNS lookup limit. Every include:, a, mx, and redirect mechanism counts as one DNS lookup. Nested includes (an included domain that itself includes other domains) also count toward your limit. If your SPF record requires more than 10 lookups, SPF validation fails for every email you send — and the failure is completely silent. You will not see an error. Your emails will simply start failing SPF checks. Use an SPF validation tool like MXToolbox to count your lookups. If you are over 10, use ip4: directives to replace some include: statements, or use an SPF flattening service.

Another common mistake: publishing multiple SPF records on the same domain. The SPF specification explicitly states that a domain must have at most one SPF record. If you have two TXT records starting with v=spf1, SPF validation returns a permanent error (PermError), and all SPF checks fail. This happens most often when switching email providers — you add the new provider’s SPF include but forget to remove the old one. Always consolidate into a single record.

Setting Up DKIM: Key Generation, DNS Records, and Selectors

DKIM (DomainKeys Identified Mail) uses public key cryptography to sign your outgoing emails. Here is how it works technically: your email server holds a private key that it uses to generate a digital signature for each outgoing email. This signature is added to the email’s header as a DKIM-Signature field. When the receiving server gets the email, it extracts the selector and domain from the signature, looks up the corresponding public key in your DNS records, and uses it to verify the signature. If the verification succeeds, the server knows the email was genuinely sent by an authorized server and has not been modified in transit.

To set up DKIM, first generate a key pair. Most email providers do this automatically. For Google Workspace, go to Admin > Apps > Google Workspace > Gmail > Authenticate Email, and Google generates your DKIM key. You then publish the public key as a DNS TXT record. The record name follows the format selector._domainkey.yourdomain.com. A typical DKIM DNS record looks like: v=DKIM1; k=rsa; p=MIIBIjANBgkqhki... (the long string is your public key in base64).

Use a 2048-bit key, not 1024-bit. While 1024-bit keys are still accepted by most providers, they are considered cryptographically weak and Google has begun flagging them. Some DNS providers have a 255-character limit for TXT records, which can be an issue with 2048-bit keys. The solution is to split the key into multiple strings within the same TXT record — most DNS providers handle this automatically, but verify by checking the record with a DKIM validator after publishing.

DKIM alignment is critical for DMARC. The d= domain in your DKIM signature must match (or be a subdomain of) your From address domain. If your From address is user@company.com but your DKIM signature has d=mail.company.com, you have relaxed alignment (acceptable for DMARC). But if your DKIM has d=emailprovider.com, you have no alignment at all, and DMARC will treat this as a failure even though DKIM verification technically passed. This misalignment issue affects roughly 15-20% of senders we audit.

Setting Up DMARC: Policies, Reports, and Gradual Enforcement

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy layer that ties SPF and DKIM together. Your DMARC record tells receiving servers what to do when an email fails both SPF and DKIM alignment. Note: DMARC passes if either SPF or DKIM passes with alignment — both do not need to pass. This is important because legitimate emails sometimes fail one protocol (for example, forwarded emails often break SPF).

A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com. A comprehensive record looks like: v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc-agg@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; adkim=r; aspf=r; pct=100; fo=1. Let’s decode each tag. p= is the policy for your domain (none, quarantine, or reject). sp= is the policy for subdomains. rua= is where aggregate reports are sent. ruf= is where forensic (failure) reports are sent. adkim= and aspf= set DKIM and SPF alignment mode (r=relaxed, s=strict). pct= is the percentage of failing emails to apply the policy to. fo= sets failure reporting options.

The golden rule: always start with p=none. This monitoring-only mode lets you collect DMARC reports without affecting email delivery. Run p=none for at least 2-4 weeks while you analyze the aggregate reports. These reports show you every IP address and domain sending email as your domain. You will likely discover legitimate sources you forgot to authenticate (your CRM, your ticketing system, your marketing automation tool). Authenticate all legitimate sources before moving to enforcement.

Once all legitimate sources are passing DMARC, move to p=quarantine with pct=25 (apply quarantine to only 25% of failing emails). Monitor for a week. If there are no issues, increase to pct=50, then pct=100. Finally, upgrade to p=reject. The entire journey from p=none to p=reject typically takes 6-8 weeks for most organizations. Rushing this process risks blocking legitimate email — I have seen companies accidentally quarantine their own transactional emails by skipping the monitoring phase.

Common Authentication Mistakes and How to Avoid Them

Mistake 1: Multiple SPF records. As mentioned, having two v=spf1 records on the same domain causes a permanent error. Consolidate all authorized sources into a single record. Mistake 2: Exceeding the 10 DNS lookup limit. Audit your SPF record with a lookup counter, and flatten or replace include: statements with ip4: directives where possible.

Mistake 3: DKIM key rotation neglect. DKIM keys should be rotated every 6-12 months. If your private key is compromised, an attacker can sign emails as your domain. Key rotation involves generating a new key pair with a different selector, publishing the new public key in DNS, updating your server to use the new private key, and removing the old key after a transition period. Mistake 4: No DMARC record at all. Without DMARC, there is no policy governing what happens when authentication fails, and you receive no visibility into who is sending email as your domain.

Mistake 5: Using p=reject before monitoring. This is the fastest way to block your own legitimate email. Always start with p=none and review reports. Mistake 6: Forgetting subdomains. If your main domain has DMARC but your subdomains do not, attackers can spoof your subdomains. Use the sp= tag to set a subdomain policy. Mistake 7: Not validating after changes. Every time you modify DNS records, verify them with tools like MXToolbox, DMARC Analyzer, or Stekpad’s built-in DNS health monitor. DNS propagation can take up to 48 hours, so test again the next day.

How to Verify Your Setup Is Working

After configuring all three protocols, verification is essential. Start by sending a test email to mail-tester.com, which provides an instant score (aim for 9/10 or above) and detailed breakdown of your authentication status. Next, check Google Postmaster Tools — within 24-48 hours of sending, it will show your authentication rates (target 100% for SPF, DKIM, and DMARC).

Use MXToolbox’s SuperTool to query your SPF, DKIM, and DMARC records directly and identify syntax errors. For DKIM, you need to know your selector to query it (format: selector._domainkey.yourdomain.com). Common selectors include google, default, s1, and k1 depending on your email provider. You can also use the email headers of a received email to find your DKIM selector — look for the s= tag in the DKIM-Signature header.

Stekpad’s DNS health monitor runs these checks automatically every 24 hours and alerts you if any authentication protocol fails or is misconfigured. This continuous monitoring catches issues like expired DKIM keys, SPF records that break after adding a new service, or DNS changes that accidentally remove your DMARC record. Prevention is always better than discovering an authentication issue after your emails have been landing in spam for a week.

What Happens When Authentication Fails

When SPF fails, the receiving server knows the email was sent from an unauthorized server. Depending on the SPF policy (~all vs -all) and the presence of a DMARC policy, the email may be delivered normally, filtered to spam, or rejected. With SPF soft fail (~all) and no DMARC, most providers will still deliver the email but flag it with a warning. With SPF hard fail (-all) or a DMARC reject policy, the email will be bounced back to the sender.

When DKIM fails, the receiving server cannot verify the email’s integrity. This happens most commonly when emails are forwarded (the forwarding server may modify headers or body), when the DKIM key has expired or been removed from DNS, or when there is a configuration error in the signing process. DKIM failures without a DMARC policy usually result in reduced inbox placement rather than outright rejection.

When DMARC fails (meaning both SPF and DKIM alignment fail), the receiving server applies the DMARC policy. With p=none, nothing happens except reporting. With p=quarantine, the email goes to spam. With p=reject, the email is bounced. This is why proper DMARC deployment is so critical: a premature p=reject policy on a domain with misconfigured SPF or DKIM will block every email that fails alignment, including your legitimate messages. Take the time to do it right.