The Email Authentication Problem
Email was designed in an era of trust. The original SMTP protocol has no built-in mechanism to verify that an email actually came from the sender it claims. This makes email spoofing — forging the "From" address — trivially easy.
Three complementary protocols were developed to solve this problem: SPF, DKIM, and DMARC. Together, they form a robust email authentication framework. Let's understand each one.
SPF (Sender Policy Framework)
SPF tells the world which mail servers are authorized to send email on behalf of your domain. It works by publishing a TXT record in your domain's DNS.
How SPF Works
- You publish an SPF record listing your authorized mail servers.
- When a receiving server gets an email claiming to be from your domain, it checks your SPF record.
- If the sending server's IP matches your SPF record, the check passes.
Setting Up SPF
Add a TXT record to your domain's DNS:
v=spf1 include:_spf.google.com include:sendgrid.net -all
Breaking this down:
v=spf1— Identifies this as an SPF recordinclude:— Authorizes the specified domain's mail servers-all— Reject mail from all other sources (hard fail)
Critical: Always end with -all (hard fail), not ~all (soft fail). Soft fail is often too permissive and may allow spoofed emails through.
DKIM (DomainKeys Identified Mail)
DKIM adds a cryptographic signature to every email you send. This proves the email hasn't been tampered with in transit and that it genuinely came from your domain.
How DKIM Works
- Your mail server signs outgoing emails with a private key.
- You publish the corresponding public key as a DNS TXT record.
- Receiving servers use your public key to verify the signature.
Setting Up DKIM
DKIM setup varies by email provider. For Google Workspace:
- Go to Admin Console → Apps → Google Workspace → Gmail → Authenticate Email.
- Generate the DKIM key (Google provides a TXT record value).
- Add the TXT record to your DNS at
google._domainkey.yourdomain.com. - Enable DKIM signing in the admin console.
The DNS record will look something like:
google._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4..."
DMARC (Domain-based Message Authentication, Reporting & Conformance)
DMARC ties SPF and DKIM together and tells receiving servers what to do when authentication fails. It also provides reporting so you can monitor who's sending email as your domain.
How DMARC Works
- A receiving server performs SPF and DKIM checks.
- It then checks your DMARC record to learn your policy.
- Based on the policy, it either delivers, quarantines, or rejects the email.
- It sends aggregate reports to the email address specified in your DMARC record.
Setting Up DMARC
Add a TXT record at _dmarc.yourdomain.com:
v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100
Breaking this down:
v=DMARC1— Protocol versionp=reject— Policy: reject emails that fail authenticationrua=— Where to send aggregate reportspct=100— Apply policy to 100% of emails
Recommended Rollout Strategy
Don't jump straight to p=reject. Roll out gradually:
- Monitor:
p=none; rua=mailto:[email protected]— collect data for 2-4 weeks - Quarantine:
p=quarantine; pct=25— start quarantining 25% of failures - Increase: Gradually raise
pctto 100 - Reject:
p=reject; pct=100— full enforcement
Common Mistakes
- Using
~allinstead of-allin SPF — soft fail is too permissive - Forgetting third-party senders — marketing tools, CRMs, and transactional email services need to be included in SPF
- Not monitoring DMARC reports — set up
ruaand actually read the reports - Jumping to
p=rejectimmediately — this can block legitimate emails from forgotten senders
Verify Your Setup
Use Waqaya's Email Security Checker to instantly validate your SPF, DKIM, and DMARC configuration. The tool checks all three protocols and gives you an overall grade with specific recommendations for improvement.
A properly configured email authentication setup is one of the most impactful security measures you can take — it protects your brand, your customers, and your email deliverability.