SPF, DKIM and DMARC Explained: Set Them Up and Fix a Failed Check

SPF, DKIM and DMARC are three DNS records that tell receiving mail servers whether a message really came from your domain. If one is missing or broken, Gmail, Yahoo and Outlook have less reason to trust your mail, and it is more likely to land in spam or be rejected. This guide explains each record, shows working examples, and walks through the failures that cause most "failed check" warnings.

What each record does

• SPF (Sender Policy Framework, RFC 7208) is a TXT record at your domain that lists the servers allowed to send mail for it.
• DKIM (DomainKeys Identified Mail, RFC 6376) adds a cryptographic signature to each message, and receivers check it against a public key you publish in DNS.
• DMARC (RFC 7489) is a policy at _dmarc.yourdomain that tells receivers what to do when mail fails SPF and DKIM alignment, and where to send reports.

SPF and DKIM prove a message is authorized. DMARC connects those results to the From address people actually see.

Set up SPF

An SPF record is a single TXT record at the root of your domain. It starts with v=spf1, lists your senders, and ends with an all mechanism.

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all"

• include: pulls in the SPF record of a service that sends for you, such as your mailbox provider or newsletter tool. Use the exact value from each provider's setup page.
• ip4: and ip6: authorize your own server addresses.
• ~all (softfail) asks receivers to treat other senders as suspicious. -all (fail) says other senders are not authorized at all.

Start with ~all while you confirm every sender is listed. Move to -all once you are sure nothing legitimate is missing.

Set up DKIM

DKIM keys are generated by whoever sends your mail. Google Workspace, Microsoft 365, Mailchimp and similar services each give you a record to publish. The record lives under a selector, a label that lets one domain publish several keys:

selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"

The name follows the pattern RFC 6376 defines: <selector>._domainkey.<domain>. The p= tag holds the public key. Some providers ask for a CNAME instead of a TXT record so they can rotate keys for you. Either way, every service that sends as your domain needs its own DKIM setup. Google's guidelines ask for keys of at least 1024 bits and recommend 2048 where your provider supports it.

To find your selector, open a message you sent, view the full headers, and look for s= in the DKIM-Signature header.

Set up DMARC

DMARC is a TXT record at _dmarc.yourdomain. Roll it out in three stages.

Stage 1: monitor.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

p=none changes nothing about delivery. The rua tag sets where receivers send aggregate reports. These are XML files that show which servers sent mail as your domain and whether each passed SPF and DKIM.

Stage 2: quarantine.

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

Mail that fails DMARC goes to spam. Move here once the reports show your real senders passing.

Stage 3: reject.

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

Receivers refuse mail that fails. This is the setting that stops others from sending mail as your domain.

Check what you published

The DMARC / SPF checker runs three TXT lookups at once: your domain for SPF, _dmarc.yourdomain for DMARC, and selector._domainkey.yourdomain for DKIM. Type your selector into the DKIM box, since it starts as "default". For each record it shows whether it was found and prints the full text, so you can read the tags yourself. It does not score or validate the record, count SPF lookups, or expand includes, so use the checklist below to review what it returns.

If you need another record type, such as the MX records that show who receives your mail, or a DKIM CNAME, use the DNS lookup tool. It supports A, AAAA, MX, TXT, NS, CNAME and SOA.

Common failures and how to fix them

Two SPF records

A domain must have exactly one SPF record. RFC 7208 says that if more than one is found, the result is a permanent error (permerror), and SPF fails for every message. This often happens when a new service tells you to "add an SPF record" and you add a second one. Merge them instead:

Wrong:
example.com.  TXT  "v=spf1 include:_spf.google.com ~all"
example.com.  TXT  "v=spf1 include:sendgrid.net ~all"

Right:
example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

If the checker lists two records under SPF, this is your problem.

More than 10 DNS lookups

RFC 7208 limits SPF evaluation to 10 terms that cause DNS queries: include, a, mx, ptr, exists and redirect. Go over and the result is permerror. Includes count too, along with the includes inside them, so three or four services can pass the limit. ip4, ip6 and all do not count. To fix it, remove services you no longer use, replace a and mx with ip4 addresses where you can, and drop ptr, which the RFC says should not be used.

Missing DKIM for a sending service

Your mailbox may sign with DKIM while your invoicing tool, CRM or newsletter platform does not. Each of these needs its own DKIM record under its own selector. Check each selector separately in the checker. A "not found" for the default selector usually means you need a different selector, not that DKIM is missing.

DMARC alignment failing

DMARC passes only when SPF or DKIM passes and the domain it checked matches the From address. SPF checks the envelope sender (the Return-Path), not the From header. If your email platform uses its own bounce domain, SPF can pass for that domain and still fail alignment for yours. The usual fix is to set up DKIM for that service with your own domain (d=example.com), or a custom return-path on a subdomain of yours. By default, alignment is relaxed, so mail.example.com aligns with example.com.

p=none forever

p=none is a monitoring setting. It is a valid first step, but it does not protect your domain from spoofing. Read your aggregate reports, fix any sender that fails, then move to quarantine and reject.

What Gmail and Yahoo require

Google and Yahoo introduced new sender requirements in 2024. Google's took effect on February 1, 2024.

All senders to Gmail must set up SPF or DKIM for their sending domains. Yahoo asks all senders to implement SPF or DKIM at a minimum. Both also ask senders to keep spam rates below 0.3%.

Bulk senders have stricter rules. Google applies them to senders of more than 5,000 messages a day to Gmail accounts. Yahoo does not give a number. Bulk senders must:

• Set up SPF and DKIM, plus DMARC. A policy of p=none meets the minimum for both providers.
• Align the From domain with either the SPF domain or the DKIM domain.
• Support one-click unsubscribe in marketing and subscribed messages. Google also requires a visible unsubscribe link in the body. Yahoo recommends the RFC 8058 POST method and says to honor unsubscribes within 2 days.

Read the Google email sender guidelines and Yahoo Sender Best Practices for the full lists.

When the records are right but mail still goes to spam

Authentication is one signal among several. If SPF, DKIM and DMARC all pass and mail still lands in spam, check whether your sending IP is on a public blocklist. The blacklist checker tests an IP address against Spamhaus ZEN, SpamCop, Barracuda and SORBS. Enter the IP of your mail server. If you enter a domain, it checks the domain's A record, which is often your website's server rather than the one that sends your mail.

Once everything passes, run the DMARC / SPF checker again after any DNS change. A second SPF record or a removed DKIM key is easy to add by accident and hard to notice until mail starts failing.