Anyone can send an email that says it is from
ceo@yourcompany.com. Without SPF, DKIM, and DMARC, there is nothing stopping them.
How Email Spoofing Works
SMTP — the protocol email runs on — has no built-in authentication. The "From" header is just a string. An attacker can send an email claiming to be from any address:
import smtplib
from email.mime.text import MIMEText
msg = MIMEText("Please wire $50,000 to this account immediately.")
msg["From"] = "ceo@yourcompany.com" # completely forged
msg["To"] = "accountant@yourcompany.com"
msg["Subject"] = "Urgent: Wire Transfer Needed"
smtp = smtplib.SMTP("attacker-smtp-server.com")
smtp.send_message(msg)Without email authentication, the receiving mail server has no way to verify that this email actually came from yourcompany.com. This is what makes phishing so effective.
The Three Layers of Email Authentication
SPF, DKIM, and DMARC work together. You need all three.
SPF (Sender Policy Framework)
SPF tells receiving mail servers which IP addresses are allowed to send email on behalf of your domain. It is a DNS TXT record.
yourcompany.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"This record says: only Google Workspace and SendGrid can send email from @yourcompany.com. The -all at the end means "reject everything else."
SPF mechanisms:
| Mechanism | Meaning |
|---|---|
-all | Hard fail — reject unauthorized senders |
~all | Soft fail — mark as suspicious but deliver |
?all | Neutral — do nothing (useless) |
include: | Authorize another domain's SPF |
ip4: | Authorize a specific IP |
Do this: Always use -all (hard fail). Using ~all is half-measures that still let spoofed emails through.
DKIM (DomainKeys Identified Mail)
DKIM adds a cryptographic signature to outgoing emails. The sending server signs the email with a private key, and the receiving server verifies the signature using a public key published in DNS.
selector1._domainkey.yourcompany.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."When a mail server receives an email claiming to be from your domain, it:
- Extracts the DKIM selector from the email header
- Looks up the public key at
selector._domainkey.yourcompany.com - Verifies the signature against the email body and headers
If the signature does not match, the email was tampered with or forged.
Key point: DKIM survives forwarding, unlike SPF. If someone forwards your email, the DKIM signature remains valid because the email content has not changed.
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
DMARC ties SPF and DKIM together and tells receiving servers what to do when authentication fails. It also provides reporting so you can see who is sending email as your domain.
_dmarc.yourcompany.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourcompany.com; pct=100"DMARC policies:
| Policy | Meaning |
|---|---|
p=none | Monitor only — deliver everything, send reports |
p=quarantine | Send failing emails to spam |
p=reject | Drop failing emails entirely |
Implementation Order
Do not jump straight to p=reject. Roll out gradually:
- Week 1-2: Set
p=noneand configureruareporting to see who sends email as your domain - Week 3-4: Review reports — identify legitimate senders you missed in SPF
- Week 5-6: Move to
p=quarantine— spoofed emails go to spam - Week 7+: Move to
p=reject— spoofed emails are dropped
# Phase 1: Monitor
_dmarc.yourcompany.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com"
# Phase 2: Quarantine
_dmarc.yourcompany.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com; pct=100"
# Phase 3: Reject
_dmarc.yourcompany.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com; pct=100"Verifying Your Configuration
Use dig to check your records:
# Check SPF
dig TXT yourcompany.com +short
# Check DKIM (replace 'selector1' with your actual selector)
dig TXT selector1._domainkey.yourcompany.com +short
# Check DMARC
dig TXT _dmarc.yourcompany.com +shortCommon Mistakes
Forgetting third-party senders
Marketing tools (Mailchimp, SendGrid), CRM systems, and ticketing platforms all send email on your behalf. If they are not in your SPF record, legitimate emails will fail authentication.
Too many DNS lookups in SPF
SPF has a 10 DNS lookup limit. Each include: counts as a lookup. If you exceed 10, SPF breaks silently. Use tools like dmarcian or mxtoolbox to check your lookup count.
Not monitoring DMARC reports
Setting p=none without reading the reports is pointless. Use a DMARC report analyzer (Postmark, Valimail, dmarcian) to parse the XML reports into readable dashboards.
Subdomains without DMARC
By default, DMARC only applies to the exact domain. Attackers can spoof hr.yourcompany.com if you do not add a subdomain policy:
_dmarc.yourcompany.com. IN TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourcompany.com"The sp=reject applies the same policy to all subdomains.
Beyond Email Authentication
SPF, DKIM, and DMARC prevent domain spoofing, but they do not stop all phishing. Attackers can register lookalike domains (yourcompaany.com) or use compromised legitimate accounts. Additional defenses include:
- BIMI — Brand Indicators for Message Identification, displays your logo next to authenticated emails
- Security awareness training — teach your team to verify unusual requests through a second channel
- Link protection — tools that scan URLs in emails before delivery
Conclusion
If you own a domain and send email from it, you need SPF, DKIM, and DMARC. Without them, anyone can impersonate your organization. Start with p=none, monitor your reports, and work your way up to p=reject. It takes a few weeks of DNS changes — not months of engineering.
Related posts
Secure Password Reset Tokens — Expiry, Storage, and What Most Implementations Get Wrong
A practical guide to building secure password reset flows: token generation, expiry windows, one-time use enforcement, and the edge cases that cause real account takeovers.
Mar 30, 2026 · 7 min readIncident Response for Developers: What to Do When You Get Hacked
A practical incident response guide for developers covering detection, containment, eradication, recovery, and communication when a security breach happens.
Mar 29, 2026 · 9 min readLinux Privilege Escalation: How Attackers Go from User to Root
A practical guide to Linux privilege escalation techniques — SUID binaries, sudo misconfigurations, cron jobs, kernel exploits, and how to defend against them.
Mar 29, 2026 · 10 min read