DNS, SPF, DKIM, DMARC: Why Your Email Goes to Spam (and How Attackers Impersonate You) Everything you need to know about the three protocols that separate your legitimate email from the spam folder — and that separate your brand from being used by scammers. Introduction You send an important email to a client.
DNS, SPF, DKIM, DMARC: Why Your Email Goes to Spam (and How Attackers Impersonate You) Everything you need to know about the three protocols that separate your legitimate email from the spam folder — and that separate your brand from being used by scammers. Introduction You send an important email to a client. They reply two days later: "sorry, it went to spam". You send another to a lead, and it simply never arrives. And meanwhile, someone on the internet is sending email impersonating your company , asking your clients for transfers, and you only find out when the client calls to complain. Welcome to the world of email authentication. A place where three acronyms — SPF , DKIM and DMARC — decide whether you exist digitally or not. The good news is that these three protocols solve 95% of deliverability and spoofing problems. The bad news is that the absolute majority of domains on the internet don't have even one of them configured correctly . And since February 2024, Google and Yahoo started requiring DMARC for senders who send more than 5,000 emails per day. Part 1: The fundamental problem with email The email protocol (SMTP) was created in 1982 and had no authentication mechanism . Literally none. Any server can send an email claiming to be from any address. For decades this worked because the internet was small. Spam came, phishing came, organized fraud came. The solution wasn't to rewrite SMTP — it was to add authentication layers on top, using DNS: SPF (2006) — which servers can send email on behalf of your domain DKIM (2007) — cryptographically signs each email sent DMARC (2012) — says what to do when SPF and DKIM fail, and gives you reports The three work together. Alone, they have holes. Combined, they form reasonable defense. Email authentication is not "optional security". It's basic infrastructure. Without it: legitimate emails go to spam, attackers can impersonate you, and Google/Yahoo simply reject much of the traffic from those who don't authenticate. Part 2: SPF — Sender Policy Framework 2.1 What it is You publish in DNS a list of servers authorized to send email on behalf of your domain. The destination server consults that list and verifies that the source IP is authorized. 2.2 How to configure A single TXT record: Breaking it down: v=spf1 — version ip4:200.150.100.10 — authorizes this IP include: spf.google.com — authorizes Google Workspace IPs -all — any other IP is rejected Common mechanisms: Mechanism What it does ip4:1.2.3.4 Specific IP ip4:1.2.3.0/24 IP range a A record IP mx MX IPs include:domain.com Includes SPF from another domain redirect=other.com Replaces with SPF from another Qualifiers: Syntax Meaning +all Accept everything (NEVER use) -all Reject everything not in the list all SoftFail — accept but mark ?all Neutral (equivalent to not having SPF) 2.3 Real examples Google Workspace only: Microsoft 365 only: Hybrid (M365 + own server + marketing + transactional): 2.4 SPF's limitations 10 DNS lookup limit. Each include, a, mx, exists counts. Exceeded it? SPF breaks with permerror and for many servers that's equivalent to failing. The limit is recursive — if you include Google's SPF, and Google includes others, they all count. Breaks with forwarding. Forwarded email comes from a server that's not in your SPF. Fails. Doesn't protect the visible "From:". SPF verifies the MAIL FROM (envelope), not the From: that appears to the user. Attacker can pass SPF perfectly and show From: ceo@yourcompany.com.br. No encryption. Only checks IP. Compromised authorized server? Attacker sends whatever they want. 2.5 Verify SPF 2.6 Common errors +all or ?all — nullifies protection Multiple SPF records on the same domain (can only have one) Wrong syntax (spaces, quotes, order) Forgetting to include new service Exceeding 10 lookups include pointing to nonexistent domain Part 3: DKIM — DomainKeys Identified Mail 3.1 What it is Cryptographic digital signature on each email sent. You generate a key pair (private + public) Public key goes in DNS Private key stays on the email server Server signs each email sent Destination server fetches the public key and verifies mathematically Guarantees authenticity (it really came from the key owner) and integrity (it wasn't altered in transit). 3.2 How a DKIM record works default. domainkey.empresa.com.br — format [selector]. domainkey.[domain] v=DKIM1 — version k=rsa — algorithm p=... — public key in Base64 The selector allows you to have multiple DKIM keys active simultaneously. Each service uses its own selector. 3.3 How to configure Google Workspace: Admin Console → Apps → Gmail → Authenticate email → Generate. Publish the record it gives you. Microsoft 365: Defender → Email & collaboration → Threat policies → DKIM → enable (uses CNAMEs). Mailgun, SendGrid, Mailchimp, Amazon SES: all have wizards. Own server (Postfix with OpenDKIM): 3.4 How DKIM signs DKIM-Signature header added to each email: d= — domain that signed s= — selector h= — signed headers bh= — bod…