SPF, DKIM, and DMARC, explained without the jargon

All three are DNS records — text entries attached to your domain, not settings inside your email client — that tell receiving mail servers whether an email claiming to be from your domain is legitimate. None of them affect what your email says; all three affect whether it’s believed.

SPF: who’s allowed to send

Sender Policy Framework lists which mail servers are authorized to send on your domain’s behalf — your own mail provider, plus any tool you’ve connected (a CRM, a sending platform). A receiving server checks the sending IP against this list; mail from an unlisted server looks forged, whether it actually is or not.

DKIM: a signature that proves nothing changed

DomainKeys Identified Mail attaches a cryptographic signature to each outgoing message, generated with a private key only your sending server holds. The receiving server checks it against a public key published in your DNS. If the message was altered in transit — or never actually came from your server — the signature won’t match.

DMARC: what to do when the first two disagree

Domain-based Message Authentication tells receivers what to do if SPF or DKIM fails: let it through anyway (none), quarantine it (usually spam), or reject it outright. It also tells receivers where to send aggregate reports about who’s sending mail claiming to be from your domain — including anyone spoofing it.

Why one missing record hurts everything

Gmail and Outlook both weigh authentication heavily when deciding inbox versus spam versus nowhere. Missing any one of the three makes your outbound mail look more suspect to them — regardless of how clean and verified your recipient list is. Deliverability is the product of both: authentication gets the message considered, list quality (see verifying before you send) keeps your domain’s reputation intact so the next message gets considered too.