Email authentication for growing senders: SPF, DKIM and DMARC in practice

Why growing senders need a serious authentication posture

There is a natural moment in every sending program where authentication stops being "something we set up once and forgot." Usually it arrives when volume crosses a threshold — a marketing program that starts sending hundreds of thousands a month, a transactional platform that moves into a regulated industry, a company that starts seeing its brand spoofed in phishing campaigns. Whatever the trigger, the common thread is that the cost of a sloppy authentication setup has finally started to outweigh the effort of fixing it.

Two forces are driving this shift. The first is mailbox providers becoming stricter about what they accept. Over the past several years, Google, Yahoo, Apple and Microsoft have all moved in the direction of treating authentication failures as a reason to filter, not just a reason to downrank. Signals point toward more formal enforcement coming — not less. The second is regulatory pressure: PCI DSS 4.0, published in 2022, explicitly requires email authentication controls for payment environments, and similar language is appearing in enterprise procurement questionnaires across industries.

The practical consequence is that authentication is no longer a deliverability bonus; it is the entry fee. The question for growing senders is not whether to invest in it, but how to do it correctly the first time without the common mistakes that make the investment expensive to unwind later. If ongoing authentication and reputation work is not something the team can absorb, managed deliverability is the service pattern that covers it.

The three protocols and what each one does

Before the specifics, the sixty-second version of each protocol. Understanding what each one covers — and what it does not — is the foundation for every decision that follows.

The single most important word in that table is alignment. SPF and DKIM were designed independently and each solves a narrow problem. Before DMARC existed, a spammer could pass SPF by using their own domain in the envelope-from, pass DKIM by signing with a completely unrelated domain, and still put your domain in the visible From header that the recipient actually sees. DMARC closes that gap by requiring one of the two underlying authentications to match the From the recipient sees.

This is why publishing SPF alone, or DKIM alone, is insufficient for a growing sender. Both have known evasion paths that only DMARC alignment blocks. The three together produce a posture that mailbox providers can verify and that attackers cannot impersonate.

SPF: what to publish and what to avoid

SPF is a single DNS TXT record at the root of your domain. It lists every server and service that is authorized to send mail using your domain in the envelope-from. Mailbox providers check the record when they receive mail and use the result as one signal in their filtering decision.

A basic SPF record, annotated

DNSexample.com.  IN  TXT  "v=spf1 include:_spf.google.com include:spf.authorizehosting.com -all"

The mechanisms in this record are, in order: declare SPF version 1 (v=spf1), authorize servers listed in Google Workspace's SPF record, authorize servers listed in your transactional relay's SPF record, and hard-fail (-all) anything not explicitly authorized. The hard fail matters: it tells receivers that if a server is not in the list, the message is definitively not legitimate.

The soft fail versus hard fail debate

Some guides still recommend ~all (soft fail) over -all for new SPF records. In 2023 this advice is mostly obsolete for production sending. A soft fail tells receivers "probably not legitimate, but process DKIM and DMARC before deciding." A hard fail tells them "definitively not legitimate." For well-maintained records, hard fail is the correct posture. Soft fail is a reasonable transitional choice during initial rollout while you confirm you have catalogued every sending source, but the destination should be a hard fail.

Common SPF failure modes

• Multiple TXT records at the root. Only one SPF record is allowed per domain. Publishing a second one (common during platform migrations) silently invalidates both.
• Wide CIDR blocks. Authorizing ip4:203.0.113.0/16 to cover a provider's range gives sending permission to everyone else in that range. Prefer include: mechanisms that let the provider maintain their own list.
• Expired includes. A provider you stopped using three years ago is still in your SPF record. Every audit finds at least one.
• Missing subdomain records. SPF does not inherit down to subdomains the way DMARC does. mail.example.com needs its own record; the parent's record does not cover it. For the broader picture of how authentication interacts with reputation as programs grow, see IP reputation planning for expanding programs.

DKIM: signing, selectors and key hygiene

DKIM adds a cryptographic signature to every outgoing message. The signature proves two things: the message has not been modified in transit, and it was signed with a key that belongs to the declared signing domain. Receivers fetch the public key from DNS, verify the signature, and use the result as another signal in filtering.

Unlike SPF, DKIM can span multiple domains and selectors, which is both its main strength and its main complexity. A selector is just a label that lets a domain have multiple DKIM keys in rotation. A typical production domain has anywhere from two to a dozen selectors, one per sending source.

DNSgoogle2023._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
ahk1._domainkey.example.com.        IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
helpdesk._domainkey.example.com.    IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Key length: 2048 is the baseline

A DKIM key is an RSA key pair. The published record contains the public half; the private half stays with the provider who does the signing. Key length used to be 1024 bits by default everywhere; that baseline has moved to 2048 bits. Mailbox providers increasingly treat 1024-bit keys as weak — not rejected outright in most cases, but flagged in evaluation. Any new DKIM setup in 2023 should start at 2048. Existing 1024-bit keys should be on a migration plan, rotated at the next opportunity.

Selector hygiene

Every sending source needs its own selector. The reason is simple: if a key is compromised or a provider relationship ends, you can retire the selector without affecting anyone else. Mixing multiple sources under a single selector turns every key rotation into a coordinated engineering event.

1. Name selectors with a provider prefix and a rotation marker. google2023 is better than key1. The name should tell you which provider uses it and when it was issued.
2. Rotate annually. A rotation schedule of 12-18 months keeps keys fresh without creating operational noise. Most providers offer scheduled rotation; enable it.
3. Leave the old selector published during rotation. Messages in flight signed with the old key need to verify until they are delivered. A one-week overlap is standard.
4. Document selectors centrally. A table of "selector name, provider, issued, next rotation" saves the on-call engineer at 2 a.m. when a DMARC report flags unexpected activity.
5. Retire unused selectors. A selector that has not signed mail in six months should be removed. Old published keys are a small attack surface; do not carry them longer than necessary.

What DKIM does not do

DKIM does not authenticate the visible From header. A message signed by d=unrelated-domain.com passes DKIM validation even if the visible From says support@yourbank.com. This is exactly the gap that DMARC was designed to close. Any deliverability engineer who says "we have DKIM, we're fine" without mentioning DMARC alignment is missing the actual point of the setup.

DMARC alignment, plainly explained

DMARC ties SPF and DKIM together by requiring at least one of them to align with the visible From header. Alignment comes in two flavors — strict and relaxed — and understanding which one you need is the authentication decision that most often gets made wrong.

Relaxed is the correct default for most programs. It allows mail.example.com in the d= to align with support@example.com in the From, which is exactly how most legitimate multi-source programs work. Strict is the right choice when every message from a domain will always sign with an exactly-matching d= value, and the sender wants the tightest possible posture against spoofing.

Why alignment matters more than authentication

A message can pass SPF and DKIM, and still fail DMARC. The reason is alignment. Consider a common scenario: a marketing ESP sends on your behalf. The envelope-from is bounces.esp.com so SPF authenticates against the ESP's own domain. The DKIM signature might be signed with the ESP's domain too. SPF passes. DKIM passes. But because neither one aligns with your visible From header, DMARC fails.

The fix is to configure the ESP to sign with your domain (custom DKIM) or to use a custom MAIL FROM (custom return path). Reputable providers support both. Growing senders who find themselves in this situation should treat it as a priority: unaligned mail from third parties is exactly the kind of traffic that DMARC at p=quarantine or p=reject will start rejecting.

DMARC policy progression: none, quarantine, reject

The three DMARC policies describe what a receiving server should do when alignment fails. The correct path is a gradual progression, not a jump.

The progression in practice

Start with a p=none record that includes a reporting mailbox. Do not move until you have seen reports from at least a full calendar month and recognized every source in them. The reports will almost always reveal sending sources you did not know about — an automated alerting system, a legacy CRM integration, a vendor who sends on your behalf. Catalogue each one and confirm it should keep sending. Then move to p=quarantine with a partial pct=25 if you want to start conservatively; raise the percentage over two or three weeks. Then to p=quarantine at pct=100. Then, after another month of clean reports, to p=reject.

DNS# Stage 1 — monitoring
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"

# Stage 2 — partial quarantine
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com; fo=1"

# Stage 3 — full quarantine
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; fo=1"

# Stage 4 — full enforcement
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; fo=1; adkim=r; aspf=r"

Research from DMARC monitoring providers published in 2023 suggests that fully enforced p=reject senders see meaningfully better inbox placement than p=none senders at equivalent volumes. The effect is not huge per message, but it compounds across millions of sends. Combined with the reputational protection of not being a spoofable brand, the case for ending up at p=reject is strong for any sender above modest volume.

Reading aggregate reports without drowning

DMARC aggregate reports arrive as compressed XML files, one per mailbox provider per day, sent to the address you listed in the rua tag. Read as raw XML, they are unreadable. The two ways to handle them are a paid monitoring service or a self-hosted parser. Both are valid; neither is optional if you are above p=none.

What a useful DMARC dashboard surfaces

• Volume per sending source. How many messages claim to be from your domain, and who is sending them.
• Alignment pass rate per source. SPF-aligned percentage, DKIM-aligned percentage, DMARC overall percentage.
• Policy outcomes. Delivered, quarantined, rejected — per-source, per-day.
• Anomalies. New sources appearing out of nowhere, established sources changing alignment behavior, volume spikes.
• Geographic distribution. Unusual patterns (sending from regions where you do not operate) often flag spoofing attempts or compromised vendor systems.

The first report-reading week will surface surprises. Treat surprises as discoveries, not as emergencies. A legitimate sender who appears in your reports without alignment is a problem to solve, but solving it requires understanding it first. Rushing to p=reject while unsolved sources are still in the data is how you stop your accounting team's invoices from landing at customers' email addresses. For the wider set of signals that should feed into this review — not just DMARC reports but bounce rates, complaint patterns and ISP feedback — see deliverability monitoring that catches problems before they scale.

Subdomains, parked domains and policy inheritance

DMARC policy applies to a specific domain, but subdomains inherit it by default. That inheritance is useful most of the time and annoying some of the time, and understanding when each applies saves a lot of debugging.

Subdomain inheritance, with the override escape hatch

If you publish p=reject at _dmarc.example.com, every subdomain inherits that policy unless it has its own _dmarc.<subdomain> record. The root record also accepts a sp= tag that specifies a different subdomain policy. If most of your mail comes from mail.example.com and is well-authenticated, but you want a looser policy for miscellaneous subdomains that you have not audited, use sp=none at the root while keeping p=reject for the root itself.

DNS# Root domain at reject; subdomains get a looser monitoring policy
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@example.com"

# After the subdomain is audited, publish its own record to tighten it independently
_dmarc.mail.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Parked domains: the often-forgotten attack surface

Any domain your organization owns but does not send mail from is a potential spoofing target. An attacker who discovers an unused domain with no DMARC record can send phishing mail that appears to come from your brand and will pass authentication trivially because there is none to check against.

The fix is to publish authentication records on every parked domain that say "this domain never sends mail." The M3AAWG industry guidance for parked domains has been stable since 2018 and is worth following:

DNS# SPF: no mail ever comes from this domain
parked-example.com.  IN  TXT  "v=spf1 -all"

# DKIM: explicit null key
*._domainkey.parked-example.com.  IN  TXT  "v=DKIM1; p="

# DMARC: reject everything
_dmarc.parked-example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Publishing these three records takes ten minutes per parked domain and closes a real attack vector. Growing organizations often own dozens of parked domains from old campaigns and acquisitions; auditing and locking them down is a worthwhile afternoon of work. For programs that legitimately send from many sibling domains rather than parked ones, the complementary read is authentication alignment and policy review for multi-domain senders.

Third-party senders and the alignment trap

The most common reason legitimate mail fails DMARC is third-party senders who were never configured for alignment. Marketing platforms, help desks, calendar invites, HR tools, accounting software, survey platforms — anything that sends on your behalf lives in this category, and each one needs to be handled.

The audit exercise every growing sender should do

Before tightening DMARC past p=none, inventory every third-party service that sends email as your domain. The list is usually longer than people expect. A rough audit method: look at aggregate reports for a month, list every source, and verify that each one is either (a) authorized and properly configured for alignment, or (b) unauthorized and should be blocked. Do not skip sources that appear at low volume; small volumes of unaligned mail are often the canary for a compromised credential or a forgotten integration.

BIMI and what authentication unlocks next

Once a domain is at p=quarantine or p=reject with clean alignment, new capabilities become available. Brand Indicators for Message Identification (BIMI) is the most visible of them: a small logo that appears next to your messages in supporting mailbox clients, signaling that the message is authenticated and the brand is who it claims to be.

The requirements for BIMI are straightforward on paper and involved in practice:

1. DMARC at p=quarantine or p=reject — the whole point of BIMI is that the logo is only shown for authenticated mail, so weaker DMARC policies disqualify the domain.
2. A square SVG logo in the BIMI profile format — a specific SVG subset, hosted on HTTPS at a URL you control.
3. A published BIMI TXT record at default._bimi.domain pointing at the logo and (in most cases) a certificate.
4. A Verified Mark Certificate (VMC) from a recognized authority, proving the brand owns the logo. Apple's implementation requires this; Gmail's requires it for non-trademarked logos.
5. Ongoing alignment discipline — any drop back to p=none disables the logo immediately.

BIMI is currently supported by Gmail, Yahoo, Apple Mail (since early 2023), Fastmail and a growing list of other providers. The visual effect is small but consistent: a branded logo in the message list improves open rates modestly, and more importantly it reinforces brand recognition in a channel that is otherwise hostile to branding.

For growing senders, BIMI is not urgent, but it is a good marker of a mature authentication posture. Teams that can check all five boxes above have clearly done the groundwork; teams that cannot should focus on that groundwork first and leave BIMI for after.

Frequently asked questions

Is SPF or DKIM enough on its own?

No. Each one authenticates a different layer and each one has known evasion paths that DMARC closes. A serious sender publishes all three, and makes sure alignment is clean.

How long should we stay at p=none before moving to quarantine?

At least 30 days, preferably 60. The goal is to have at least one full monthly cycle of aggregate reports, enough time to recognize every legitimate source, fix alignment for the important ones, and understand the tail of small-volume senders. Moving faster than 30 days almost always produces surprises at quarantine.

Should we include the pct= tag in our DMARC record?

Only at the quarantine stage, and only as a transitional measure. pct=25 when moving from p=none to p=quarantine softens the transition while you monitor reports; raise the percentage over two to three weeks until it reaches 100. The pct= tag has no effect at p=none and should be removed once at p=reject.

What does fo=1 mean in the DMARC record?

It controls when failure (forensic) reports are generated. fo=0 (default) generates reports only when both SPF and DKIM fail. fo=1 generates reports when either one fails. For growing senders still catching alignment issues, fo=1 is more useful because it surfaces DKIM-only failures and SPF-only failures separately, which is often diagnostically important.

Can we skip DMARC if our mail is all transactional?

No. Transactional mail is exactly the mail that phishers most want to impersonate — password resets, billing notifications, account alerts. A transactional-only domain without DMARC is a high-value spoofing target. The authentication posture for transactional should be as strong as for marketing, and arguably stronger.

Our ESP says it handles DMARC for us. Is that enough?

Usually not. The ESP can handle alignment for the mail it sends, but DMARC is a policy on your domain that applies to every sender. If other systems also send as your domain (and they almost always do), those need to be aligned separately. The ESP's assurance is necessary but not sufficient.

Do we need BIMI to get to p=reject?

No. BIMI is an additional capability that authentication unlocks, not a prerequisite. Many mature programs stay at p=reject without BIMI because the brand-mark certificate cost does not justify the visible benefit. The authentication work is the same either way.

Closing perspective

There is a quiet bias in how teams think about authentication work: it looks like infrastructure that nobody asked for, paid for by engineering time that could have shipped features. That framing is understandable and backwards. Authentication is not an infrastructure cost; it is a deliverability multiplier that compounds for every message your brand ever sends.

The programs that treat SPF, DKIM and DMARC as project work — set up once, forgotten — are the ones that discover alignment problems the hard way, when a quarterly marketing campaign silently stops hitting inboxes because a vendor changed their sending infrastructure six months ago. The programs that treat authentication as an ongoing practice — audited quarterly, reports read weekly, policies progressed deliberately — are the ones whose inbox placement stays stable while the ecosystem tightens around them.

The signals point clearly in one direction. Mailbox providers are getting stricter, not looser. Regulatory frameworks are adding email authentication requirements, not removing them. The gap between well-authenticated senders and everyone else is widening, and that gap shows up directly in inbox placement and in reputational exposure when brand spoofing happens. A growing sender who invests in authentication posture now is buying defensibility for the next several years of changes, not just solving today's problem.

Do the basics first and do them well. SPF with a hard fail and a clean include list. DKIM with 2048-bit keys and per-source selectors. DMARC starting at monitoring, progressing to enforcement, with reports read by someone whose job includes reading them. Subdomain and parked-domain hygiene. Third-party sender alignment. That sequence is not glamorous, but it is durable — and for growing senders in late 2023, durability is exactly what the industry seems to be rewarding.