SPF, DKIM & DMARC Explained Simply

If someone on your team says "our DMARC is misconfigured" and you nod along without actually knowing what that means, you're not alone. These three acronyms get thrown around constantly in email marketing, usually by people assuming everyone already understands them. They don't require a computer science background to understand — they're closer to a passport check at an airport than actual cryptography homework. This guide explains what each one does, using an analogy that actually holds up, plus exactly where you go to set each one up without needing a developer standing over your shoulder.

Key Takeaway: All three records live in the same place — your domain's DNS settings, the same control panel where your website's hosting information lives. You don't edit code or touch your email platform's settings to fix most authentication problems; you add specific text records through your domain registrar (GoDaddy, Namecheap, Cloudflare, or wherever you bought your domain). If you haven't settled on a sending platform yet, it's worth reading our breakdown of who actually leads in B2B email marketing strategy first, since your platform choice directly affects how much of this setup is automated for you versus how much you configure by hand.

The Airport Passport Check Analogy

Picture your domain as a person trying to board a flight (the inbox). Three separate checkpoints decide whether that person gets waved through, pulled aside, or turned away entirely:

• SPF is the guest list. It's a list of which servers are allowed to send mail claiming to be from your domain. If a server isn't on the list, it's like showing up to the gate without being on the passenger manifest.
• DKIM is the passport itself. It's a signature stamped onto every message, proving the message wasn't altered after it left your hands. Even if you're on the guest list, an unstamped or altered passport still raises a flag.
• DMARC is the actual security officer at the checkpoint. It's the one making the decision: if SPF or DKIM comes back wrong, what happens next? Do we wave them through anyway (monitor only), pull them into a side room (spam folder), or turn them away at the door (reject)? DMARC also gives you a report afterward telling you who tried to board using your name.

SPF: The Guest List

What it actually does: SPF (Sender Policy Framework) is a single line of text published in your DNS that lists every server allowed to send email using your domain name. When Gmail or Outlook receives a message claiming to be from you, it checks the sending server's IP address against that list.

What it looks like: An SPF record is a TXT record that reads something like:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Each include: Points to a service you use to send mail — your email platform, your CRM, your helpdesk tool. The ~all at the end tells receiving servers what to do with anything not on the list (a "soft fail," meaning flag it but don't necessarily block it outright).

The one thing that quietly breaks it: SPF can only process 10 DNS lookups before it fails completely, regardless of how correctly it's written. Every include: counts toward that limit, and some services (like Salesforce or certain CRM platforms) use nested includes that quietly eat up several lookups each. If you've connected more than a handful of tools over the years, it's worth actually counting your lookups rather than assuming you're fine.

Where to add or check it: Log into your domain registrar (GoDaddy, Namecheap, Cloudflare, Google Domains) → DNS settings → look for a TXT record starting with v=spf1. If you don't see one, you need to add it; if you see more than one SPF TXT record, that's actually a problem — you can only have one SPF record per domain, so multiple conflicting ones need merging into a single record.

DKIM: The Stamped Passport

What it actually does: DKIM (DomainKeys Identified Mail) attaches a unique cryptographic signature to every outgoing email. The receiving server checks that signature against a public key published in your DNS. If the message was altered even slightly in transit, the signature won't match, and the check fails.

What it looks like: Unlike SPF, you don't usually write a DKIM record by hand. Your email platform (Mailchimp, ConvertKit, ActiveCampaign, Google Workspace) generates a unique key pair and gives you a specific DNS record to paste in, usually a CNAME or TXT record with a name like s1._domainkey.yourdomain.com. If you're still deciding which platform to send from in the first place, our comparisons of free email marketing platforms and software for running email campaigns both note which tools make custom domain authentication easy to find versus buried a few menus deep — worth checking before you commit, since some platforms make this five-minute step take much longer than it should.

The step people skip: Simply connecting your email platform doesn't automatically set up DKIM with your own domain. Most platforms sign outgoing mail with their own shared domain by default until you specifically go into your platform's settings and enable custom or branded domain authentication, which is usually a distinct toggle you have to find and turn on, then paste the DNS record it generates into your registrar. Skipping this step is the single most common reason DKIM shows as "not aligned" even when someone insists they "already set it up."

Where to add or check it: Inside your email platform's domain or sending settings (often labeled "Domain Authentication," "Custom Tracking Domain," or "Sender Authentication"), then paste the record it generates into your DNS the same way you'd add an SPF record.

DMARC: The Security Officer's Rulebook

What it actually does: DMARC (Domain-based Message Authentication, Reporting and Conformance) is the record that tells receiving mail servers what to do when SPF or DKIM fails, and it's also what confirms alignment — meaning the domain in your visible "From:" address actually matches the domain that SPF or DKIM authenticated.

What it looks like: A basic starting DMARC record looks like:

v=DMARC1; p=none; rua=mailto:reports@yourdomain.com

p=none means monitor only — nothing gets blocked yet, but you start receiving reports showing you who is sending mail using your domain and whether it's passing or failing. p=quarantine Sends failing mail to spam. p=reject Blocks it outright.

The order to actually do this is: Start with p=none For at least a few weeks, read the reports it generates to make sure all your legitimate sending sources show up as passing, and only then move to p=quarantine and eventually p=reject. Jumping straight to p=reject Before confirming every legitimate sender is properly authenticated, is the fastest way to have real marketing emails silently disappear.

Where to add or check it: The same DNS settings as SPF, as a TXT record with the host _dmarc.yourdomain.com.

Proof Block — Screenshot This: After setup, send a test email to a Gmail account you control, open it, click the three-dot menu, and select "Show original." Screenshot the section showing SPF: PASS, DKIM: PASS, DMARC: PASS — that single screenshot is worth more to a skeptical reader than any explanation of the concepts.

A Quick Self-Check Before You Touch Anything

Warning: Before changing any DNS record, check what's already there. Deleting or overwriting an existing SPF record instead of adding to it is one of the most common mistakes non-technical marketers make, since a domain can only have one SPF TXT record — if you paste in a new one without merging it with what's already there, you can accidentally break authentication for tools that were working fine before you started.

Quick Win

Use a free checker tool like MXToolbox or Google's Admin Toolbox before and after making any change. Paste in your domain, and it will show you your current SPF, DKIM, and DMARC records exactly as published, along with plain-language warnings if something looks broken — no DNS experience required to read the output.

FAQ

Q1. Do I need all three, or can I get away with just one? 

You need all three working together. SPF and DKIM alone don't tell receiving servers what to do when authentication fails, and DMARC, without SPF or DKIM configured underneath it has nothing to actually check.

Q2. Will setting these up break my current email sending while I'm working on it? 

Adding SPF and DKIM records doesn't interrupt anything already working, since you're adding to your DNS, not replacing your email platform's setup. DMARC is the one to be cautious with — always start at p=none so nothing gets blocked while you confirm everything is properly aligned.

Q3. I don't have a developer. Can I really do this myself? 

Yes. Every step here happens in your domain registrar's DNS panel and your email platform's settings — both are web dashboards designed for non-developers, not a code editor. The main skill required is finding the right settings menu, not writing anything from scratch.

Q4. How do I know if my current setup is already working or broken? 

Run your domain through a free checker tool like MXToolbox or send yourself a test email and check "Show original" in Gmail, as described in the Proof Block above. Both approaches show you a clear pass or fail for each of the three protocols.

Final Thoughts

None of this requires becoming a developer — it requires knowing which settings menu to open and being deliberate about the order you make changes in, especially with DMARC. Once you've got a working setup, the deeper compliance requirements — the exact spam-rate thresholds, what changed with DMARCbis in May 2026, and Gmail's specific bulk sender rules — are covered in full in our Email Deliverability Guide 2026, which builds directly on the foundation this guide just walked you through.