DNS & AUTHENTICATION

SPF, DKIM, and DMARC explained

Three DNS records stand between your cold emails and the spam folder. Here's what they do and how to set them up correctly.

10 min read

01

Why authentication matters in 2026

Authentication used to be best practice. Now it's mandatory. Since February 2024, Gmail and Yahoo require SPF, DKIM, and DMARC alignment for any sender sending more than 5,000 emails per day. Senders without a valid DMARC policy face bulk delivery or rejection outright.

Gmail, Yahoo, and Microsoft have required SPF, DKIM, and DMARC for bulk senders since February 2024. Non-compliant messages are now rejected outright, not just flagged.

80%+

of domains globally still have no effective DMARC protection

2026

EasyDMARC Adoption Report cites most domains as either missing DMARC or stuck on p=none

More than 80% of domains globally have no effective DMARC protection — no record at all, or a monitoring-only p=none policy that offers zero spoofing protection. (EasyDMARC 2026 DMARC Adoption Report)

02

SPF explained

SPF — Sender Policy Framework — is a DNS record that authorises which mail servers are allowed to send email on behalf of your domain. When a receiving mail server gets an email claiming to be from you, it checks your SPF record to see if the sending IP is on the authorised list.

A typical SPF record for a Google Workspace sender:

v=spf1 include:_spf.google.com ~all

TXT record added to your domain's DNS

Common SPF mistakes:

Two SPF records

A domain can only have one SPF TXT record. If you add a second, both records are invalid. Merge them into a single record.

Exceeding the 10-lookup limit

SPF allows a maximum of 10 DNS lookups during evaluation. Every 'include:' counts as a lookup. Chains of includes from third-party senders (CRMs, marketing platforms) add up quickly. Tools like MXToolbox SPF analyser show your current count.

-all vs ~all

'~all' (soft fail) treats failures as suspicious but delivers them. '-all' (hard fail) rejects them. For cold email senders, ~all is safer while you verify your config is correct; migrate to -all once you're confident.

03

DKIM explained

DKIM — DomainKeys Identified Mail — adds a cryptographic signature to every email you send. The receiving server checks that signature against a public key published in your DNS. If the email was altered after it was signed — by a malicious relay, a spam filter, or anything in between — the signature fails.

Unlike SPF, DKIM survives email forwarding. When someone forwards your email to another account, the forwarding server doesn't change your domain — so the DKIM signature still validates. This makes DKIM the more reliable of the two for reputation purposes.

Enabling DKIM in Google Workspace

01Admin Console → Apps → Google Workspace → Gmail → Authenticate email
02Select your domain and click Generate new record
03Copy the TXT record Google provides and add it to your DNS
04Wait for DNS propagation (up to 48 hours), then click Start authentication

Enabling DKIM in Microsoft 365

01Defender portal → Email & Collaboration → Policies & Rules → Threat Policies → Email Authentication Settings
02Select DKIM tab, select your domain, toggle Enable
03Microsoft generates two CNAME records — add both to your domain's DNS
04Return and toggle Enable again once DNS has propagated

04

DMARC explained

DMARC — Domain-based Message Authentication, Reporting and Conformance — is the policy that ties SPF and DKIM together. It tells receiving mail servers what to do when an email fails SPF or DKIM alignment, and it provides aggregate reports so you can see what's happening to your email authentication in the wild.

A basic DMARC record:

v=DMARC1; p=none; rua=mailto:[email protected]

TXT record added at _dmarc.yourdomain.com

p=none (monitoring mode)

Authentication failures are reported to your rua address but not acted on. Emails are delivered regardless. Start here — you need to understand what's failing before you enforce.

p=quarantine

Authentication failures are sent to the spam folder instead of the inbox. Move to this once your rua reports show clean authentication with no unexpected failures.

p=reject

Authentication failures are rejected entirely. The email never reaches the recipient. Only move here once you're confident every legitimate sending source is properly authenticated.

05

Step-by-step setup order

Order matters. Setting up DMARC before DKIM is in place means DMARC reports will flag failures that don't represent real problems — and if you're enforcing at p=reject, legitimate email gets rejected.

1

1. Set up SPF

Add your SPF TXT record. Verify it passes using MXToolbox SPF check. Confirm you have only one SPF record and you're under the 10-lookup limit.

2

2. Enable DKIM

Generate and publish your DKIM key via Google Workspace or Microsoft 365. Wait for DNS propagation. Verify the signature is passing using an email header checker.

3

3. Add DMARC at p=none

Publish your DMARC record with p=none and a rua email address to receive aggregate reports. Do not skip this step to go straight to p=quarantine.

4

4. Monitor for 2 weeks

Review the DMARC aggregate reports. Look for unexpected failures — services you've forgotten that send on your behalf (newsletter tools, CRMs, ticketing systems). Fix each one.

5

5. Move to p=quarantine, then p=reject

Once reports show clean authentication with no unexpected sources, move to p=quarantine. Run for another week. If still clean, move to p=reject.

06

How to verify

Once your records are in place, verify them before you start sending. DNS propagation can take up to 48 hours, but most changes reflect within a few minutes to a few hours.

ForgeSend DNS Checker

Free tool at forgesend.cloud/tools/dns-checker — checks SPF, DKIM, DMARC, and MX records in real time with pass/fail status and fix instructions.

Check your domain →

MXToolbox

Industry-standard DNS diagnostics. Use the SPF, DKIM, and DMARC-specific checks for detailed analysis including lookup count and alignment.

What passing looks like

SPFv=spf1 include:_spf.google.com ~allPASS
DKIMselector1._domainkey → signature verifiedPASS
DMARCv=DMARC1; p=none; rua=mailto:dmarc@...PASS
MX10 aspmx.l.google.comPASS

Check your SPF, DKIM and DMARC records → DNS Health Checker

07

Common mistakes

Duplicate SPF records

Two TXT records starting with 'v=spf1' on the same domain means both are invalid. Merge all your includes and mechanisms into a single record.

DMARC before DKIM

If you publish DMARC with p=quarantine or p=reject before DKIM is working, legitimate email from your own domain will fail authentication and get rejected or quarantined.

Jumping straight to p=reject

DMARC at p=none first, then p=quarantine, then p=reject. Skipping stages means you reject legitimate email from services you've forgotten are sending on your behalf.

Ignoring DMARC aggregate reports

The rua reports tell you what's actually failing in the wild. They exist to help you find configuration gaps before you enforce. Ignoring them means enforcing blindly.

Check if your domain is blacklisted → Blacklist Checker

Check your DNS health in seconds

ForgeSend's free DNS checker validates SPF, DKIM, DMARC, and MX records in real time — no account needed.

Check your domain →
← Back to all guides