SPF, DKIM & DMARC Explained: How to Configure DMARC p=reject

You can have the sharpest prospect list and the tightest cold email copy on the market. But if your domain isn't authenticated correctly, your emails land in spam or get bounced before anyone reads them. Since February 2024, Google and Yahoo have made SPF, DKIM and DMARC mandatory for high-volume senders, and in 2025 Microsoft fell in line. In 2026 these three protocols are no longer a niche technical detail: they're the baseline requirement for cold outreach that doesn't torch your domain.

In this guide I'll walk you through what SPF, DKIM and DMARC actually are, why you need all three, and above all how to reach DMARC with a p=reject policy, the level of protection 2026 standards effectively demand. No textbook theory, just what to configure and in what order.

Why email authentication became mandatory

The problem these protocols solve is as old as email itself. Anyone can write whatever they want in the "from" field. Nothing inherently stops a scammer from sending a message signed "info@yourdomain.com" without having any access to your domain. That's how phishing and spoofing work.

SPF, DKIM and DMARC are the answer to that gap. They're three technical signatures that tell the receiving server: "this email really does come from who it claims to come from." Providers use them as a first-pass filter. If they're missing or misconfigured, your message starts out with a reputation handicap no matter how good the content is. If you want the full picture of what pushes messages into the junk folder, we've written a dedicated guide on why emails end up in spam.

The formal rules changed in 2024. For anyone sending more than 5,000 emails a day to Gmail (so-called "bulk senders"), Google and Yahoo require all three protocols active, a spam rate under 0.3%, and one-click unsubscribe. In practice, though, for B2B cold outreach — where you're sending dozens or hundreds of emails from a domain — the 5,000 threshold is almost irrelevant: without full authentication, deliverability collapses long before you hit it. This is central to every customer acquisition system built on cold email.

SPF: who's authorized to send on your behalf

SPF (Sender Policy Framework) is the list of "authorized carriers." It's a text record you publish in your domain's DNS declaring which server IPs are allowed to send email in your name. When a receiving server gets a message from "yourdomain.com," it checks this list. If the sending IP is on it, the check passes. If it isn't, the message is suspect.

An SPF record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net -all

What this means in practice:

• v=spf1: declares this is a version 1 SPF record.
• include: authorizes a service's servers (here, Google Workspace and SendGrid). Every tool that sends on your behalf needs to be included.
• -all: the most important part. The dash means "reject everything else." This is "hard fail" mode, and it's the one you should use. The ~all variant ("soft fail") is more permissive and should only be used while testing.

Two common mistakes that cost you deliverability:

• Multiple SPF records on the same domain. Only one is allowed. If you have two, authentication fails. They need to be merged into a single line.
• The 10 DNS lookup limit. Each include counts as one or more DNS queries. Go over 10 and SPF throws a "permerror" and stops working. If you use a lot of services, look into SPF flattening tools.

DKIM: the message's cryptographic signature

SPF verifies where an email comes from. DKIM (DomainKeys Identified Mail) verifies that the content hasn't been tampered with and that it really came from you. It works with a pair of cryptographic keys: a private one, which your server uses to sign every outgoing email, and a public one, which you publish in your DNS. The receiving server takes the signature, checks it against the public key, and confirms they match.

DKIM's practical advantage over SPF is that the signature "travels" with the email. If a message gets forwarded, SPF often breaks (the sending server changes), while DKIM holds up, because the signature stays attached to the content.

Setup depends on your provider. In Google Workspace you enable it from the admin console (email authentication section), which generates a key for you to paste into your DNS as a TXT record. Practical tips for 2026:

• Use 2048-bit keys, not 1024-bit. That's the current security standard.
• Every sending platform (your Google Workspace, your cold email tool, the billing software that sends invoices) has its own DKIM "selector" and its own key. All of them need to be published.
• After activation, wait for DNS propagation (anywhere from a few minutes to a few hours) before verifying.

DMARC: the rule that ties everything together

SPF and DKIM alone aren't enough, and this is the point almost no guide explains well. There's a piece missing: what should the receiving server do when the checks fail? And where does it send you reports? That's DMARC's job (Domain-based Message Authentication, Reporting and Conformance).

DMARC does two things. First, it introduces the concept of alignment: it's not enough for SPF or DKIM to pass — the verified domain also has to match the domain shown in the "From" field. This closes the loophole where someone passes the technical checks using a different domain than the one displayed. Second, it has you declare a policy: what to do with emails that fail alignment.

A basic DMARC record:

v=DMARC1; p=none; rua=mailto:report@yourdomain.com

The letter that matters is p=. It has three possible values, and they form your severity scale:

Policy	What happens to unaligned email	When to use it
p=none	No action, monitoring and reporting only	Initial phase, to gather data
p=quarantine	Sent to spam / quarantine	Transition phase, after checking the reports
p=reject	Rejected and never delivered	End goal, maximum protection

The rua= is the address where you receive daily aggregate reports: they're an X-ray of who's sending email in your name. Reading them is what tells you when you're ready to raise the policy level.

How to reach DMARC p=reject without breaking legitimate email

Here's the tricky part. Jumping straight to p=reject without preparation is the fastest way to make your invoices, your billing software's notifications and your legitimate newsletters disappear. The reason is that some services sending on your behalf (your CRM, your e-invoicing tool, your email marketing platform) often aren't authenticated correctly yet. With p=reject, those emails simply get rejected.

The right approach is gradual, in three phases. It takes patience, usually 4 to 8 weeks:

1. Phase 1, monitoring (p=none). Publish the record with p=none and the rua address. It blocks nothing, but you start receiving reports. For 2-4 weeks you watch which services send in your name and which ones fail alignment. You'll almost always discover legitimate senders you'd forgotten about.
2. Phase 2, partial quarantine (p=quarantine with pct). Once the reports show your legitimate senders passing, move to p=quarantine. You can start with pct=25 (applies the rule to only 25% of emails) and gradually ramp up to 100%. Keep monitoring the reports.
3. Phase 3, reject (p=reject). Once reports have been clean for a few weeks and every legitimate sender is aligned, switch to p=reject. Your domain is now locked down: no one can spoof it successfully anymore, and providers treat you as a trusted sender.

The final, steady-state record will look like this:

v=DMARC1; p=reject; rua=mailto:report@yourdomain.com; adkim=s; aspf=s

The adkim=s and aspf=s parameters enforce "strict" alignment, the most rigorous kind. They're optional, but recommended once you're stable on reject.

Authentication and warmup: two different things that work together

A common misconception: authenticating your domain doesn't by itself guarantee your cold emails land in the inbox. SPF, DKIM and DMARC are the necessary condition, not the sufficient one. They're your domain's ID card. But a brand-new domain, even one perfectly authenticated, doesn't yet have reputation.

That's where warmup comes in: the process of gradually ramping up sending volume over the first few weeks, so providers learn to trust you. Authentication and warmup are two legs of the same table. Remove one and the whole campaign wobbles. Alongside them sit the metrics bulk senders must hit: spam under 0.3%, bounce under 2%, and one-click unsubscribe always present.

For anyone setting up cold outreach seriously, technical deliverability needs to be decided before you write a single email. If you're evaluating tools, we compared the options in our guide to the best cold email software for 2026. And if you're weighing email against social, it's worth reading our comparison of cold email vs LinkedIn.