Why your emails go to spam: SPF, DKIM and DMARC, in order

Read the verdict in the message headers

Every mailbox provider that receives an email checks where it came from and records the result in the message headers. To read it, send an email from your business address to a Gmail address, open it, click More (the three dots) and then Show original. Look for the Authentication-Results line:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@your-domain.com header.s=google;
       spf=pass (google.com: domain of hello@your-domain.com designates 203.0.113.25 as permitted sender) smtp.mailfrom=hello@your-domain.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=your-domain.com

These three settings are unevenly spread. Among the 1,730 SMB domains that receive mail in our monthly survey, 96% publish SPF, and 71% have no DMARC policy that acts on the result.

1. SPF: the list of authorised servers

SPF is a TXT record at the root of your domain. It starts with v=spf1, names the servers allowed to send for the domain, and ends with what to make of every other server. The two most common email providers publish the value to use:

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

v=spf1 include:spf.protection.outlook.com -all

Every other service sending with your domain goes into that same record: newsletter tool, invoicing software, CRM, and your website server if its forms send mail themselves. Each service documents the include: to add; a server is declared by its address, with ip4::

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

• One SPF record per domain. Two records starting with v=spf1 make SPF invalid (permerror): merge them into one.
• Ten DNS lookups at most. Every include, a, mx, ptr, exists and redirect counts, including the ones nested inside your includes. Past ten, SPF is invalid. ip4 and ip6 do not count.
• How the record ends. -all declares every other server unauthorised, ~all flags it without calling it illegitimate. Google suggests ~all in its documentation, Microsoft suggests -all. Once DMARC is in place, its policy decides what happens to a message that fails.

2. DKIM: a signature on every message

DKIM adds a signature to every message, which the recipient’s provider checks against a public key published in your DNS, under a name shaped like selector._domainkey.your-domain.com. The signing happens at the service that sends; your part is to publish the key it gives you.

• Google Workspace: in the Admin console, Menu > Apps > Google Workspace > Gmail > Authenticate email, then "Generate new record". The default selector is google and Google recommends a 2048-bit key. Publish the google._domainkey TXT record, then come back and click "Start authentication".
• Microsoft 365: in the Microsoft Defender portal, under Email & collaboration > Policies & rules > Threat policies > Email authentication settings, DKIM tab (https://security.microsoft.com/authentication?viewid=DKIM). DKIM there relies on two CNAME records, selector1._domainkey and selector2._domainkey, whose exact values the portal shows for your domain: copy them as they are, then turn signing on.
• Other services (newsletters, invoicing, CRM) each have a domain authentication page that gives their own DKIM records.

Gmail accepts keys of 1024 bits and up; 2048 bits is the length the standard recommends. Allow up to 48 hours for a newly published key to be visible everywhere.

3. DMARC: the instruction you give mailbox providers

DMARC ties SPF and DKIM to the address the recipient sees, the one in the From field. A message passes DMARC when SPF or DKIM is valid for the domain of that address: that is alignment. The record also says what to do with a message that fails, and where to send reports.

v=DMARC1; p=none; rua=mailto:dmarc@your-domain.com

1. Publish p=none with a rua address. The large providers send a daily aggregate report there, a compressed XML file listing the servers that sent with your domain and how they fared.
2. Read the reports for two to four weeks. Each legitimate source that fails (a forgotten newsletter tool, the invoicing software) gets fixed in SPF or DKIM.
3. Move to p=quarantine, then, after a few weeks without lost mail, to p=reject. If your team posts to mailing lists, stay at quarantine: the standard advises against reject for such domains, because lists modify the messages they redistribute.

Older guides suggest ramping up with the pct tag. The current DMARC standard, RFC 9989, published in May 2026, no longer recognises it: you ramp up through the policy itself.

The contact form trap

Many website forms send the message with the visitor’s address as the sender. The website server has no authority over the visitor’s domain, so SPF and DKIM cannot align and DMARC fails. When the visitor’s provider publishes a strict policy (yahoo.com publishes p=reject), the message is refused or filed as spam before it reaches you.

• From: an address on your own domain, for example form@your-domain.com.
• Reply-To: the visitor’s address, so that hitting Reply writes straight back to them.
• Sending: through an authenticated SMTP account on your email service, covered by SPF and signed with DKIM, rather than through the server’s default mail function.

When everything passes and mail still lands in spam

• Blocklists: Spamhaus’s free checker, https://check.spamhaus.org/, looks up an IP address or a domain.
• Reverse DNS: Gmail asks every sender to use a sending server whose IP address has a valid reverse (PTR) name that points back to that same address. An email provider handles this for you; on a server you run yourself, check it.
• Bulk sending: above roughly 5,000 messages a day to Gmail addresses, Google requires SPF and DKIM, DMARC at p=none or stricter, alignment, one-click unsubscribe and a reported spam rate under 0.3%. Since November 2025, Gmail rejects part of the traffic that misses these rules. Yahoo applies similar requirements without publishing a threshold, and since 5 May 2025 Outlook.com has rejected mail from domains sending more than 5,000 messages a day without SPF, DKIM and DMARC.
• Google Postmaster Tools (postmaster.google.com) shows your domain reputation and spam rate at Gmail once the domain is verified with a DNS record. The dashboards fill in once your sending volume is high enough.