SPF, DKIM, and DMARC Explained for Non-Technical Founders

SPF, DKIM, and DMARC are three DNS records that prove your emails are really from you. Set them up and mailbox providers trust you, so your email reaches the inbox. Skip them and Gmail, Yahoo, and Microsoft either drop you into spam or reject you outright. That is the whole story, and you do not need to be an engineer to get it right.

This guide is written for the founder who owns the domain but has never touched a DNS zone. No jargon left unexplained, no "consult your IT team." You will get plain-English definitions, real copyable records you can adapt, and the one thing most guides skip: the safe order to turn DMARC on so you do not accidentally block your own real email.

Key takeaways

• SPF, DKIM, and DMARC are three separate TXT records you add to your domain's DNS. Together they answer "is this email really from this domain, and unchanged."
• Since February 2024, Google and Yahoo require SPF and DKIM on all senders, and both plus a DMARC record for anyone sending more than 5,000 messages a day. This is enforced, not optional.
• SPF lists who may send for you. DKIM cryptographically signs each message. DMARC ties them to your visible From address and tells receivers what to do on failure.
• Turn DMARC on with p=none first (monitor only), read the reports, then move to p=quarantine and finally p=reject. Jumping straight to reject can block your own legitimate mail.
• The records are the price of entry, not a guarantee. Reputation and complaint rate still decide the inbox, so pair authentication with clean list habits.

What each record actually does, in plain English

Think of it like proving you wrote a letter. Anyone can put your return address on an envelope. These three records are the checks the post office runs to confirm it is genuinely you.

SPF (Sender Policy Framework) is a public list of who is allowed to send email for your domain. You publish it as a TXT record. When mail arrives, the receiving server reads the sending server's IP and checks it against your list. On the list, SPF passes. Not on the list, SPF fails. That is it: SPF is a guest list for your sending servers.

DKIM (DomainKeys Identified Mail) adds a tamper-proof signature to every message you send. Your sending service holds a private key and signs each email; you publish the matching public key in DNS. The receiver uses the public key to confirm two things: the message came from a server that holds your private key, and nobody altered it in transit. DKIM is a wax seal on the envelope that also proves the letter was not steamed open.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy that ties it together and gives you visibility. It does two jobs. First, it requires "alignment": the domain in your visible From address has to match the domain that passed SPF or DKIM, which stops a scammer from passing their own SPF while spoofing your From line. Second, it tells receiving servers what to do when a message fails, and it emails you reports on everything sent using your domain, including spoofing attempts.

Here is the part most people get wrong: DMARC does not require both SPF and DKIM to pass. It is an "or" check. As long as one of them passes and aligns with your From domain, DMARC passes. You publish all three because they cover different failure modes, but a single aligned pass is enough for DMARC itself.

Why this is not optional anymore

For years, authentication was a best practice you could put off. That ended in February 2024, when Google and Yahoo began enforcing shared bulk-sender rules, later echoed by Microsoft.

Per Google and Yahoo's published sender requirements, every sender must authenticate with SPF or DKIM. Anyone who sends more than 5,000 messages a day to Gmail must use both SPF and DKIM and publish a DMARC record with a policy of at least p=none, with the From domain aligned to SPF or DKIM. Yahoo adds that DKIM keys should be at least 1,024 bits. Bulk senders also have to keep their spam complaint rate low and offer one-click unsubscribe on marketing mail.

The consequence for ignoring this is not subtle. Non-compliant mail first gets temporary errors on a slice of traffic, then escalates to spam-foldering and outright rejection. If you run a SaaS and your password resets, receipts, and onboarding emails are unauthenticated, some of them are already not arriving. For a full picture of what else moves inbox placement, see our email deliverability guide.

Copyable records you can adapt

Here are real records in the correct format. Replace the example values with your own. You add all of these as TXT records in your DNS provider (the same place you manage your domain, such as Cloudflare, Namecheap, or Route 53).

SPF. One TXT record on your root domain, and only one SPF record is allowed. This example authorizes Amazon SES and Google Workspace:

Type: TXT
Host: @
Value: v=spf1 include:amazonses.com include:_spf.google.com -all

The include: entries pull in each provider's authorized servers. The -all at the end means "reject anything not listed." If you send through more than one service, put every include: in this single record. Watch the ten-DNS-lookup limit: SPF is allowed a maximum of ten lookups, and too many include: entries silently break it.

DKIM. You do not write DKIM by hand. Your sending provider generates the keys and gives you records to publish, usually one to three CNAME records or a TXT record with a selector. With Amazon SES the console hands you three CNAMEs that look like this:

Type: CNAME
Host: abc123._domainkey.yourdomain.com
Value: abc123.dkim.amazonses.com

Publish exactly what your provider gives you. The selector (the abc123 part) lets you rotate keys and run multiple services without collisions.

DMARC. One TXT record at the _dmarc subdomain. Start in monitor mode:

Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r

p=none means "do not block anything yet, just report." rua= is the address where aggregate reports get sent, so you can see who is sending as you. adkim=r and aspf=r set relaxed alignment, which is the forgiving default you want while you are getting set up.

The safe rollout: monitor, then enforce

This is the section that saves you from blocking your own email, and it is exactly what most tool-first guides gloss over. Never jump straight to p=reject. Move in three stages and let the reports tell you when it is safe.

1. Publish p=none and watch (two to four weeks). Nothing gets blocked. The DMARC reports arriving at your rua address show every source sending mail using your domain: your ESP, your CRM, your support desk, your invoicing tool. You will almost always find a legitimate service you forgot about. Fix its SPF or DKIM until it passes and aligns.

1. Move to p=quarantine and confirm (two to four weeks). Change p=none to p=quarantine. Now anything failing DMARC goes to the recipient's spam folder instead of the inbox. Keep reading reports. If a real service is still failing, its mail lands in spam, which is a visible, recoverable problem rather than a silent block.

1. Move to p=reject. Once your reports show only known, aligned sources passing, change to p=reject. Failing mail is now blocked outright, which is what actually stops spoofers from impersonating you. You can add pct= to ramp gradually, for example p=quarantine; pct=25 to apply the policy to a quarter of failing mail first.

The whole rollout takes four to eight weeks of patience, not one afternoon of copy-paste. That patience is the difference between authentication that protects you and authentication that eats your own onboarding emails.

How to check your records are working

Publishing a record and having it work are different things. Verify before you trust it.

• SPF and DMARC syntax. Free lookups from MxToolbox or an SPF record checker read your live DNS and flag syntax errors, the ten-lookup problem, or a missing record. Run your domain through one after each change.
• DKIM signing. Send yourself a real email, open the raw headers, and look for dkim=pass. In Gmail, use "Show original." A dkim=pass with your domain in the d= tag confirms it is signing and aligned.
• A full end-to-end check. Send a real message to a Mail-Tester address to see SPF, DKIM, DMARC, and content graded together in one score. Our guide on how to run an email deliverability test walks through exactly this.
• DMARC reports over time. The XML reports at your rua address are the source of truth for who is sending as you. A DMARC analyzer turns that XML into a readable dashboard if you would rather not parse it by hand.

If your records pass but mail still lands in spam, the problem has moved past authentication to reputation. Our explainer on why your emails go to spam covers what comes next, and sender reputation explains the score that authentication alone cannot fix.

Common mistakes that quietly break authentication

• Two SPF records. Only one SPF record is valid per domain. A second one makes both fail. Merge every include: into one record.
• Blowing the ten-lookup limit. Every include: counts toward SPF's ten-DNS-lookup ceiling. Stacking too many services silently breaks SPF. Trim unused ones or flatten the record.
• From-domain misalignment. Your visible From address must be on the same domain that passes SPF or DKIM. Sending from [email protected] while your ESP signs as mail.esp.com fails DMARC alignment even though SPF and DKIM technically pass.
• Jumping to p=reject on day one. The single most common way founders block their own mail. Always start at p=none.
• Forgetting a subdomain. DMARC on your root domain does not automatically cover mail.yourdomain.com. Publish records for every domain and subdomain you actually send from.

Where Meisa fits

Everything above is portable knowledge: those records work no matter who you send through. The friction is usually in the setup, hunting down each service's DKIM keys, guessing whether alignment is right, and reading DMARC XML by hand.

Meisa is an email platform for SaaS teams built around your sending identity. It has a domain verification model separate from your sender identities, so when you add a domain it walks you through the exact DKIM, SPF, and DMARC records to publish and then confirms they verify, instead of leaving you to decode raw DNS. Because Meisa can run on your own Amazon SES, you own the domain reputation you are authenticating, and its true open-rate analytics tell you whether real humans are opening once your mail is landing. If you would rather run the whole thing from Claude or ChatGPT, its MCP connector exposes senders, domains, and analytics as tools your AI assistant can drive.

To be fair, if all you need is a one-time DNS cleanup, a free record checker plus your registrar's help docs will get you there and you do not need a platform for it. Meisa earns its place when authentication is step one of running real lifecycle email and broadcasts, and you want verification, sending, and honest analytics in one place you control. See the best email tools for SaaS for how it compares.

FAQ

What is SPF, DKIM, and DMARC in simple terms?

They are three DNS records that prove your email is genuine. SPF is a public list of servers allowed to send for your domain. DKIM adds a tamper-proof cryptographic signature to each message. DMARC ties both to your visible From address, tells receivers what to do when a message fails, and emails you reports on who is sending as you. Together they let Gmail, Yahoo, and Microsoft trust that mail from your domain is really yours.

Does DMARC need both SPF and DKIM to pass?

No. DMARC is an "or" check, not an "and" check. As long as either SPF or DKIM passes and aligns with your From domain, DMARC passes. You still publish both because they cover different failures and give you redundancy, but a single aligned pass is enough for DMARC to succeed on any given message.

How do I set up SPF, DKIM, and DMARC?

Add three records in your DNS provider. Publish one SPF TXT record listing every service that sends for you, ending in -all. Publish the DKIM records your sending provider generates (usually CNAMEs with a selector). Publish a DMARC TXT record at _dmarc starting with p=none and an rua= reporting address. Then verify with a record checker, watch the DMARC reports, and only tighten the policy once real senders are passing.

What DMARC policy should I start with?

Always start with p=none. It blocks nothing and only reports, so you can discover every service sending mail as you without risking your own email. After two to four weeks of clean reports, move to p=quarantine, then finally p=reject. Jumping straight to p=reject is the most common way founders accidentally block their own legitimate mail.

Do I really need all three if I am a small sender?

Since February 2024, Google and Yahoo require SPF or DKIM on every sender, and both plus DMARC for anyone sending over 5,000 messages a day. Even under that threshold, publishing all three is the safest choice: it protects you against spoofing and is increasingly the baseline receivers expect before they trust you. There is no downside to authenticating fully, and real risk to authenticating partially.

Where do I add these records?

In your DNS provider, which is wherever you manage your domain, such as Cloudflare, Namecheap, GoDaddy, or Amazon Route 53. Log in, find the DNS or zone editor, and add each one as a TXT record (DKIM is often CNAMEs your provider supplies). Changes can take up to a day to propagate, so verify with a record checker after you save rather than assuming it is live immediately.