EncryptCodecencryptcodec
Blog/Security
SecurityMarch 29, 2026 · 9 min read

Phishing Prevention: A Developer's Guide to SPF, DKIM, and DMARC

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:

MechanismMeaning
-allHard fail — reject unauthorized senders
~allSoft fail — mark as suspicious but deliver
?allNeutral — 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:

  1. Extracts the DKIM selector from the email header
  2. Looks up the public key at selector._domainkey.yourcompany.com
  3. 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:

PolicyMeaning
p=noneMonitor only — deliver everything, send reports
p=quarantineSend failing emails to spam
p=rejectDrop failing emails entirely

Implementation Order

Do not jump straight to p=reject. Roll out gradually:

  1. Week 1-2: Set p=none and configure rua reporting to see who sends email as your domain
  2. Week 3-4: Review reports — identify legitimate senders you missed in SPF
  3. Week 5-6: Move to p=quarantine — spoofed emails go to spam
  4. 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 +short

Common 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.

Share this post

Try the Phishing Builder Simulation

Related posts