SPF, DKIM and DMARC are three separate DNS records that together prove your outgoing email is genuinely from you, not a spoofed sender — and each has a specific syntax where small mistakes cause silent authentication failures rather than obvious errors.

SPF: Authorizing Who Can Send

An SPF record is a TXT record listing every service allowed to send mail as your domain. A basic example for a domain using Google Workspace and a WordPress site's contact form:

v=spf1 include:_spf.google.com include:websnp.com ~all

The critical, commonly-missed rule: a domain can have only one SPF record. Adding a second one (a common mistake when setting up a new service without checking for an existing record) breaks SPF validation for all senders, not just the newly added one — the fix is always to add the new include to the existing record, never create a second one.

DKIM: Cryptographically Signing Each Message

DKIM works differently — your email provider generates a public/private key pair, publishes the public key as a DNS TXT record at a specific selector subdomain (e.g. google._domainkey.yourdomain.com), and signs every outgoing message with the private key. The receiving server checks the signature against your published public key. Each platform (Google, Zoho, your hosting provider) generates its own DKIM key — if you send from multiple platforms, each needs its own DKIM record added, not just one for whichever you set up first.

DMARC: Telling Receivers What to Do on Failure

DMARC ties SPF and DKIM together and tells receiving servers your policy for mail that fails both checks:

v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100

The p= value is the policy: none monitors without affecting delivery (the safe starting point), quarantine sends failing mail to spam, reject blocks it outright. Start at none, review the aggregate reports DMARC sends to the address in rua= for a few weeks to confirm nothing legitimate is failing, then move to quarantine and eventually reject once confident.

The Mistake That Breaks Everything Silently

Jumping straight to p=reject without first monitoring at p=none is the single most damaging DMARC mistake: if your own SPF or DKIM has any misconfiguration you haven't caught yet, a reject policy will silently block your own legitimate mail with no visible error on your end — the sender simply never hears back, and you may not learn why for weeks.

Verifying It All Works

After adding all three records, send a test email to a free checker service (like Mail-Tester.com), which reports pass/fail status for SPF, DKIM and DMARC individually along with the specific record values it detected — the fastest way to confirm the records are not just present but actually correct.

Where to Actually Add These DNS Records

If your domain's DNS is managed through your hosting provider's cPanel (Zone Editor), through your domain registrar directly, or through a separate DNS provider, the exact interface differs but the record types and values above stay the same — add each as a TXT record at the specified subdomain (root domain for SPF and DMARC, the specific DKIM selector subdomain for DKIM), and allow a few hours for DNS propagation before testing with a mail checker tool.