SPF, DKIM, and DMARC: Email Authentication Setup
How SPF, DKIM, and DMARC work, what alignment means, how to configure them for Amazon SES and Google Workspace, and a safe rollout order from p=none to p=reject.
SPF, DKIM, and DMARC are three DNS based mechanisms that let a receiving mail server decide whether a message that claims to come from your domain was actually authorised by you. Without them, mail from a new domain is treated with suspicion, and the large mailbox providers now expect bulk senders to publish all three. This guide explains what each record does, how the three fit together through alignment, and how to configure them for Amazon SES and Google Workspace.
SPF: who may send on behalf of the domain
Sender Policy Framework is a TXT record at the domain apex that lists the servers allowed to send mail using that domain in the envelope sender, also called the Return-Path or MAIL FROM address. A receiving server looks up the record, checks whether the connecting IP address is covered, and produces a pass, fail, softfail, or neutral result.
The record starts with v=spf1 and is followed by mechanisms. The include mechanism pulls in another domain’s record, which is how you authorise a sending service: Google Workspace documents include:_spf.google.com, and Amazon SES documents include:amazonses.com. The ip4 and ip6 mechanisms authorise specific addresses, useful for a VPS that sends directly. The record ends with a qualifier for everything else, usually ~all (softfail) while you are still finding every sender and -all (fail) once the list is complete.
Two constraints catch people out. A domain may publish only one SPF record, so multiple services go into one record with several include mechanisms. And the evaluation may perform at most ten DNS lookups, including the lookups nested inside each include, so a record that includes many services can exceed the limit and fail permanently. Trim unused services instead.
SPF checks the envelope sender, not the From header a person sees. That distinction is why a service can pass SPF on its own domain while your domain gains nothing from it, and it drives the alignment rules below.
DKIM: a signature that survives forwarding
DomainKeys Identified Mail attaches a cryptographic signature to each message in a DKIM-Signature header. The sending server signs selected headers and the body with a private key, and the receiving server fetches the matching public key from DNS at selector._domainkey.yourdomain and verifies it. The d= tag in the signature names the signing domain, and the s= tag names the selector, so one domain can hold several keys for several services and rotate them independently.
Because the signature travels with the message, DKIM still verifies after a message is forwarded by a mailing list or a personal forwarding rule, which is where SPF usually breaks. That is why DKIM alignment is the more reliable path to a DMARC pass for most senders.
Amazon SES offers Easy DKIM, which generates the key pair for a verified identity and asks you to publish CNAME records that point to keys SES hosts, so rotation happens without touching DNS again. SES also supports bringing your own key if you need to control it. Google Workspace generates a key from the Admin console under Gmail authentication settings; you publish the TXT record at the selector it gives you, wait for DNS to propagate, and then turn on signing. Until signing is turned on, Workspace mail is signed with a Google domain rather than yours.
DMARC: policy and alignment
Domain-based Message Authentication, Reporting and Conformance ties SPF and DKIM to the domain in the From header, the one the recipient sees. A message passes DMARC if at least one of the two checks passes and the domain it passed on aligns with the From domain. SPF aligns when the envelope sender domain matches the From domain; DKIM aligns when the d= tag matches the From domain. Relaxed alignment, the default, accepts a subdomain of the From domain. Strict alignment requires an exact match and is set with adkim=s or aspf=s.
The DMARC record is a TXT record at _dmarc.yourdomain starting with v=DMARC1. The p= tag tells receivers what to do with mail that fails: none means deliver and report, quarantine means treat as suspicious, usually by sending to spam, and reject means refuse it. The rua= tag names an address for aggregate reports, which are XML summaries of who sent mail using your domain and how it authenticated. The sp= tag sets a separate policy for subdomains, and pct= applies the policy to a percentage of failing mail so you can roll out gradually.
Alignment is where sending services need attention. Amazon SES uses an amazonses.com address as the envelope sender by default, so SPF passes but does not align. To get SPF alignment, configure a custom MAIL FROM domain, normally a subdomain such as mail.yourdomain, and publish the MX and SPF records SES asks for. Easy DKIM signs with your domain, so DKIM alignment is available as soon as the CNAME records are live. Google Workspace signs with your domain once DKIM is enabled and uses your domain in the envelope sender, so both checks align.
| Record | DNS location | Type | What it proves | Aligns with From header via |
|---|---|---|---|---|
| SPF | Domain apex (or the MAIL FROM subdomain) | TXT | Connecting IP is authorised for the envelope sender domain | Envelope sender domain |
| DKIM | selector._domainkey.domain | TXT or CNAME | Message headers and body were signed by the key holder | d= tag in the signature |
| DMARC | _dmarc.domain | TXT | Policy for unaligned failures, plus where to send reports | Defines the alignment rules |
A safe rollout order
Publishing a reject policy before every legitimate sender is authenticated will block your own mail, so roll out in sequence.
- Inventory every system that sends mail as the domain: Workspace mailboxes, the application through SES, the helpdesk, the invoicing tool, the marketing platform, and any VPS that sends cron output.
- Publish SPF with the includes for each service, ending in ~all, and confirm the lookup count stays under the limit.
- Enable DKIM on each service with its own selector and verify the signature in a test message’s headers.
- Publish DMARC with p=none and an rua address, then read the aggregate reports for a few weeks to find senders you missed.
- Move to p=quarantine, optionally with pct= to start small, then to p=reject once reports show only authorised sources.
- Set sp= for subdomains you never send from, and tighten SPF to -all.
Common mistakes
The most frequent failure is a second SPF record added by a colleague, which makes both invalid. The second is DKIM enabled on the service but never switched on in DNS, so messages go out signed by the service’s own domain. The third is a DMARC reject policy set on the apex while a subdomain used by a forgotten tool has no records at all, which the sp= tag was designed to handle. Finally, a new domain with perfect records still has no reputation; authentication tells receivers who you are, and the guide to email deliverability basics covers the warm-up and list hygiene that tell them whether to trust you.
Where to go next
Both services mentioned here appear on the marketplace. The Amazon SES accounts page lists SMTP limit options, and the Google Workspace account page lists Workspace options for business mailboxes. Use of either remains subject to the provider’s terms, and sending must be permission based and compliant with anti-spam law.
For the SES side of the setup, including the sandbox and production access, read Amazon SES explained. For Workspace mailboxes on a custom domain, see setting up business email with Google Workspace. The rest of the email infrastructure series is in the Cloud Library.