SPF, DKIM, and DMARC: Stop Your Emails from Going to Spam

You have spent hours crafting the perfect email — a password reset notification, an invoice, a welcome message — and it lands in your recipient's spam folder. Or worse, it never arrives at all. The most common reason? Your domain is missing proper email authentication records.

SPF, DKIM, and DMARC are three DNS-based mechanisms that work together to prove that an email genuinely came from your domain. Without them, receiving mail servers have no reliable way to distinguish your legitimate messages from phishing attempts that spoof your address. This guide walks you through each protocol, how to configure them, and how to verify your setup with our SPF Record Test tool.

Why Email Authentication Matters

Email was designed in an era when trust was assumed. The SMTP protocol, which powers email delivery, has no built-in mechanism to verify that the "From" address is genuine. Anyone with a mail server can send an email claiming to be from ceo@yourcompany.com, and without authentication, the receiving server has no way to know it is a forgery.

This fundamental design flaw has led to decades of phishing, spam, and business email compromise (BEC) attacks. Email authentication protocols were developed to address this gap by allowing domain owners to publish machine-readable policies in their DNS records that tell receiving servers how to verify messages.

The benefits of proper email authentication include:

• Improved deliverability – Authenticated emails are far less likely to be flagged as spam.
• Brand protection – Prevents attackers from sending phishing emails that appear to come from your domain.
• Visibility – DMARC reporting gives you insight into who is sending email on your behalf (both legitimate and malicious).
• Compliance – Major email providers like Google and Yahoo now require SPF, DKIM, and DMARC for bulk senders.

SPF: Sender Policy Framework

SPF allows you to specify which mail servers are authorized to send email on behalf of your domain. It works by publishing a TXT record in your DNS that lists the approved IP addresses and hostnames.

How SPF Works

1. You publish an SPF record in your DNS as a TXT record at the domain apex.
2. When a receiving server gets an email from your domain, it looks up your SPF record.
3. It checks whether the sending server's IP address matches one of the authorized sources in your SPF record.
4. If the IP matches, the SPF check passes. If not, the SPF check fails.

SPF Record Syntax

An SPF record is a single TXT record that starts with v=spf1 and contains a series of mechanisms:

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:sendgrid.net -all

Let's break this down:

• v=spf1 – Required version tag. Must be the first element.
• ip4:203.0.113.0/24 – Authorizes all IP addresses in this CIDR range.
• include:_spf.google.com – Authorizes all IPs listed in Google Workspace's SPF record (delegates to their record).
• include:sendgrid.net – Also authorizes SendGrid's mail servers.
• -all – The "all" mechanism defines the default policy. -all (hard fail) means reject anything not matching the previous mechanisms. ~all (soft fail) means accept but mark it. ?all (neutral) means no policy.

Common SPF Mistakes

• Too many DNS lookups – SPF has a limit of 10 DNS lookups (includes and redirects). Exceeding this limit causes the entire SPF check to fail. Use our SPF Record Test to check your lookup count.
• Using +all – This effectively authorizes the entire internet to send email as your domain. Never do this.
• Forgetting third-party senders – If you use a CRM, helpdesk, or transactional email service, their servers need to be included in your SPF record.
• Multiple SPF records – A domain must have exactly one SPF record. Having two causes both to be invalid.

DKIM: DomainKeys Identified Mail

While SPF verifies the sending server, DKIM verifies the message itself. It uses public-key cryptography to sign outgoing emails so that the receiving server can verify the message has not been altered in transit.

How DKIM Works

1. Your mail server generates a public/private key pair. The private key stays on the server; the public key is published as a DNS TXT record.
2. When sending an email, the server creates a cryptographic hash of certain headers and the body, then signs that hash with the private key.
3. The signature is added to the email as a DKIM-Signature header.
4. The receiving server extracts the selector and domain from the signature, looks up the public key in DNS, and verifies the signature.

The DKIM DNS Record

DKIM public keys are published at a specific subdomain following the pattern selector._domainkey.yourdomain.com:

selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

The selector allows you to have multiple DKIM keys simultaneously (for example, one for your main mail server and one for a third-party service). Each sending service will tell you what selector to use.

DKIM Best Practices

• Use a key size of at least 2048 bits. 1024-bit keys are still common but increasingly considered weak.
• Rotate your DKIM keys periodically (at least annually).
• Ensure every service that sends email on your behalf has its own DKIM signing configured.

DMARC: Tying It All Together

DMARC builds on SPF and DKIM by adding a policy layer and a reporting mechanism. It tells receiving servers what to do when SPF and DKIM checks fail, and it provides you with feedback about authentication results.

How DMARC Works

DMARC introduces the concept of alignment: the domain in the "From" header must match (align with) the domain used in SPF and/or DKIM checks. This prevents attackers from passing SPF with their own domain while spoofing yours in the visible "From" address.

A DMARC record is published as a TXT record at _dmarc.yourdomain.com:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; pct=100"

Key tags:

• v=DMARC1 – Version tag (required).
• p= – Policy for the domain. Options: none (monitor only), quarantine (send to spam), reject (block entirely).
• rua= – The email address where aggregate reports should be sent. These XML reports contain statistics about authentication results.
• pct= – The percentage of messages to which the policy applies. Useful for gradual rollout.
• sp= – Policy for subdomains (optional; defaults to the main policy).

Recommended DMARC Rollout Strategy

1. Start with p=none – This enables reporting without affecting mail delivery. Monitor the reports for 2–4 weeks to identify all legitimate sources of email for your domain.
2. Move to p=quarantine – Once you are confident all legitimate senders pass SPF and DKIM, start quarantining failures. Start with pct=10 and gradually increase.
3. Graduate to p=reject – The ultimate goal. This tells receiving servers to reject any email that fails DMARC. This is the strongest protection against phishing and spoofing.

Verifying Your Setup

After configuring SPF, DKIM, and DMARC, you need to verify everything is working correctly:

1. Use the SPF Record Test on GF.dev to validate your SPF syntax and check the DNS lookup count.
2. Use the DNS Lookup tool to query your DKIM and DMARC TXT records directly.
3. Send a test email to a Gmail or Outlook account and inspect the headers. Look for spf=pass, dkim=pass, and dmarc=pass in the Authentication-Results header.
4. Monitor your DMARC aggregate reports weekly for any failures from legitimate senders.

If your emails are still going to spam even after authentication, check whether your sending IP or domain is on any blacklists, and make sure your email content itself is not triggering spam filters.

Summary

Email authentication is not optional in today's internet. SPF declares who can send, DKIM proves the message is genuine, and DMARC ties them together with a policy and reporting. Together, these three protocols dramatically improve your email deliverability and protect your domain from being used in phishing attacks. Take ten minutes today to check your records with our SPF Record Test — your deliverability will thank you.