Why Your Emails Go to Spam: SPF, DKIM and DMARC Explained

When legitimate email lands in spam, the instinct is to blame the wording: too many exclamation marks, the word "free", a big image. Content does matter, but it is rarely the first thing a receiving server checks. Before Gmail or Outlook looks at a single word, it asks a simpler question: can this message prove it really comes from the domain in its From line? Three DNS records answer that question. When any of them is missing or broken, the answer is "no", and no amount of careful copywriting gets the message to the inbox.

The problem these records solve

The protocol that carries email, SMTP, dates from 1982 and has no built-in way to check who is sending. Any server can connect to any other and claim to be sending on behalf of any address, which is exactly how phishing works. SPF, DKIM and DMARC were added on top, over the following decades, to let a domain owner publish rules in DNS that receivers can check. Large mailbox providers now treat a message that fails those checks as suspect by default.

SPF: who is allowed to send

An SPF record is a TXT record at your domain listing the servers allowed to send its mail:

v=spf1 include:_spf.google.com include:sendgrid.net -all

That says mail for this domain comes from Google Workspace or SendGrid, and nothing else should be trusted (-all). The receiver checks the connecting server's IP address against the list. SPF goes wrong in a few predictable ways:

• Two SPF records. Adding a new service by creating a second v=spf1 record, instead of adding an include to the existing one, makes SPF fail for every message. A domain may have exactly one.
• Too many lookups. Each include, a and mx costs a DNS lookup, including the ones nested inside the services you include, and the total may not exceed ten. Pile on a CRM, a help desk and two newsletter tools and the record silently becomes invalid.
• A forgotten sender. Invoices from your billing system, alerts from your website, replies from your help desk: every service that sends as your domain needs to be in the record, or its mail fails.

SPF has one structural weakness: it checks the hidden envelope sender, not the From address people see, and it breaks when mail is forwarded, because the forwarding server is not on your list. That is why it cannot stand alone.

DKIM: a signature that travels with the message

DKIM has the sending server sign each message with a private key. The matching public key is published in DNS under a name called a selector, such as google._domainkey.example.com. The receiver reads the selector from the message's DKIM-Signature header, fetches the key and verifies that the signed headers and body have not changed. Because the signature is inside the message, it survives forwarding.

The usual failure is that DKIM was never switched on for your domain. Many email services sign everything with their own domain until you add their DNS records, and a signature from sendgrid.net proves nothing about example.com. Every sending service has a setup page that gives you the records to add; until you add them, your mail is unsigned as far as your domain is concerned.

DMARC: tying it to the address people see

DMARC closes the gap. It requires that a message pass SPF or DKIM and that the domain which passed matches the domain in the visible From line, which is called alignment. It also lets you tell receivers what to do with mail that fails, and where to send reports:

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

The policy p=none only monitors, p=quarantine sends failures to spam, and p=reject refuses them outright. Do not jump straight to reject. Start at none with a reporting address, read the reports for a few weeks to find every service sending as you, fix their SPF and DKIM, then tighten the policy step by step.

Since February 2024, Gmail and Yahoo have required bulk senders, those sending more than 5,000 messages a day to Gmail, to have SPF, DKIM and a DMARC record with at least p=none, with the From domain aligned, plus one-click unsubscribe on marketing mail. Smaller senders are held to the same standard in practice: missing authentication is one of the strongest spam signals there is.

Editing DNS without breaking something else

A domain's root can hold only one set of TXT records, and SPF shares it with verification strings for services like Google Search Console and Microsoft 365. Some DNS control panels replace the whole set when you edit one entry. Before saving a change to SPF, make sure every other TXT value at the root is still there, or you will fix your mail and quietly unverify something else.

When the records are right and mail still goes to spam

Authentication gets you considered; reputation gets you delivered. If everything passes and mail still lands in spam, look at who you are sending to and how. Messages to old or purchased lists bounce and draw complaints, which damage the domain's reputation for everyone else you mail. Sudden jumps in volume from a new domain look like a spammer warming up. Google's Postmaster Tools shows your spam complaint rate, which Google expects to stay below 0.3%. Content filters come last, and they matter most once the rest is clean.

Check yours in a minute

The Email Deliverability Checker looks up your SPF, DMARC, MX and common DKIM selectors and explains every problem in plain English. For a definitive answer on a particular message, send one to a Gmail address, open it, and choose Show original from the message menu. Gmail lists the SPF, DKIM and DMARC result for that exact message at the top. All three should say PASS.