SPF, DKIM and DMARC explained: why your emails go to spam

When SMTP was designed in the early 1980s, nothing checked whether a sender was who they claimed to be. Anyone could put any address in the From: line, and technically they still can. SPF, DKIM and DMARC are three layers added later to close that gap. All three live in your domain’s DNS, so you set them up once at your DNS host (Cloudflare, GoDaddy, Namecheap, your registrar) rather than in your mail client.

Why do emails go to spam?

For every incoming message, the receiving server (Gmail, Outlook, Yahoo, iCloud) asks roughly three questions:

1. Is the server that sent this allowed to send for this domain? (SPF)
2. Was the message signed by the domain and left unchanged in transit? (DKIM)
3. What does the domain owner want done if those checks fail? (DMARC)

If the answer is “unknown” or “no”, the message is far more likely to land in spam or be rejected outright. Mail sent by third-party services suffers first: website contact forms, Shopify or WooCommerce order notifications, Mailchimp newsletters, CRM sequences. Your main mailbox may work fine while those quietly fail.

Content and reputation still matter (spammy wording, purchased lists, high complaint rates), but without authentication even a perfect message starts at a disadvantage.

The 2024 sender rules from Google, Yahoo and Microsoft

Since February 2024, Google and Yahoo have required bulk senders (roughly 5,000+ messages a day to their users) to:

• authenticate with SPF and DKIM,
• publish a DMARC record (at least p=none) and pass DMARC alignment,
• offer one-click unsubscribe for marketing mail and honour it within two days,
• keep the user-reported spam rate below 0.3% (Google recommends staying under 0.1%).

Microsoft applied similar rules to Outlook.com, Hotmail and Live.com addresses from May 2025. Even if you send far less, these rules are the de facto standard: smaller senders are expected to have at least SPF or DKIM, and having all three is simply good practice.

SPF: who may send for your domain?

SPF (Sender Policy Framework) is a list of servers allowed to send email for your domain. It is a single TXT record on the root of the domain:

example.com.  TXT  "v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all"

• v=spf1 marks the record as SPF.
• include: pulls in another provider’s list (Google Workspace, Microsoft 365, Mailchimp, SendGrid, Brevo…).
• ip4: / ip6: authorise a specific address, e.g. your web server.
• ~all at the end means “anything else is suspicious” (softfail); -all means “reject anything else” (fail).

Common SPF mistakes:

The 10-lookup limit comes from the SPF standard (RFC 7208) and catches many growing companies: each include, a, mx and redirect counts, including nested ones.

DKIM: was the message altered?

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each outgoing message using a private key held by your mail provider. The receiver fetches the matching public key from DNS to verify it. The key is published under a selector:

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

You don’t generate the key yourself. Turn DKIM on in your provider’s admin panel and copy the record it gives you:

• Google Workspace: Admin console → Apps → Google Workspace → Gmail → Authenticate email.
• Microsoft 365: Microsoft Defender portal → Email authentication settings → DKIM (usually two CNAME records, selector1 and selector2).
• Newsletter and transactional tools (Mailchimp, SendGrid, Postmark, Brevo) have a “domain authentication” page with their own records.

Each service uses its own selector, so having several DKIM records is normal. Use 2048-bit keys where offered.

DMARC: what happens when checks fail?

DMARC ties SPF and DKIM together. It tells receivers what to do with mail that fails, and it asks them to send you aggregate reports showing who is sending as your domain. It is a TXT record on the _dmarc subdomain:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

The crucial concept is alignment: DMARC passes only if SPF or DKIM passes and the domain it authenticated matches the domain in the visible From: address. A newsletter tool that signs with its own domain (say sendgrid.net) passes DKIM but fails DMARC alignment until you set up custom domain authentication.

Aggregate reports arrive as XML files. They are hard to read raw, so most people use a free DMARC report viewer or a dedicated mailbox they check weekly.

Step-by-step setup

1. Check where you stand. Enter your domain in our SPF and DMARC checker to see which records exist and which are broken.
2. List every service that sends as your domain: mailbox provider, web server (contact forms), newsletter platform, e-commerce, CRM, helpdesk, invoicing software.
3. Build one SPF record that includes all of them and stays under 10 lookups.
4. Enable DKIM for each service and publish the records they give you.
5. Publish DMARC with p=none and a reporting address. Watch the reports for two to four weeks.
6. Tighten the policy: p=quarantine, then p=reject. You can phase in with pct= if you want to be cautious.
7. Verify propagation. Use the DNS lookup tool to confirm the TXT records are live from public resolvers.

Troubleshooting tips

• Forwarded mail fails SPF. That is expected, because the forwarding server isn’t in your list. DKIM usually survives forwarding, which is why you want both.
• Mailing lists break DKIM when they edit the subject or footer. Modern lists rewrite the From: address to cope with DMARC.
• “Sent via” or “on behalf of” warnings in Gmail or Outlook usually mean DKIM is signed by the provider’s domain, not yours.
• Website form mail goes to spam. Send through an authenticated SMTP account on your own domain instead of PHP mail().

If you are unsure who controls the DNS for a domain, a WHOIS lookup shows the registrar and nameservers. For background on TXT, MX and other record types, see our guide to DNS records.

Checklist

• Exactly one v=spf1 record, under 10 DNS lookups, ending in ~all or -all.
• DKIM enabled for every service that sends as your domain.
• A _dmarc record exists with at least p=none and a working rua address.
• Marketing email has one-click unsubscribe and spam complaints stay well below 0.3%.
• Website forms send through authenticated SMTP, not an unauthenticated web server.
• You know who manages the domain’s DNS and when the domain renews.