Email Security: SPF, DKIM, and DMARC Explained

4 min read

## Why Email Authentication Matters Email was designed without authentication. Any server can send a message claiming to be from any address. For decades, this has been exploited by spammers and phishers to send emails that appear to come from trusted senders — banks, payment processors, your employer, your own company. Three DNS-based standards close this gap: SPF, DKIM, and DMARC. Together, they let receiving mail servers verify that a message claiming to be from your domain was actually sent by an authorized source. Without all three, your domain can be impersonated in email, your messages may be marked as spam, and your customers may receive convincing phishing emails that appear to come from you. ## SPF: Sender Policy Framework An SPF record is a `TXT` DNS record that lists the IP addresses and mail servers authorized to send email on behalf of your domain. When a receiving mail server gets a message claiming to be from `yourcompany.com`, it checks the SPF record to see if the sending server is on the authorized list. If it is not, the message fails SPF. ### Creating an SPF Record SPF records are TXT records published at the root of your domain (`@`). A basic record looks like: ``` v=spf1 include:_spf.google.com include:sendgrid.net ~all ``` Breaking this down: - `v=spf1` — Identifies this as an SPF record. - `include:_spf.google.com` — Authorizes Google's mail servers (if you use Google Workspace). - `include:sendgrid.net` — Authorizes SendGrid (if you use it for transactional email). - `~all` — "Soft fail" for any source not listed. Use `-all` (hard fail) once you are confident the list is complete. Gather a list of every service that sends email on behalf of your domain before creating your SPF record. Missing a legitimate sender will cause those messages to fail SPF. **Important constraints**: SPF records have a maximum of 10 DNS lookup operations. If you use many third-party email services, you may need to consolidate or use SPF flattening. ## DKIM: DomainKeys Identified Mail DKIM adds a cryptographic signature to outgoing email messages. The sending mail server signs each message with a private key, and publishes the corresponding public key in a DNS record. Receiving servers retrieve the public key and verify the signature, confirming that the message content has not been tampered with and that it was sent by a server holding the private key. DKIM signatures are attached to a specific domain selector (a label) and published as a TXT record at `selector._domainkey.yourdomain.com`. ### Setting Up DKIM Most email providers (Google Workspace, Microsoft 365, SendGrid, Mailgun) generate the key pair and provide you with the DNS record to publish. The process: 1. In your email provider's admin panel, find DKIM settings and generate a key. 2. Copy the DNS record (a TXT record) provided. 3. Add this record to your DNS at your registrar or DNS provider. 4. Return to the email provider and click "Verify" to confirm propagation. If you have multiple sending services, each needs its own DKIM key with a different selector. ### DKIM Record Example ``` v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCC... ``` Published at: `google._domainkey.yourcompany.com` ## DMARC: Domain-based Message Authentication, Reporting & Conformance DMARC builds on SPF and DKIM. It tells receiving mail servers what to do when a message fails SPF or DKIM authentication, and it provides a reporting mechanism so you can see what is happening with your domain's email. A message "passes" DMARC if either: - It passes SPF, **and** the SPF-authenticated domain aligns with the `From:` domain. - It passes DKIM, **and** the DKIM-signing domain aligns with the `From:` domain. This alignment requirement is key — it prevents attackers from using a legitimate sending domain in SPF/DKIM while spoofing a different `From:` address. ### DMARC Record Syntax DMARC records are TXT records published at `_dmarc.yourdomain.com`: ``` v=DMARC1; p=none; rua=mailto:[email protected] ``` The `p=` field is the policy: - `p=none` — Monitor mode. Take no action on failures; just send reports. Start here. - `p=quarantine` — Suspicious messages go to spam/junk. - `p=reject` — Failing messages are rejected outright. The strongest enforcement. ### Implementation Sequence Rushing to `p=reject` risks blocking legitimate email. Use this phased approach: 1. **Publish SPF and DKIM** for all your sending sources. 2. **Set DMARC to `p=none`** with a `rua` (aggregate report) address. 3. **Review aggregate reports** for 2–4 weeks. Identify all legitimate sending sources and confirm they pass SPF and DKIM. 4. **Fix any failures** by adding missing authorized senders to SPF or correcting DKIM configuration. 5. **Move to `p=quarantine`** once all legitimate mail passes consistently. 6. **Promote to `p=reject`** after another monitoring period confirms no legitimate mail is affected. ### Reading DMARC Reports DMARC aggregate reports (`rua`) arrive as XML files summarizing which IPs sent email on behalf of your domain and whether they passed or failed authentication. Use a DMARC report analysis service (several are available free) to convert these into readable dashboards. Look for: - Unknown sending sources (potential phishing infrastructure). - Legitimate sources failing SPF or DKIM (misconfiguration to fix). - Volume trends that might indicate spoofing campaigns. ## Verification with DNS Record Helper Use DNS Record Helper to confirm your SPF, DKIM, and DMARC records are published correctly and syntactically valid. Check WHOIS Lookup Tool for domain-level status. ## Summary | Standard | Protects Against | DNS Record Type | |---|---|---| | SPF | Unauthorized sending servers | TXT at `@` | | DKIM | Message tampering; unauthorized signing | TXT at `selector._domainkey` | | DMARC | Domain spoofing in `From:` field | TXT at `_dmarc` | Implement all three. Together they form the foundation of email Domain Security, protect your customers from phishing, and improve your email deliverability. Return to Domain Security Checklist to confirm email authentication as part of your full security review.

Related Guides