SPF, DKIM, and DMARC are DNS-based email authentication standards. They exist because email was designed without any built-in way to verify who is actually sending a message -- anyone can put any address in the From field. These three records give inbox providers a way to check whether an email genuinely came from the domain it claims to be from.
All three are now required for bulk senders by Gmail and Yahoo. Getting them right is not optional if you want reliable inbox delivery.
SPF -- Sender Policy Framework
SPF is a DNS record that lists which mail servers are authorized to send email for your domain. When a receiving mail server gets an email claiming to be from yourcompany.com, it looks up your SPF record and checks whether the sending server's IP address is on the list. If it is, SPF passes. If it is not, SPF fails.
What an SPF record looks like
v=spf1 include:amazonses.com include:_spf.google.com ~all
Breaking this down:
v=spf1-- declares this is an SPF recordinclude:amazonses.com-- authorizes Amazon SES to send on your behalfinclude:_spf.google.com-- authorizes Google Workspace~all-- softfail for anything else (use-allfor a hard fail once you are confident your record is complete)
SPF limitations
SPF has a significant practical limitation: it breaks when email is forwarded. When someone forwards your email to another address, the forwarding server sends the message from its own IP, which is not in your SPF record. The receiving server sees an SPF failure even though the email is legitimate. This is why DKIM matters -- DKIM survives forwarding in a way SPF cannot.
SPF also has a 10 DNS lookup limit. Each include: statement counts as one lookup. If your record requires more than 10 lookups to resolve, the extra ones are ignored and SPF may fail. Senders who use many third-party services can hit this limit without realizing it.
DKIM -- DomainKeys Identified Mail
DKIM adds a cryptographic signature to every email you send. The signature is generated using a private key stored on your sending server and verified using a public key published in your DNS. When a receiving server gets your email, it looks up your public key and uses it to verify that the signature is valid and the email has not been tampered with in transit.
What DKIM looks like in a DNS record
selector._domainkey.yourcompany.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA..."
The selector is a label that lets you publish multiple DKIM keys for the same domain -- useful when you send through several services. Each sending service generates its own key pair and gives you the public key to publish in DNS.
Why DKIM matters more than SPF for deliverability
DKIM signatures survive email forwarding because the signature is attached to the message content, not the sending IP. When a forwarded email arrives, the DKIM signature can still be verified against the original sending domain's public key. This is why inbox providers increasingly rely on DKIM-based domain reputation over SPF-based IP reputation -- DKIM gives a reliable signal even when mail has been forwarded through intermediary servers.
For DMARC alignment -- which we cover below -- DKIM alignment checks whether the domain in your From address matches the domain in the DKIM signature. For most senders sending from their own domain through an email platform, this is handled automatically.
DMARC -- Domain-based Message Authentication, Reporting and Conformance
DMARC ties SPF and DKIM together and adds a policy layer. It tells receiving servers what to do when an email fails authentication checks, and it instructs them to send you reports about authentication results across all mail claiming to be from your domain.
What a DMARC record looks like
v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com; fo=1
The key parameters:
p=none-- monitor only, take no action on failures. Use this to start.p=quarantine-- send failing mail to spam. Move here once your authentication is confirmed clean.p=reject-- reject failing mail outright. The most protective policy.rua=mailto:...-- where to send aggregate reports (daily summaries of authentication results)fo=1-- request failure reports when either SPF or DKIM fails
How DMARC alignment works
DMARC passes when either SPF or DKIM passes AND the passing domain aligns with your From domain. Alignment means the domain matches -- either exactly (strict) or at the organizational domain level (relaxed, the default).
In practice: if you send from newsletter@yourcompany.com and your DKIM signature covers yourcompany.com, DKIM alignment passes. If your sending service signs with their own domain instead of yours, you need to configure custom DKIM on your sending domain to get alignment.
The right path for DMARC policy
Start with p=none and set up a rua address to receive aggregate reports. Read those reports for two to four weeks to understand what is sending mail on behalf of your domain and whether authentication is passing. Once you are confident everything legitimate is authenticating correctly, move to p=quarantine. Move to p=reject only when you have verified that all your legitimate sending paths pass DKIM -- since DKIM survives forwarding unlike SPF, a high DKIM pass rate is the reliable signal that p=reject is safe.
How they work together
| Standard | What it checks | Survives forwarding | Required for DMARC |
|---|---|---|---|
| SPF | Sending server IP is authorized | No | One of SPF or DKIM must pass |
| DKIM | Message signature is valid and untampered | Yes | One of SPF or DKIM must pass |
| DMARC | Policy + alignment + reporting | Yes (via DKIM) | Requires SPF and DKIM to be set up |
A passing DMARC result requires that at least one of SPF or DKIM passes AND that the passing domain aligns with your From address. In practice, DKIM alignment is the more reliable path because it survives the forwarding and relay scenarios that break SPF.
What Gmail and Yahoo now require
Since early 2024, Gmail and Yahoo have required bulk senders (those sending over 5,000 messages per day to Gmail addresses) to have SPF, DKIM, and DMARC all configured. The specific requirements:
- SPF or DKIM must be configured for your sending domain
- DMARC must be published with at least
p=none - The From domain must match the authenticated domain (alignment)
- Valid forward and reverse DNS for sending IPs
- Complaint rate below 0.1% (monitored via Google Postmaster Tools)
- One-click unsubscribe header in marketing email
These are now baseline requirements, not optional improvements. Senders who do not meet them see mail filtered to spam or rejected outright.
Setting up authentication on Amazon SES
With Amazon SES, DKIM is configured per sending domain in the SES console. SES generates a key pair and gives you three CNAME records to publish in DNS. Once published and verified, SES signs all outbound mail from that domain automatically.
SPF for SES is automatically handled when you use SES as your sending infrastructure -- SES's own SPF record covers the sending IPs. For DMARC alignment, the DKIM signature is what matters: as long as SES is signing with your domain and your DMARC record is published, alignment passes.
Authentication setup included.
AledaMail guides you through SPF, DKIM, and DMARC setup for your sending domain and verifies everything is correctly configured before your first send.
Start free