SPF vs DKIM vs DMARC, Explained in Plain English

SPF, DKIM and DMARC are three DNS records that let Gmail, Outlook and Yahoo confirm an email really came from your domain. Since 2024, Google and Yahoo have required them from bulk senders, and Gmail requires at least SPF or DKIM from everyone. If they're missing or broken, your email can be filtered to spam or refused.

The short version:

None of them is enough alone. Here's how each one works, and how they fit together.

SPF: the list of who may send for you

SPF (Sender Policy Framework, RFC 7208) is a list of the servers and services allowed to send email using your domain. When a message arrives, the receiving server checks whether the server that sent it is on your list.

A typical SPF record for a company on Google Workspace that also sends from a CRM looks like this:

v=spf1 include:_spf.google.com include:servers.example-crm.com ~all

v=spf1 marks it as SPF. Each include: authorizes a service. The ending sets what happens to everything else: ~all (softfail) says "probably not us," and -all (fail) says "definitely not us."

The rules people trip over:

• One SPF record per domain. Two records starting with v=spf1 is an error, so receivers treat SPF as broken. When you add a new tool, merge it into the existing record instead of adding another.
• The 10-lookup limit. RFC 7208 caps the number of DNS lookups SPF can trigger at 10. Every include: counts, and so do the includes nested inside it. Go over and SPF fails with a permanent error, even though the record looks fine.
• SPF checks the envelope sender, not the From address you see. Many sending tools use their own domain for the envelope (the "Return-Path"). SPF can pass for their domain while doing nothing for yours. This is why alignment, below, matters.
• SPF breaks when mail is forwarded, because the forwarding server isn't on your list.

DKIM: a signature that proves the message is genuine

DKIM (DomainKeys Identified Mail, RFC 6376) adds a digital signature to every message. Your email provider signs each message with a private key, and publishes the matching public key in your DNS. The receiving server uses the public key to confirm two things: the domain in the signature (the d= value) signed the message, and the signed parts weren't changed along the way.

The public key lives at a "selector" under your domain, for example:

google._domainkey.yourcompany.com   TXT   v=DKIM1; k=rsa; p=MIIBIjANBgkq...

What to know:

• Each sending service needs its own DKIM setup. Google Workspace, Microsoft 365, your CRM and your cold email tool each give you their own record, and you have to switch signing on in each one.
• Sign with your own domain. If a tool signs with its own domain instead of yours, DKIM passes but doesn't align with your From address. Look for a "custom domain" or "authenticate your domain" setting.
• Key length. Gmail requires DKIM keys of at least 1024 bits for personal Gmail accounts, and recommends 2048 bits where your provider supports it.
• DKIM usually survives forwarding, as long as the message isn't modified. That makes it the more reliable of the two checks.

DMARC: the policy and the reporting

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) ties the other two together. It does three jobs:

1. Requires alignment. For DMARC to pass, a message must pass SPF or DKIM, and the domain that passed must match the domain in the visible From address. This is what stops someone passing SPF on their own domain while pretending to be you.
2. Sets a policy for mail that fails: p=none (just monitor), p=quarantine (send to spam) or p=reject (refuse it).
3. Sends reports. The rua address receives daily aggregate reports from inbox providers, showing every server that sent mail claiming to be your domain, and whether it passed.

A safe starting record:

_dmarc.yourcompany.com   TXT   v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com

Alignment is "relaxed" by default, so mail.yourcompany.com aligns with yourcompany.com. You can make it strict with adkim=s and aspf=s, but most companies don't need to.

How they work together

Imagine your CRM sends a newsletter as hello@yourcompany.com:

• SPF checks whether the CRM's sending server is listed for the envelope domain. If the CRM uses its own envelope domain, SPF passes for them, not for you.
• DKIM checks the signature. If you set up the CRM to sign as yourcompany.com, DKIM passes and aligns.
• DMARC sees an aligned DKIM pass and passes the message, even though SPF didn't align.

That's the key point: DMARC needs only one aligned pass. In practice, aligned DKIM on every service is the most robust setup, with SPF as the backup.

Now imagine a scammer sends as billing@yourcompany.com from their own server. SPF fails (their server isn't listed), DKIM fails (they don't have your key), and DMARC fails. What happens next depends on your policy: with p=none the message is judged on other signals and may still reach the inbox, while with p=reject it's refused.

What Gmail, Yahoo and Outlook require

• Gmail, all senders: SPF or DKIM, valid forward and reverse DNS for sending IPs, TLS, and a spam rate below 0.3% in Postmaster Tools.
• Gmail, senders of more than 5,000 messages a day to Gmail accounts: SPF and DKIM, a DMARC record (p=none is enough), From alignment with SPF or DKIM, and one-click unsubscribe for marketing and subscribed messages.
• Yahoo, bulk senders: SPF and DKIM, a DMARC policy of at least p=none that passes, alignment, one-click unsubscribe honored within 2 days, and a spam rate below 0.3%.
• Outlook.com, high-volume senders: SPF, DKIM and DMARC of at least p=none, aligned, since May 2025.

Even if you send far less than 5,000 a day, meeting the bulk-sender rules is the safest baseline.

How to set them up without blocking your own email

The order matters, especially for DMARC:

1. List every service that sends email as your domain. Your email provider, CRM, help desk, invoicing, newsletter, website forms and any cold email tool. People usually forget one or two.
2. Fix SPF. One record, every legitimate sender included, under 10 lookups.
3. Turn on DKIM in every service, signing as your own domain.
4. Publish DMARC at p=none with a rua address. Read the reports for a few weeks. They'll show services you forgot and anyone spoofing you.
5. Fix each sender the reports show failing.
6. Move to p=quarantine, then p=reject once your real mail passes consistently.

Jumping straight to p=reject is the classic mistake: if one real service isn't set up yet, you block your own invoices or password resets. That's why our Domain fix runs over 30 to 45 days, paced by the reports.

Check yours

The quickest way to see where you stand is our free email health check, or the DMARC checker if DMARC is your main question. Both read your public DNS records and tell you in plain English what's missing, with the exact record to add. If Gmail has already bounced you, our guide to the 550 5.7.26 error explains each version of that message.