Do I need all three, or just one?

All three, if you can. SPF and DKIM each catch a different kind of fake email, and DMARC is the part that ties them together and tells receiving servers what to do when a message fails both. DMARC with nothing under it has nothing to act on.

What does a DMARC policy of p=none actually do?

It means "watch, don’t act." Receiving servers send you reports on which mail passed and which failed, but they still deliver the failing mail as normal. Almost everyone starts here, to make sure their real email passes before turning on stricter rules.

Why did my email land in spam even though SPF is set up?

SPF on its own isn’t enough. If DKIM is missing, if your domain is brand new with no sending history, or if the wording of your email trips a spam filter, you can still land in spam. Reaching the inbox depends on all three records plus a domain that has warmed up over time.

Can I use one DKIM key for every sending tool?

No. Each tool you send from (your newsletter platform, your cold email tool, your CRM) should get its own DKIM name and key. Sharing one key means you can’t change it for one tool without breaking the others, and most platforms create their own automatically anyway.

What happens if I turn on a DMARC reject policy too early?

If any real sender (a marketing tool, a CRM, a forwarded address) isn’t set up correctly yet, "reject" bounces that genuine mail with no warning. Move through the stages in order: watch only, then spam, then reject, checking your DMARC reports at each step.

Do tools like Mailpool, Maildoso, Infraforge, ZapMail, or Inboxkit mean I can skip learning this?

Not really. They take the manual DNS work off your plate, which helps a lot when you’re setting up many domains at once. You still want to know what each record does, so you can tell whether a deliverability problem is on your side and check that the provider set things up right. These come up in cold-email communities. They’re not a Makeinfo recommendation.

Can I set this up myself on Google Workspace or Outlook?

Yes. Both walk you through the exact lines to add in their admin settings, and for a single domain it’s usually a 15 to 30 minute job you do once. The paid providers mainly save time when you’re standing up a lot of domains and inboxes for cold outreach.

Learn GTM & Sales Automation SPF, DKIM, DMARC

Email Deliverability

SPF, DKIM, DMARC: why your emails bounce without them

Three small settings on your domain decide whether your email reaches the inbox or gets thrown out as fake. Here's what each one does in plain language, with no networking background needed.

6 comparison points 5 automated setup options ~5 min read

Picture your domain as a company that sends out mail, and every receiving server as a security desk that has never met you. SPF, DKIM, and DMARC are three ways to prove a message really came from you. Think of SPF as the list of post offices allowed to send in your name, DKIM as a wax seal that shows the letter wasn't opened or swapped on the way, and DMARC as the written note telling the security desk what to do with anything that fails both checks.

Skip them and your email either bounces or lands in spam with no error message to tell you why. Set them up and you shut down the easiest way for someone to send email pretending to be you, and you protect your reputation as a sender for every campaign after that.

What SPF, DKIM, and DMARC actually do

First, one word you'll see a lot: DNS. It's the settings panel for your domain, the same place you'd point your website. All three records are just lines of text you add there.

SPF (Sender Policy Framework) is a list of the servers allowed to send email for your domain. When a message arrives, the receiving server checks whether it came from a server on that list. If it didn't, the message fails SPF. That could be an impostor. It could also just be a new sending tool you forgot to add.

DKIM (DomainKeys Identified Mail) adds a signature to every message you send, using a secret key only you hold. You publish the matching public half in DNS. The receiving server checks the signature against it. A match tells the server two things: the message really was signed by you, and nobody changed it along the way.

DMARC (Domain-based Message Authentication, Reporting & Conformance) is the rulebook. It checks that SPF or DKIM passed and that the domain they passed for matches the "From" name the reader sees. Then it tells the receiving server what to do when a message fails: nothing yet (p=none), send it to spam (p=quarantine), or refuse it (p=reject). SPF and DKIM only report. DMARC is the one that acts.

Side by side

SPF vs DKIM vs DMARC comparison table

Aspect	SPF	DKIM	DMARC
What it checks	Is this server allowed to send email for your domain?	Does the message carry a valid signature from your domain, unchanged since it was sent?	Did SPF or DKIM pass and match the "From" name the reader sees, and what happens if not?
Where it lives	One line in your domain’s DNS settings	A line your email platform adds to DNS, under a name like `default._domainkey`	A line in DNS at `_dmarc.yourdomain.com`
What it stops	Strangers sending email as your domain from servers you never approved	Someone changing your message on the way, or faking your signature	Spoofed mail that slips past SPF or DKIM on its own
When a check fails	The receiving server might reject it, flag it, or ignore the failure. Depends how you wrote the line.	The signature just doesn’t match. DKIM by itself blocks nothing.	Your policy decides: watch only, send to spam, or reject outright.
How hard to set up	One line, but it quietly breaks if you add a new sending tool and forget to list it	Your email platform makes a key for you, and you paste the matching line into DNS	Do this one last. It only works once SPF or DKIM is already running.
Common mistake	Adding a second SPF line. Only one is allowed, so every tool goes in the same one.	Changing or removing the key without updating the DNS line to match	Jumping to "reject" before checking that your real email still gets through

Manual vs automated

Setting these up: by hand, or let a provider do it

For one domain, Google Workspace and Outlook both show you the exact lines to add in their admin settings. It's usually a 15 to 30 minute job you do once. Teams spinning up many sending domains at the same time often pay a provider to handle it instead. A recent Reddit thread on cold-email setup brought up these as options people discuss:

Mailpool

Automatic DNS at purchase, plus MCP/Claude setup

Sets up SPF, DKIM, and DMARC for you the moment you buy a domain. It also ships an MCP tool, so you can spin up sending domains and inboxes straight from Claude.

Maildoso

Bulk pre-configured inboxes for cold email

Sells bulk inboxes built for cold email. Each one arrives with SPF, DKIM, and DMARC already configured.

Infraforge

Automatic DNS for Microsoft and Google inboxes

Sets up and manages the DNS records for you across both Microsoft 365 and Google Workspace inboxes.

ZapMail

Cold-email infrastructure, setup handled for you

Cold-email infrastructure provider brought up as an option that handles setup for you instead of you editing records by hand.

Inboxkit

Cold-email infrastructure, setup handled for you

Another cold-email mailbox provider mentioned as one that takes care of authentication setup on its own.

They're listed because the community talks about them, not because Makeinfo recommends them. Check the pricing, the delivery track record, and the support yourself before you move any sending domains onto one.

Why this matters before you scale cold outreach

Mailbox providers keep a running score of how trustworthy a sender is, and they track it by domain, not by individual email. Send a lot of unauthenticated mail from one domain and that score drops fast. That's why teams doing real cold-email volume send from separate domains, kept apart from their main company domain, with SPF, DKIM, and DMARC set up on each one from day one.

Authentication is one part of a working outreach setup. The list building, the contact data, and the follow-up sequences still have to come together around it. If you're planning that fuller picture, our n8n vs Clay breakdown covers the tools teams use for the rest of it, and SuperEnrich handles lighter contact enrichment for smaller lists.

Common questions

FAQ: SPF, DKIM, DMARC, and email deliverability

Keep going

More GTM and sales automation breakdowns, built the same way.

GTM & Sales Automation → ← All resources