Email SPF/DKIM/DMARC Configuration: Improving Email Deliverability and Security

Email SPF/DKIM/DMARC Configuration: Improving Email Deliverability and Security

SPF, DKIM, and DMARC are the three pillars of email authentication. They solve a very practical set of problems: why your deliverability fluctuates, why messages land in spam, and whether someone can impersonate your domain for phishing. Each plays a different role: SPF declares who is allowed to send, DKIM proves a message really came from you, and DMARC tells receivers what to do when SPF/DKIM both fail. Only when all three DNS records are in place do you actually own your domain's email identity.

1. SPF (Sender Policy Framework)

SPF uses a single DNS TXT record to declare which servers are authorized to send mail for your domain. If a mail server's IP isn't on the list, receivers can mark the message as failed:

# DNS TXT Record
example.com.  IN  TXT  "v=spf1 include:_spf.google.com ~all"

A common mistake: when using a third-party service (Google Workspace, Mailgun, etc.), reference its include rather than copying over its IPs — IPs change, and include is the stable way to reference them. SPF has a 10-DNS-lookup limit, so chaining too many includes will silently break validation.

2. DKIM (DomainKeys Identified Mail)

DKIM signs each message with a private key; receivers verify the signature against the public key you publish in DNS. This confirms the message wasn't tampered with in transit and genuinely comes from your domain:

# DKIM DNS Record (selector name is set by your email provider)
google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

A few things to watch: the selector name is decided by the provider — Google Workspace uses google, Cloudflare Email Routing uses something like c1; the p= public key must be copied completely without truncation; and if you run multiple sending systems (marketing plus transactional), give each its own selector and key so you can rotate and debug them independently.

3. DMARC (Domain-based Message Authentication, Reporting & Conformance)

SPF and DKIM each return pass/fail; DMARC dictates what receivers do when both fail, and gives you aggregate reports showing the full authentication picture:

# DMARC DNS Record
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100"

The rua address receives aggregate reports (XML). Hand them to a third-party tool (dmarcian, Google Postmaster Tools) to see which services are impersonating your domain and which SPF chain occasionally fails. The sp tag lets you set a separate policy for subdomains.

4. Configuration and Verification

Verify with tooling after publishing records — don't go live on faith:

# Command-line verification
dig TXT example.com                # View SPF
dig TXT google._domainkey.example.com   # View DKIM public key
dig TXT _dmarc.example.com         # View DMARC

# After sending a test message, cross-check results at:
# https://mxtoolbox.com/diagnostic.aspx
# https://www.mail-tester.com

A Complete Spoofing Block, End to End

Tracing all three protocols together is the best way to see where each one sits. Suppose an attacker tries to send you a phishing email pretending to be from example.com:

1. SPF blocks first: the attacker's server IP isn't on example.com's SPF allowlist, so SPF fails. Gmail, Outlook, and similar receivers already know "this message's identity is suspect."
2. DKIM checks again: the attacker doesn't hold example.com's DKIM private key, so the signature is missing or fails verification. Note that SPF and DKIM are an "OR" — if either passes, DMARC may allow delivery, which is exactly why you need both.
3. DMARC makes the final call: when both fail, the receiver applies the policy in your _dmarc record. p=reject bounces it outright; p=quarantine drops it in spam. The aggregate report logs the source IP and outcome for your investigation.

In practice many domains configure SPF and stop there, leaving DKIM missing and no DMARC at all — attackers can still spoof the "display name" in the header. Those domains are the worst phishing vectors. All three records are what actually close the gap.

A Smarter Rollout Detail: A Dedicated Sending Subdomain

If several systems send mail from your site — order emails, marketing pushes, support tickets — don't hang them all on the root domain. Set up a dedicated sending subdomain like mail.example.com instead. The reason is practical: open rate, bounce rate, and spam complaints directly shape a sending domain's reputation, and if one system earns a high complaint label, receivers may pull down legitimate mail for the whole domain. Splitting the sending domain from the root means that even if a marketing flow goes wrong, order notifications and password resets still land. The only cost is a few extra DNS records (the SPF include, a DKIM selector, and the DMARC rua/sp tags) — operationally negligible.

FAQ

What happens with SPF but no DKIM/DMARC? SPF depends on the envelope address and often fails when mail is forwarded; DKIM survives forwarding because it signs content. Domains with SPF only frequently show up as "via" in Gmail.

Will DMARC kill legitimate mail right after launch? It can, which is why the rollout must be none → quarantine → reject, watching reports at each tier — typically two or more weeks.

Who owns the config when using a third-party provider? Providers supply ready-made SPF includes, DKIM selectors, and DMARC recommendations; you just publish the records at your DNS host. The domain is yours, so the DNS records are always yours to publish.

Reference: RFC 7208 (SPF) https://www.rfc-editor.org/rfc/rfc7208 ; RFC 7489 (DMARC) https://www.rfc-editor.org/rfc/rfc7489 ; Google Sender Guidelines https://support.google.com/a/answer/81126