To authenticate your sending domain, you’ll publish DNS records for SPF, DKIM, and DMARC. Together they help mailbox providers verify that your email is really coming from you and reduce spoofing.

1) SPF: authorize which servers can send for your domain

Purpose: tells receiving servers which mail servers/IPs are allowed to send mail for your domain.

What to add

Add a TXT record at your root domain (@) with an SPF policy.

Example:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all

Common parts

• v=spf1 — SPF version
• include: — delegate to a provider (Google, Microsoft, SendGrid, Mailchimp, etc.)
• ip4: / ip6: — specific sending IPs
• -all — hard fail for anything not listed
• ~all — soft fail (less strict)

Best practices

• Only one SPF record per domain
• Keep the record under 10 DNS lookups if possible
• Include every service that sends mail for your domain

---

2) DKIM: cryptographically sign outgoing mail

Purpose: adds a digital signature to messages so recipients can verify they weren’t altered and that they were signed by your domain.

What to add

Your email provider will give you:

• a selector (like s1 or google)
• a public key to publish in DNS

You’ll create a TXT record like:

s1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_HERE"

How it works

• Your email provider signs outgoing messages with a private key
• Receivers fetch the public key from DNS and verify the signature

Best practices

• Use a long, unique key (2048-bit RSA is common/recommended)
• Keep selectors separate if multiple systems sign mail
• Rotate keys periodically if your provider supports it

---

3) DMARC: tell receivers how to handle failures

Purpose: sits on top of SPF and DKIM and tells receiving servers what to do if authentication fails, plus where to send reports.

What to add

Add a TXT record at:

_dmarc.example.com

Example starting policy:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

DMARC tags

• v=DMARC1 — DMARC version
• p= — policy:
  • none = monitor only
  • quarantine = mark as suspicious
  • reject = reject failing mail
• rua= — aggregate report address
• ruf= — forensic report address (less commonly used; privacy support varies)

Alignment

DMARC passes when:

• SPF passes and aligns with the visible “From” domain, or
• DKIM passes and aligns with the visible “From” domain

Alignment can be strict or relaxed depending on your DMARC settings.

---

Recommended setup order

1. Inventory all sending sources

   • Google Workspace / Microsoft 365
   • Marketing platforms
   • CRM systems
   • Transactional email services
   • Servers/apps sending directly

2. Publish SPF

   • Add all legitimate sending sources
   • Ensure only one SPF TXT record exists

3. Enable DKIM in each sending platform

   • Generate or obtain selector + public key
   • Add DNS TXT/CNAME records as instructed by the provider
   • Turn signing on

4. Publish DMARC

   • Start with p=none
   • Monitor reports and fix gaps
   • Move to quarantine, then reject

---

Example DNS records

SPF

example.com TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"

DKIM

s1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0B..."

DMARC

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

---

Common mistakes to avoid

• Publishing multiple SPF records
• Forgetting a third-party service that sends on your behalf
• Having SPF that exceeds the DNS lookup limit
• DKIM not enabled on all sending streams
• Moving DMARC to reject before checking reports
• Using a DMARC report mailbox you don’t monitor

---

How to verify it’s working

Use:

• dig / nslookup to inspect DNS records
• Email header analysis in Gmail/Outlook
• External tools like:
  • MXToolbox
  • dmarcian
  • Google Postmaster Tools
  • Microsoft SNDS (for some mail ecosystems)

In email headers, look for:

• spf=pass
• dkim=pass
• dmarc=pass

---

If you tell me your email provider(s) (e.g., Google Workspace, Microsoft 365, SendGrid, Mailchimp, SES), I can give you the exact DNS records and a rollout plan.