March 2, 2026

SPF, DKIM, DMARC: what they do and why they matter for outbound

A practical explanation of SPF, DKIM, and DMARC, how they work together, and why they matter for deliverability.

Most deliverability problems are identity problems. If receiving servers cannot verify that you are allowed to send as your domain, you are asking them to trust a stranger wearing your name tag.

SPF, DKIM, and DMARC are the three acronyms that decide whether your outreach hits inbox, lands in spam, or gets rejected outright. They are not "nice to have." They are table stakes.

1) The one-sentence version (what each thing does)

SPF: "These servers are allowed to send email for my domain."
DKIM: "This message was signed by my domain and was not altered in transit."
DMARC: "Only accept mail that proves it is really from my visible From domain, and here is what to do if it fails."

Think of it as paperwork for email identity. Boring, but necessary.

2) Why it matters now (providers stopped being lenient)

Providers like Gmail have made authentication part of their baseline sending requirements. Google explicitly requires SPF or DKIM for all senders, and SPF + DKIM + DMARC for bulk senders. The bulk sender threshold is 5,000 messages/day to Gmail accounts.

If you want predictable deliverability at scale, SPF/DKIM/DMARC are not optional. You set them up, then you earn trust with sender reputation over time.

3) How it works in reality (a concrete walkthrough)

Say you send an email that shows: From: adam@outloopteam.com

When Gmail (or any receiver) gets it, it will typically evaluate:

A) SPF check (who sent it?)

SPF is checked against the sending server and the "envelope sender" (the return-path / mail-from), which is not always the same as the visible From address.

If your SPF record says "Google Workspace is allowed to send," and the message really came from Google, SPF passes.

B) DKIM check (was it tampered with?)

DKIM adds a cryptographic signature to the message. The receiver pulls your public key from DNS and verifies the signature. If the message was altered in transit, verification fails.

C) DMARC check (does it match the visible From?)

DMARC checks whether the domain that passed SPF or DKIM is aligned with the domain shown in the From header. Attackers can spoof the visible From address. DMARC tells receivers to only accept mail when the authentication ties back to that same From domain.

Practical mental model: SPF and DKIM are proofs. DMARC is the rule for how those proofs must match what the recipient actually sees.

4) The common mistakes that quietly ruin deliverability

Most setups fail quietly, not loudly. A few patterns that come up repeatedly:

"SPF is set, so I'm done." SPF only covers part of the picture. It authenticates the sending server, not necessarily the address the recipient sees in their inbox. DMARC checks whether those two things match. If they do not, you can still fail.
DKIM left off. Many people connect a domain and start sending without realizing DKIM is not on by default. It needs a DNS record added and usually a manual switch flipped inside your email provider.
Multiple SPF records on the same domain. You can only have one. Two records means receivers see a broken setup and may treat your mail as untrustworthy.
Too many services piled into one SPF record. SPF has a hard limit on how many sources it can reference. Add enough tools and you quietly break your own record.
DMARC set to monitor mode and never touched again. Starting in monitor mode is fine. It lets you see what is happening without blocking anything. But if you never move past it, you are not actually protected, and some receivers know it.

5) A sane setup order

The order matters because each layer builds on the one before it.

Step 1: Tell the internet which servers are allowed to send email for your domain (SPF).
Step 2: Set up message signing so receivers can verify your emails were not tampered with in transit (DKIM).
Step 3: Add a policy that ties steps 1 and 2 to your actual From address, and start in monitor mode so you can see what is passing and failing before anything gets blocked.
Step 4: Once you are confident everything is set up correctly, tighten the policy so failing mail gets blocked.

If you are doing outreach, this is not admin overhead. It is the difference between landing in someone's inbox and getting silently discarded before they ever see your name.

6) Where Outloop fits

Outloop started as a tool for running outreach cleanly inside Gmail. Even if your setup is simple, the fundamentals still matter: if SPF/DKIM/DMARC are missing or misaligned, inbox placement becomes unpredictable fast.

The reason we're publishing this is straightforward: most outreach problems are diagnosed too late. Teams adjust copy, volume, and targeting, but the domain fails basic authentication checks, so the campaign is fighting with one hand tied behind its back.

Use authentication as a baseline check before you scale any outbound.
Validate that SPF or DKIM passes, and that DMARC alignment is correct for your From domain.
If you are unsure, start with DMARC in monitoring mode (p=none), then tighten once you confirm legitimacy.

Whether you use Outloop, a spreadsheet, or another tool entirely, this part doesn't change. Authentication is the difference between "our emails are landing" and "we think our emails are landing."

TL;DR

SPF authorizes which servers can send for your domain.
DKIM signs messages so receivers can verify integrity and origin.
DMARC ties authentication back to the visible From domain, defines what to do on failures, and provides reporting.
Providers like Gmail explicitly require authentication, and bulk sending raises the bar.
Set up SPF + DKIM first, then DMARC (start in monitor mode, tighten later).