← Back to Blog
Security

SPF, DKIM, and DMARC Explained — The Three DNS Records That Keep Your Email Out of Spam

By Tobava Security Team  ·  March 28, 2026  ·  9 min read

Email deliverability is 80% DNS configuration. If your emails are landing in spam folders, if your domain is being spoofed by phishers, or if you recently received a rejection from Gmail saying your mail doesn't meet their 2024 sender requirements, the root cause is almost certainly a missing or misconfigured SPF, DKIM, or DMARC record.

This guide explains what each record does, how they work together, and gives you copy-paste DNS entries for common scenarios.

The Problem These Records Solve

Email was designed in an era of trusted networks. The SMTP protocol that email uses has no built-in mechanism to verify that a message actually came from who it claims to be from. Anyone can send an email claiming to be from [email protected] — and without authentication records in place, receiving mail servers have no reliable way to detect the forgery.

SPF, DKIM, and DMARC are three DNS-based mechanisms that together solve this problem. They allow receiving mail servers to cryptographically verify that an email claiming to come from your domain actually came from a server you authorised. If verification fails, the receiving server can reject or quarantine the message.

SPF — Sender Policy Framework

SPF is a DNS TXT record that lists the mail servers authorised to send email on behalf of your domain. When a receiving server gets a message claiming to be from yourcompany.com, it checks the SPF record in your DNS and verifies that the sending server's IP address is on the approved list.

How to set up SPF

Add a TXT record to your domain's DNS with the following format:

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

If you send email from multiple services (e.g., Google Workspace for regular email and Mailchimp for newsletters):

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

The ~all at the end is a "soft fail" — messages that don't match will be accepted but marked as suspicious. Use -all (hard fail) once you're confident your SPF record is complete, as it causes non-matching servers to be rejected outright.

Common mistake: You can only have one SPF record per domain. If you add a second TXT record starting with v=spf1, both records will be ignored. Combine all your authorised senders into a single record.

DKIM — DomainKeys Identified Mail

DKIM adds a cryptographic signature to every outgoing email. Your mail server signs each message with a private key, and the corresponding public key is published in your DNS. Receiving servers retrieve your public key and use it to verify the signature. If the email was tampered with in transit, the signature will not match.

DKIM solves something SPF cannot: it proves the message content has not been altered after leaving your server. A message can pass SPF (sent from an authorised server) but still have its content modified in transit. DKIM detects this.

How to set up DKIM

DKIM requires your email provider to generate a key pair. The process varies by provider:

The resulting DNS record looks like this (the key will be your own):

Name: google._domainkey.yourcompany.com Type: TXT Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ...

The google prefix is the selector — a label that identifies which key to use. You can have multiple DKIM records with different selectors for different sending services.

DMARC — Domain-based Message Authentication, Reporting and Conformance

DMARC is the policy layer that sits on top of SPF and DKIM. It tells receiving mail servers what to do when a message fails authentication, and optionally requests that those servers send you reports about authentication failures.

Without DMARC, a phisher can spoof your domain even if you have SPF and DKIM set up, by sending email from a different server that doesn't use your domain's records (a technique called domain alignment bypass). DMARC closes this gap by requiring that the "From" address in the email aligns with either the SPF or DKIM authenticated domain.

How to set up DMARC

Start with a monitoring policy while you validate your configuration:

Name: _dmarc.yourcompany.com Type: TXT Value: v=DMARC1; p=none; rua=mailto:[email protected]

The p=none policy means: do nothing with failing messages, but send me reports. This lets you see what's failing before you enforce anything.

After reviewing your reports for 2–4 weeks and confirming all legitimate mail is passing, move to enforcement:

v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100

p=quarantine sends failing messages to spam. p=reject refuses delivery entirely — the strictest option, appropriate for high-value domains at risk of phishing attacks.

How the Three Records Work Together

A receiving mail server checks these records in sequence:

  1. SPF check: Is the sending IP authorised in the domain's SPF record?
  2. DKIM check: Does the message carry a valid cryptographic signature from the claimed domain?
  3. DMARC check: Did the message pass at least one of SPF or DKIM with domain alignment? If not, apply the DMARC policy (none / quarantine / reject).

A message only needs to pass one of SPF or DKIM to satisfy DMARC. But having both configured gives you redundancy — if one check fails due to a forwarding service or mailing list, the other can still pass.

Gmail's 2024 Sender Requirements

In February 2024, Google began enforcing new requirements for bulk senders (anyone sending more than 5,000 messages per day to Gmail addresses). These requirements are now applied more broadly:

If your emails to Gmail users are bouncing or going to spam since early 2024, failure to meet these requirements is the most likely cause.

Testing Your Configuration

Once you've set up your records, allow 24–48 hours for DNS propagation, then verify:

Tobava Mail automatically configures SPF, DKIM, and DMARC for all custom domains. Set up your secure business email →