Email Authentication: SPF, DKIM, DMARC

Email authentication explained for sales teams

Email authentication is the set of DNS records that tie your sending domain to the messages you actually send. SPF, DKIM, and DMARC are the three load-bearing protocols. Together they answer one question every receiver asks before it routes a message to the inbox: did this mail really come from the domain in the From line, and was it altered in flight?

Direct answer. Email authentication uses three DNS records to prove your mail is legitimate. SPF lists allowed senders, DKIM signs every message with a 2048-bit key, and DMARC binds both to the From header and reports failures. Gmail and Yahoo require all three for any sender shipping more than 5,000 messages per day to consumer inboxes (Google sender requirements, 2024). Without them, bulk mail lands in spam by default.

This guide covers each protocol the way a rep or a founder running outbound actually needs them: the TXT record syntax, the policy ladder, the verification commands, and the eight mistakes that quietly cap your inbox rate. For a wider deliverability view, pair this with the cold email deliverability guide and the email deliverability glossary entry.

Why SPF, DKIM, and DMARC are mandatory in 2026

Authentication moved from best practice to gate in February 2024. Google and Yahoo jointly published bulk-sender requirements that block unauthenticated mail at the gateway. Microsoft followed in May 2025 with the same baseline. The result: a cold email program that ignores SPF, DKIM, or DMARC now starts with a spam-folder default and earns its way out, instead of starting inboxed and earning its way down.

Four numbers explain the new reality. Authenticated B2B mail clears the inbox gate at 95 percent. Unauthenticated mail draws a 5× higher spam rate post-rules. Gmail caps you at a 0.10 percent spam complaint rate before sender reputation collapses. And a sales team running Gangly ships the three records on a fresh domain in a median of 4 minutes (Gangly customer benchmark, 2026, n=212 domains).

The Authentication Trust Ladder (the Gangly framework)

The Authentication Trust Ladder is the five-layer model the Gangly deliverability team uses to set up new sending domains. Each layer compounds on the one below it. Skip a layer and the rest of the stack carries the load alone, which is what new senders consistently get wrong.

1. 1

   Layer 1: SPF

   Publish a TXT record at the apex of the sending domain that lists every IP and platform allowed to send mail as you. SPF answers the receiver question, "Was this sender on the allow list at all?"

2. 2

   Layer 2: DKIM

   Generate a 2048-bit asymmetric key pair, publish the public half as a TXT record at a named selector, and have the mail server sign every outgoing message with the private half. DKIM proves the message was not altered in flight.

3. 3

   Layer 3: DMARC

   Publish a TXT record at _dmarc that tells receivers what to do when SPF or DKIM fail and where to send the daily report. DMARC binds the From header to the authenticated domain. Without it, SPF and DKIM are advisory.

4. 4

   Layer 4: Alignment

   Force the From header domain to match the SPF Return-Path domain (relaxed or strict) and the DKIM d= tag. Misaligned auth passes SPF and DKIM individually but fails DMARC, which is the single biggest cause of new-domain spam-folder hits.

5. 5

   Layer 5: BIMI + MTA-STS

   Once DMARC sits at p=reject, publish BIMI to show a verified brand logo in Gmail and MTA-STS to force inbound TLS. Both compound the trust signal that already exists.

The five-layer view explains why partial setups fail. A domain that publishes SPF and DKIM but no DMARC passes individual checks but offers no enforcement and no reporting — the receiver has no policy to apply and the sender has no visibility into forged mail. A domain that publishes DMARC but never escalates past p=none signals to receivers that the owner is not serious about enforcement, which dilutes the trust signal. Climb the full ladder.

SPF setup: publish the TXT record that authorizes your senders

SPF (Sender Policy Framework) is a single TXT record at the apex of your sending domain that lists every IP, hostname, and platform allowed to send mail as you. It answers the receiver's first question: was this sender on the allow list at all? Publish exactly one SPF record per domain. RFC 7208 makes a second record invalidate both.

A working SPF record for a sales team running Google Workspace plus SendGrid plus Outreach looks like this:

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

Three rules to remember. First, every platform you ship from needs an include or a4 entry — forgetting one sends mail through that platform straight to spam. Second, the chain cannot exceed ten DNS lookups; flatten the includes with a tool like dmarcian if the chain grows. Third, the closing qualifier should be ~all (softfail) during the first 30 days, then -all (fail) once the platform list is locked. Using +all or ?all tells the receiver to pass any sender — worse than publishing no record at all.

DKIM setup: sign every message with a 2048-bit key

DKIM (DomainKeys Identified Mail), defined in RFC 6376, signs every outgoing message with a private cryptographic key and publishes the matching public key in DNS. Receivers verify the signature on receipt. If the signature checks out, the receiver knows two facts: the sending server held the private key, and the message body was not altered between signing and delivery.

The setup is platform-specific but follows the same four moves. Generate a 2048-bit RSA key pair on the sending platform (Google Workspace, SendGrid, Postmark, Outreach all expose a console button for this). Pick a unique selector per platform — gangly1, sendgrid1, outreach2026 — so two platforms never overwrite each other at the same DNS host. Publish the public key as a TXT record at <selector>._domainkey.<domain>. Activate signing on the platform.

Two failure modes account for almost every DKIM bug. The first is a 1024-bit key. Google began downgrading 1024-bit signatures in 2023 and now treats them as failed. Use 2048 bits and rotate the key annually. The second is selector collision — two platforms publishing google._domainkey overwrite each other in DNS, which silently breaks DKIM for both. Always pick a platform-specific selector before generating the key.

DMARC setup: enforce alignment from p=none to p=reject

DMARC (Domain-based Message Authentication, Reporting, and Conformance, RFC 7489) is the glue between SPF, DKIM, and the visible From header. It does two jobs: it tells receivers what to do when SPF or DKIM fail, and it requests aggregate reports of every message that claims to be from your domain. Without DMARC, SPF and DKIM are advisory. With DMARC at p=reject, they are policy.

The minimum viable DMARC record on day one looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100; adkim=r; aspf=r

The policy starts at p=none so nothing breaks while you inventory legitimate senders. The rua mailbox receives daily XML reports — route it to a processor (dmarcian, Valimail, Postmark) that parses the XML, because raw reports are unreadable. The adkim and aspf tags control alignment strictness; start at relaxed (r) and tighten to strict (s) once alignment audits are clean.

Escalation follows the policy ladder over 8 to 12 weeks:

1. P1

   p=none (Week 1–4)

   Monitor mode. Receivers report failures but deliver everything. Use rua= and ruf= aggregate reports to inventory every legitimate sender. Do not skip this stage on a real domain.

2. P2

   p=quarantine pct=25 (Week 5–8)

   Quarter of failing mail lands in spam. Watch the daily DMARC reports. If a legitimate sender appears in the failure list, fix its SPF or DKIM record before raising the percentage.

3. P3

   p=quarantine pct=100 (Week 9–10)

   All failing mail lands in spam. Reports should now show only forged or shadow-IT senders. Investigate every unknown source name in the rua reports.

4. P4

   p=reject (Week 11+)

   Failing mail is dropped at the gateway. The domain now publishes the strongest signal a receiver can read. Only move here after two consecutive weeks of clean quarantine reports.

BIMI and MTA-STS: the two records that compound the trust signal

BIMI (Brand Indicators for Message Identification) and MTA-STS (Mail Transfer Agent Strict Transport Security) sit at the top of the Authentication Trust Ladder. They do not replace SPF, DKIM, or DMARC, and they do not improve raw deliverability for unauthenticated mail. They compound the trust signal that already exists for senders who finished the three-record stack.

BIMI publishes a verified brand logo in DNS, paired with a Verified Mark Certificate (VMC) issued by Entrust or DigiCert. Gmail and Yahoo render the logo next to the From line for authenticated senders at p=quarantine or p=reject. Valimail's 2024 State of Email Trust report measures a 3–10 percent open-rate lift on senders that ship BIMI on top of clean DMARC. The cost is a $1,500–$2,000 annual VMC and a registered trademark.

MTA-STS forces receivers to send inbound mail to your domain over TLS only, with the policy published at https://mta-sts.<domain>/.well-known/mta-sts.txt. It does nothing for outbound deliverability but closes a man-in-the-middle hole that opportunistic TLS leaves open. For a sales team that wins large enterprise deals, the procurement security review almost always asks for it. Ship both records after DMARC sits stable at p=reject for 30 days.

Verify the records with a five-command audit

Five commands answer every authentication question a sales team has about a sending domain. Run them after every DNS change and before every campaign launch. Three are terminal commands; two are inbox-side checks. The full sweep takes under three minutes.

# 1. Confirm SPF is published and contains every sending platform
dig +short TXT example.com | grep spf1

# 2. Confirm DKIM is published at the active selector
dig +short TXT gangly1._domainkey.example.com

# 3. Confirm DMARC policy and report endpoint
dig +short TXT _dmarc.example.com

# 4. Send a synthetic message to a Gmail seed inbox and open "Show original"
#    Expect: SPF=PASS, DKIM=PASS, DMARC=PASS, Alignment=PASS

# 5. Check the DMARC aggregate report mailbox for new failing sources
#    Expect: only senders you recognize

The Show original view in Gmail is the receiver-truth check. If the four pass lines are present, the receiver accepted the authentication. If any line shows FAIL or NEUTRAL, fix the underlying record before the next send. Gangly customers run this sweep weekly as part of the deliverability cadence, which is why authentication regressions surface in days rather than after a campaign already damaged reputation.

Eight authentication mistakes that quietly send mail to spam

Eight failure modes account for the overwhelming majority of authentication regressions across the Gangly customer benchmark, 2026. Each one is one DNS edit away from a fix. Run this list before you debug anything else.

1. 1

   Multiple SPF records on the same host

   RFC 7208 allows exactly one SPF TXT record per domain. A second record makes both invalid. Merge the include: list into one record.

2. 2

   SPF +all or ?all

   Both qualifiers tell the receiver to pass mail regardless of source. Use ~all during testing and -all once the include list is locked. Anything looser is worse than no record.

3. 3

   More than ten SPF DNS lookups

   RFC 7208 caps the include and redirect chain at ten lookups. Receivers return a permerror when you exceed the limit. Flatten the chain with a service like dmarcian or remove unused senders.

4. 4

   DKIM key shorter than 2048 bits

   Google began downgrading 1024-bit keys in 2023 and now ignores them outright. Generate a fresh 2048-bit key on every platform and rotate annually.

5. 5

   DKIM selector collision across platforms

   Two platforms publishing google._domainkey overwrite each other. Pick a unique selector per platform (gangly1, sendgrid1) so receivers can resolve the right public key.

6. 6

   DMARC without aggregate reporting

   A DMARC record without rua= is a black box. You have no idea which senders are failing until reps complain. Always publish a rua mailbox or a third-party DMARC processor.

7. 7

   Jumping straight to p=reject

   New domains that publish p=reject on day one block half their own mail. Climb the policy ladder over 8–12 weeks while the aggregate reports inventory every legitimate sender.

8. 8

   Ignoring DMARC alignment

   Mail can pass SPF and DKIM but still fail DMARC when the From header domain does not match the authenticated domain. Set adkim=s and aspf=s only after both alignment paths are clean.

Five of the eight involve a partial setup that passes a casual inbox check but fails alignment under load. The other three are policy choices that look bold and end up self-inflicted (the SPF soft pass, the early p=reject, the absent rua). Treat the list as a pre-launch checklist on every new sending domain.

Verdict. Most teams that hit a spam-folder wall did not publish bad records. They published partial records, never escalated DMARC past p=none, and never reviewed an aggregate report. The fix is not more authentication — it is finishing the ladder.

How Gangly fits the email authentication workflow

Authentication is the deliverability floor. The work that earns the inbox sits above it: signal-led targeting, warm sequences, and the discipline to stop sending when reply rates drop. Gangly automates the parts of the rep workflow that quietly damage authentication when they go wrong — adding senders without updating SPF, rotating platforms without rotating DKIM keys, scaling sequences without watching the DMARC aggregate report.

• Outreach Writer — ships every send through authenticated sender pools and rejects messages from unaligned domains before they leave the gateway.
• Workflow Sequencer — caps sequence volume on any domain whose Postmaster Tools spam rate crosses the Gmail 0.10 percent threshold, which protects authentication ROI.
• Signal Detection — ranks the inbox you should earn first, so the authenticated send goes to the prospect most likely to reply rather than a cold list that will drive a complaint rate.

Pair the three product surfaces with the wider deliverability stack documented in the cold email deliverability guide and the cold email warmup guide. For a glossary anchor on the next term, the domain reputation entry explains how authentication compounds with sender history. To see the full sales workflow that holds the cut, start a free trial or book a demo.