SPF, DKIM & DMARC explained for email senders

Why authentication is now mandatory, not optional

Email was designed in an era of trust, so nothing in the original protocol stops anyone from typing your domain into the From address. Spammers and phishers exploited that for decades. Authentication closes the hole by letting you publish, in public DNS, exactly who is allowed to send as you — and letting receivers verify it.

This used to be a best practice. It is now effectively a requirement. Since 2024, Google and Yahoo require bulk senders (roughly 5,000+ messages a day) to have SPF, DKIM, and a DMARC policy in place, and Microsoft has followed with similar rules. Without them, your mail is throttled, filtered, or bounced regardless of how good your content is.

SPF: who is allowed to send

SPF (Sender Policy Framework) is a single TXT record on your domain that lists the mail servers and services permitted to send email using your domain in the envelope sender. When a receiving server gets a message, it checks whether the connecting server appears in your SPF record.

A record looks like: v=spf1 include:_spf.google.com include:sendgrid.net ~all. Each include authorizes a sending service; the ~all at the end means 'anything not listed is suspicious (soft fail).'

• Publish exactly one SPF record per domain — multiple SPF records is a common, silent failure.
• Include every service that sends as you: your ESP, your CRM, your helpdesk, your own mail server.
• SPF has a hard limit of 10 DNS lookups. Chaining too many includes breaks it — flatten or consolidate if you hit the ceiling.
• SPF alone breaks when mail is forwarded, because the forwarding server isn't in your record. That's one reason DKIM and DMARC exist.

DKIM: proof the message wasn't altered

DKIM (DomainKeys Identified Mail) signs each outgoing message with a private cryptographic key held by your sending service. The matching public key lives in a TXT record on your domain. The receiver recalculates the signature using that public key; if it matches, the message is provably from your domain and hasn't been tampered with in transit.

Unlike SPF, DKIM survives forwarding, because the signature travels with the message itself rather than depending on the connecting server's IP. Your ESP usually generates the key pair and gives you a DNS record (a 'selector') to publish — you rarely touch the cryptography directly.

• Use a 2048-bit key where your provider supports it; 1024-bit is the weaker minimum.
• Each sending service gets its own selector, so you can run several signers on one domain.
• Rotate keys periodically and remove selectors for services you no longer use.
• Verify the published record with a DKIM checker before you rely on it — a truncated or malformed key silently fails.

DMARC: the policy that ties it together

DMARC (Domain-based Message Authentication, Reporting & Conformance) is the record that makes SPF and DKIM actually enforceable. It does two jobs: it tells receivers what to do with mail that fails authentication, and it asks them to send you reports on everything sent using your domain — including forgeries.

DMARC introduces a concept called alignment: it isn't enough for SPF or DKIM to pass, the domain they authenticate must match the visible From domain. This is what stops a spammer from passing SPF on some throwaway domain while still displaying your brand in the From line.

A record looks like: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. The p value is your enforcement policy, and moving it up is the whole game.

• p=none — monitor only. Nothing is blocked; you just collect reports. Always start here.
• p=quarantine — failing mail goes to spam/junk. Move here once your legitimate mail passes cleanly.
• p=reject — failing mail is refused outright. This is the goal, and what best protects your brand from spoofing.
• rua= — the address where aggregate XML reports are sent. Feed these into a DMARC reporting tool to read them.

How to set them up, in order

Roll these out deliberately. The most common way senders hurt themselves is jumping straight to an enforcing DMARC policy before every legitimate service is authenticated — which blocks their own mail.

• 1. Inventory every service that sends email as your domain (ESP, CRM, invoicing, support, marketing tools).
• 2. Publish one SPF record covering all of them, staying under the 10-lookup limit.
• 3. Enable DKIM signing in each service and publish each selector's public key.
• 4. Publish DMARC at p=none with a rua reporting address and watch the reports for a few weeks.
• 5. Fix any legitimate source that's failing alignment, then raise the policy to p=quarantine.
• 6. Once clean, move to p=reject for full protection. Re-check whenever you add a new sending tool.

Authentication earns trust — a clean list keeps it

SPF, DKIM, and DMARC prove you are who you say you are. They don't fix the other half of deliverability: sending to addresses that don't exist. Mailbox providers watch your bounce rate and spam-trap hits just as closely as your authentication, and a perfectly authenticated campaign to a dirty list still lands you in spam. The two work together — authentication is your identity, list hygiene is your reputation.

That's where EmailClik Verify fits. Before a send, run your list through it: every address gets a 0–100 deliverability score and machine-readable reason codes, sorted into good, risky, and bad, with catch-all detection, disposable/role/free flags, and typo rescue that fixes obvious mistakes like gmial.com. Upload a CSV, TXT, or XLSX up to a million rows — it auto-detects the email column, dedupes, and preserves every column you uploaded, plus a one-page PDF report. There's a REST API for real-time checks at signup, and EverClean can auto-clean lists right inside your ESP or CRM.

It's pay-as-you-go — 10,000 emails for $37, 100,000 for $149, 1,000,000 for $549 — with credits that never expire and no subscription. Authenticate your domain so providers trust you, then verify your list so you keep that trust.

Frequently asked questions