SPF, DKIM, and DMARC: A Practical Guide to Email Authentication and Deliverability

Getting a message accepted by the receiving server is only half the job. The other half is landing in the primary inbox instead of the spam folder. That second half is what email authentication buys you.

Delivery is not deliverability

These two words get used interchangeably, and the difference matters.

Delivery answers one question: did the receiving mail server accept your message? Did it get through the front door?

Deliverability is about where the accepted message ends up: the primary inbox, the promotions tab, or the junk folder.

Outbound email sent
        |
     Delivery  (accepted by server)
        |
   +----+----+
   |         |
 Inbox     Spam / Junk
(good      (poor
 placement) placement)

When deliverability slips, the cost is real. Password resets, receipts, and account alerts that land in spam bury your support desk in "I never got the email" tickets. Marketing that never reaches the inbox earns nothing. And Gmail, Outlook, and Yahoo all score your sending domain's reputation over time. Once that score drops, clawing it back is slow work.

Why authentication became mandatory

SMTP was designed in an era that assumed everyone on the network was trustworthy, so it never checked who was actually sending a message. Spammers turned that gap into spoofing: forging your address to impersonate your brand. Mailbox providers responded with strict identity checks, and today authentication is a requirement, not a nice-to-have.

Three protocols do the work, each covering a different angle:

Set all three up correctly and you give receiving servers a solid reason to trust you.

SPF: who is allowed to send

An SPF record is a DNS TXT record listing every IP address, hostname, and third-party service authorized to send mail using your domain. When a server receives a message claiming to be from [email protected], it looks up your SPF record. If the sending IP matches something on the list, SPF passes.

Setting it up:

1. Audit your senders. List every service that sends on your behalf: Google Workspace, Microsoft 365, Mailchimp, Salesforce, Zendesk, and so on.
2. Draft one record. Combine those sources into a single string. For example:

v=spf1 ip4:192.0.2.1 include:_spf.google.com include:thirdparty.com ~all

3. Publish it as a TXT record at your root domain (@) through your DNS provider. The SPF Generator will assemble the syntax for you.

Two mistakes cause most SPF failures:

• Never publish more than one SPF record for a domain. Two records invalidate the check entirely.
• Watch the 10-lookup limit. SPF allows a receiving server at most 10 DNS lookups per evaluation. Stack too many nested include: tags and you get a PermError, which counts as a failure. If you hit that ceiling, an SPF flattening tool collapses those includes into direct IPs.

DKIM: proving the message wasn't tampered with

Where SPF validates the sending server, DKIM validates the message itself. It uses public-key cryptography to attach an invisible signature to every outbound email's headers.

Outbound mail server
   signs headers with PRIVATE key
        |
Receiving mail server
   fetches PUBLIC key from DNS
   validates the signature
        |
   pass / fail

Your server signs each message with a private key. The receiver fetches your public key, published in DNS, and checks the signature. If it matches and nothing was altered in transit, DKIM passes.

Setting it up:

1. Generate the key pair in your provider's admin console (Google Workspace, Microsoft 365, etc.) under the DKIM settings.
2. Note the selector. The provider hands you a prefix like google or k1. That becomes part of the record's hostname.
3. Publish the public key as the DKIM record your provider specifies, usually a CNAME or TXT record at selector._domainkey.yourdomain.com.
4. Turn on signing back in the provider console once the DNS record has propagated.

DMARC: tying it together and taking control

SPF and DKIM run independently. DMARC binds them to your domain and decides what happens when a message fails. Without it, a spoofed message that fails SPF leaves the receiving server to guess whether to deliver or drop it. DMARC makes that call for them.

The p= tag sets your policy:

• p=none — monitoring. Failing messages are delivered as normal, but you receive aggregate reports at the address in your rua tag.
• p=quarantine — failing messages go to spam or junk.
• p=reject — failing messages are blocked outright at the gateway.

Roll it out in stages rather than jumping straight to reject:

Phase 1: Monitor          Phase 2: Partial          Phase 3: Enforce
v=DMARC1; p=none;    =>    v=DMARC1; p=quarantine;  =>  v=DMARC1; p=reject;
collect reports           spoofs to junk              spoofs blocked

Step by step:

1. Start with monitoring. Publish a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:[email protected];

The DMARC Generator builds this for you.

2. Read the reports. Feed the incoming XML into a DMARC Report Parser over two to four weeks. Look for legitimate services that are failing, then fix their SPF or DKIM.
3. Move to p=quarantine once your real mail streams pass authentication reliably.
4. Finish at p=reject. At that point your domain is protected against direct-domain spoofing.

Where to start

If you only do one thing today, publish an SPF record and a p=none DMARC record so you can see what's actually sending as your domain. From there, add DKIM, read the reports, and tighten the policy as your legitimate senders line up. Run the whole stack through an Email Health Check to confirm SPF, DKIM, and DMARC all resolve and pass before you enforce anything.