If your emails are landing in spam folders—or not arriving at all—there's a good chance your domain's email authentication isn't properly configured. This guide explains the three pillars of email authentication and how to set them up correctly.
See how your domain is currently configured with our free scanner.
Without proper authentication, anyone can send emails that appear to come from your domain. This is called email spoofing, and it's a favorite technique of phishers and spammers.
Email authentication solves this by:
The three technologies that make this work are SPF, DKIM, and DMARC. Let's break each one down.
SPF (Sender Policy Framework) is a DNS record that lists which servers are authorized to send email on behalf of your domain. When an email arrives, the receiving server checks if the sending server's IP address is on your approved list.
v=spf1 include:_spf.google.com include:sendgrid.net ~allv=spf1 — This is an SPF record (version 1)include:_spf.google.com — Google Workspace servers are authorizedinclude:sendgrid.net — SendGrid servers are authorized~all — Soft-fail emails from any other source| Issue | Impact | Solution |
|---|---|---|
| No SPF record | Emails may be flagged as spam | Add an SPF record with your mail providers |
| Multiple SPF records | SPF fails completely (RFC violation) | Combine into a single record |
| Using +all | Anyone can spoof your domain | Change to ~all or -all |
| Too many DNS lookups (>10) | SPF fails with PermError | Flatten your record or reduce includes |
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to your emails. This signature proves the email came from your domain and hasn't been modified in transit.
Published at google._domainkey.yourdomain.com:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...Unlike SPF (which only checks the sending server), DKIM verifies the email content itself. Even if an email is forwarded through multiple servers, the DKIM signature stays intact, proving authenticity.
DMARC (Domain-based Message Authentication, Reporting & Conformance) ties SPF and DKIM together. It tells receiving servers what to do when an email fails authentication checks, and provides reporting so you can monitor authentication results.
Published at _dmarc.yourdomain.com:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com| Policy | Effect | When to Use |
|---|---|---|
| p=none | Monitor only, take no action | Starting out, building visibility |
| p=quarantine | Send to spam folder | After monitoring confirms legitimate sources |
| p=reject | Block the email entirely | Maximum protection, after thorough testing |
Don't jump straight to p=reject. Here's the recommended rollout:
These three technologies form a defense-in-depth approach. For DMARC to pass, at least one of SPF or DKIM must pass AND align with the From domain.
Email Arrives
↓
SPF Check: Is the sender's IP authorized?
↓
DKIM Check: Is the signature valid?
↓
DMARC Check: What's the domain policy?
↓
Email Delivered / Quarantined / Rejected
~all or -allp=)_dmarc.yourdomain.comp=none, p=quarantine, or p=reject)rua=) is configuredpct is not set to 0Yes, for maximum protection and deliverability. SPF and DKIM each solve different problems, and DMARC ties them together with policy enforcement and reporting.
If you're using @gmail.com or @outlook.com, Google and Microsoft handle authentication for you. This guide applies to custom domains (like @yourcompany.com).
Typically a few hours, but can take up to 48 hours. Start with monitoring (p=none) while you wait.
Use our checker to confirm everything is configured correctly.