BUY WEBSITES
BUY DOMAINS
LOGIN
SIGNUP
SPF, DKIM, and DMARC for Aged Domains: How Email Authentication Works, and the Records a Domain Inherits When It Changes Hands
SPF, DKIM, and DMARC are the three DNS-published standards that prove a message genuinely came from the domain it claims. Together they are how a receiving mail server decides whether a domain is a real operator or a forgery, and since February 2024 both Google and Yahoo require all three from any sender that reaches the inbox at volume.
The common guides explain the trio on a fresh domain set up from scratch. An aged domain differs in one decisive way: it arrives with a record set the previous owner published. A stale SPF include, an orphaned DKIM selector, and a DMARC record pointing at a reporting mailbox that no longer exists are all part of what transfers the day a domain changes hands.
This guide does both jobs. It explains how each of SPF, DKIM, and DMARC works, with real record syntax and the alignment detail the three-pillars explainers skip, and it covers the part only an acquisition raises: auditing and resetting the authentication a domain carries forward. SEO Domains operates the curated marketplace where a domain’s mail history is screened before listing, so the record set at the start is a clean slate instead of a cleanup job.
What SPF, DKIM, and DMARC are, and what each one does
SPF, DKIM, and DMARC are three email authentication standards a domain publishes as DNS records. SPF, the Sender Policy Framework, lists which servers are permitted to send mail for the domain. DKIM, DomainKeys Identified Mail, attaches a cryptographic signature that proves a message was not altered and came from the domain. DMARC, Domain-based Message Authentication, Reporting and Conformance, ties the first two to the visible From address, sets the action receivers take when a message fails, and collects reports.
Each standard answers a different question a receiving server asks about an incoming message. SPF answers whether the sending server was authorized. DKIM answers whether the message is intact and genuinely signed by the domain. DMARC answers whether those checks line up with the address the reader sees, and what the domain owner wants done if they do not.
The one job each standard does
The three are frequently described as overlapping, which is where the confusion in the search results starts. They do not overlap. They stack. SPF and DKIM each produce an independent pass-or-fail result, and DMARC reads both results, applies an alignment test, and enforces a policy. Removing any one leaves a gap a forger can use.
SPF: which senders are allowed
A DNS TXT record listing the IP addresses and services permitted to send mail for the domain. The receiver checks the sending server against the list. Defined in RFC 7208.
DKIM: was the message genuine and intact
A cryptographic signature added to the message header, verified against a public key the domain publishes in DNS. It proves the message was signed by the domain and not altered in transit. Defined in RFC 6376.
DMARC: tie it to the From address and decide
A DNS TXT record that requires SPF or DKIM to align with the visible From domain, sets a policy for failures, and requests reports. Defined in RFC 7489.
Together: one provable identity
A receiver reads all three to judge whether the domain is a real, operated sender. EmailLabs describes the set as one coherent identity by design, not three unrelated switches.
Why aged domains make the inheritance the real subject
On a brand-new domain all three records are written on a blank slate. On an aged or expired domain that is not the case. The name already lived a life, and the DNS records from that life can still be published when the domain transfers. The rest of this guide keeps that distinction sharp, because it is the part the established three-pillars guides never reach.
How SPF works: the authorized-sender list in DNS
SPF, the Sender Policy Framework, is a single DNS TXT record that names every IP address and service authorized to send mail for the domain. When a message arrives, the receiving server reads the envelope sender domain, looks up its SPF record, and checks whether the connecting server is on the authorized list. SPF is defined in RFC 7208, and its result feeds DMARC.
The record, field by field
An SPF record is a string published at the domain’s root. It begins with the version tag and ends with an all mechanism that states the verdict for any server not explicitly listed. A representative record reads:
The version is v=spf1. The include mechanism delegates to another provider’s SPF, here Google Workspace, so its mail servers count as authorized. The ip4 mechanism adds a specific address. The closing -all is a hard fail, meaning any server not matched is treated as unauthorized. A softer ~all marks unmatched mail as a soft fail instead.
The ten-lookup limit, the trap that breaks SPF
RFC 7208 caps an SPF check at ten DNS lookups. Every include mechanism that points at a provider counts against the limit, and nested includes count too. A domain that stacks a marketing platform, a help desk, and a payment processor can quietly cross ten lookups, at which point the SPF evaluation returns a permanent error and the check stops passing. Valimail flags excessive SPF lookups as a leading hidden cause of authentication failure.
This trap matters doubly on an aged domain, because the inherited include list was written for the previous owner’s tools, not the new owner’s. An include for a service no longer in use still burns a lookup.
How DKIM works: the cryptographic signature
DKIM, DomainKeys Identified Mail, attaches a digital signature to outgoing messages using a private key held by the sending service. The matching public key is published in DNS at a named selector. A receiving server recomputes the signature with the public key and confirms the message was signed by the domain and unaltered in transit. DKIM is defined in RFC 6376, and its result, like SPF, feeds DMARC.
Selectors, keys, and the signature header
DKIM splits a key pair across two locations. The private key stays with the sending service and signs each message, adding a DKIM-Signature header. The public key is published as a DNS TXT record at a selector, a label the sending service chooses, in the form selector._domainkey.example.com. The signature header names the domain in a d= tag and the selector in an s= tag, so the receiver knows precisely which public key to fetch.
The d= tag carries the signing domain, the s= tag the selector, and the b= tag the signature itself. The receiver looks up mail2026._domainkey.example.com, retrieves the public key, and verifies. A match means the message is intact and genuinely from a service holding the domain’s private key.
Why selectors are where aged domains trip
Because the selector is named by the signing service, a domain can carry more than one DKIM public key at a time, one per service it has used. An aged domain commonly arrives with selectors from the previous owner’s providers still published in DNS. Those orphaned keys are not dangerous on their own, but they are clutter, and a key whose private counterpart is gone signs nothing. The work on acquisition is to publish a fresh selector and retire the inherited ones that no longer sign anything.
How DMARC works: policy, alignment, and reporting
DMARC, Domain-based Message Authentication, Reporting and Conformance, is the DNS record that makes SPF and DKIM enforceable. It requires at least one of them to align with the domain in the visible From header, sets a policy for what receivers do when a message fails, and requests reports. DMARC builds on both SPF and DKIM and is defined in RFC 7489. dmarc.org describes it as helping receivers determine whether a message aligns with what they know about the sender.
Alignment, the concept the three-pillars guides skip
This is the mechanic the bulk of explainers omit, and it is the one that makes DMARC work. SPF and DKIM each authenticate a domain, but not necessarily the domain a reader sees. SPF checks the envelope sender, the hidden Return-Path address. DKIM checks the d= signing domain. A forger can pass both against a domain they control while the From address shows a victim’s. Alignment closes that gap by requiring the authenticated domain to match the visible From domain.
DMARC offers two alignment modes per check. Relaxed alignment, the default, accepts a match at the organizational-domain level, so mail.example.com aligns with example.com. Strict alignment demands an exact match. The adkim tag sets DKIM alignment mode and aspf sets SPF alignment mode, both documented in RFC 7489 and summarised on dmarc.org.
| Policy (p=) | What it tells receivers | Typical use |
|---|---|---|
| p=none | Take no enforcement action; deliver as normal but send reports | The monitoring stage. Required minimum for Gmail and Yahoo bulk senders |
| p=quarantine | Treat failing mail as suspicious; route it to spam or junk | The intermediate stage, once reports confirm legitimate mail aligns |
| p=reject | Refuse failing mail outright; it never reaches the recipient | The enforcing end state, for a domain whose sending is fully under control |
Reporting: how a domain owner sees what is being sent
DMARC’s reporting is what turns it from a switch into an instrument. The rua tag names a mailbox for aggregate reports, daily XML summaries of every source sending mail under the domain and whether each passed. The ruf tag requests forensic reports, message-level detail on individual failures. A minimal record reads:
That record starts in monitoring mode, asks for aggregate reports at a named mailbox, and sets relaxed alignment for both checks. The aggregate feed is what surfaces every service sending as the domain before the policy is tightened. dmarc.org documents both report types.
How the three work together, standard by standard
A message passes DMARC when it passes SPF with SPF alignment, or passes DKIM with DKIM alignment, or both. SPF and DKIM run independently and produce separate results; DMARC reads them, applies the alignment test, and enforces the published policy. This is why all three are required together: SPF alone breaks on forwarding, DKIM alone says nothing about the sending server, and only DMARC ties either result to the address the reader sees.
The pass logic, in sequence
The combined check follows a fixed order. SPF and DKIM evaluate first and independently. DMARC then needs only one of them to both pass and align. That single-pass rule is deliberate, because each of SPF and DKIM has a blind spot the other covers.
SPF runs. The receiver matches the connecting server against the envelope-sender domain’s SPF record. Pass or fail. Source: RFC 7208.
DKIM runs. The receiver fetches the public key at the selector and verifies the signature. Pass or fail, independent of SPF. Source: RFC 6376.
DMARC reads both. It needs SPF-pass-plus-SPF-alignment or DKIM-pass-plus-DKIM-alignment against the visible From domain. One aligned pass is enough. Source: RFC 7489 and dmarc.org.
If neither aligned check passes, the receiver applies the published policy: none, quarantine, or reject, and logs the result to the rua mailbox.
Why one without the others leaves a gap
SPF alone fails the moment a message is forwarded, because the forwarding server is not on the original domain’s authorized list. DKIM alone proves the message is intact but says nothing about which server sent it, and offers no instruction on failures. DMARC alone is inert without an SPF or DKIM result to read. The three are a set, which is the same reason Gmail and Yahoo require all of them instead of any one.
| Standard | Governing RFC | Where the record lives | What a pass proves |
|---|---|---|---|
| SPF | RFC 7208 | TXT at the domain root | The sending server is authorized for the domain |
| DKIM | RFC 6376 | TXT at selector._domainkey | The message is signed by the domain and unaltered |
| DMARC | RFC 7489 | TXT at _dmarc | An authenticated check aligns with the visible From, and a policy applies |
Inherited authentication: the records that transfer with an aged domain
An aged or expired domain transfers with whatever SPF, DKIM, and DMARC records the previous owner published, plus the mail reputation the name carried under that owner. A clean domain inherits a usable foundation; a poisoned one inherits stale records and a damaged reputation. Auditing and resetting the inherited authentication, and reading the inherited reputation before purchase, is the acquisition work no general guide covers.
What actually transfers with the domain
Two distinct things come with an aged domain, and they behave differently. The DNS records are configuration: readable, and the new owner can keep what works and rewrite the rest. The mail reputation is history: the prior sending behaviour of the name, recorded by receivers and blocklists, which no record edit can rewrite. Spamhaus, which maintains the Domain Block List keyed to domain names instead of IPs, is one place a name’s prior abuse leaves a mark that follows it to the next owner.
Inherited records (resettable)
The published SPF, DKIM selectors, and DMARC record. Configuration in DNS. The new owner audits them, keeps what serves the new sending setup, and rewrites the rest on day one.
Inherited reputation (not rewritable)
The domain’s prior sending history, held by receivers and blocklists such as Spamhaus. A clean history is an asset. A spam-flagged one is a deficit a fresh DMARC record cannot erase.
The orphaned records an aged domain commonly carries
A neglected aged domain commonly arrives with three kinds of stale authentication. Each is harmless to ignore in theory and a delivery problem in practice once sending begins.
- A stale SPF record with includes for the previous owner’s tools, which both fail to authorize the new sending servers and waste lookups against the ten-lookup limit.
- Orphaned DKIM selectors from services the prior owner used, publishing public keys whose private counterparts are gone, signing nothing.
- A DMARC record at p=reject pointing rua at a dead mailbox, which can refuse the new owner’s first messages while no one reads the reports that would explain why.
That last case is the sharp one. An inherited strict DMARC policy, left in place before the new SPF and DKIM align, enforces rejection against legitimate mail. The reputation side of this diligence is the subject of the email-authentication pillar, and the broader profile screening lives in the expired domain fundamentals hub.
Reputation is why the source of the domain decides the outcome
Configuration is fixable in an afternoon. Reputation is not. This is the point at which sourcing carries the heaviest weight: a domain screened for a clean mail history before purchase starts the rebuild ahead, while an unvetted drop can start it behind, with a deficit no record edit removes. For an aged domain acquired to send from, the SEO Domains marketplace lists names screened across their history, where the mail reputation is read before the listing goes live.
Setting up and verifying SPF, DKIM, and DMARC on an acquired domain
On an acquired domain the sequence is audit first, then reset: read the inherited records, neutralise the strict DMARC policy, publish fresh SPF and DKIM aligned to the new sending services, confirm both pass and align, then walk DMARC back up from none to quarantine to reject. Working in that order keeps the domain from rejecting its own mail while the records come under control.
This is the focused authentication sequence. The full email build on an aged domain, including the MX records that sit underneath it, is covered across the email and authentication pillar; the steps below are the SPF, DKIM, and DMARC core of it.
-
Audit the inherited records, before sending anything
Query the domain’s existing TXT records. Read the SPF record at the root, list every DKIM selector under _domainkey, and read the DMARC record at _dmarc. The audit is looking for a strict policy, dead reporting mailboxes, and includes or selectors for tools no longer in use.
The mistake: sending the first campaign before reading the inherited DMARC record. A p=reject left by the prior owner refuses unaligned mail on message one.
-
Set DMARC to monitoring while the rebuild runs
If the inherited DMARC enforces, drop it to p=none and point rua at a controlled mailbox. Monitoring mode delivers mail normally while the aggregate reports reveal every source sending as the domain, which is the picture needed before tightening anything.
The mistake: leaving rua pointed at the previous owner’s dead address, so the reports that would guide the rollout go nowhere.
-
Publish fresh SPF, scoped to the new tools
Rewrite the SPF record to authorize only the services now in use, with one include per real tool, and keep the total under ten DNS lookups. Close it with -all once the list is confirmed complete.
The mistake: stacking the inherited includes on top of the new ones and crossing the ten-lookup limit, which returns a permanent error and breaks SPF entirely.
-
Publish a fresh DKIM key and retire the orphans
Generate a DKIM key pair in the sending service, publish its public key at a fresh selector under _domainkey, and remove the orphaned selectors from the prior owner. A test message confirms the DKIM-Signature header verifies.
The mistake: leaving dead selectors published. They sign nothing and only add clutter a receiver can read as a neglected, improvised setup.
-
Verify alignment, then walk DMARC up
Confirm that at least one of SPF or DKIM both passes and aligns with the From domain, using the aggregate reports and a test to a verification address. Once the reports show legitimate mail aligning cleanly, move DMARC from none to quarantine, watch, then to reject.
The mistake: jumping straight to p=reject before the reports confirm alignment, which quarantines or refuses the domain’s own newsletters and notifications.
The mistakes that break authentication on an aged domain, and the fix
The failures that break SPF, DKIM, and DMARC on an acquired domain are a short, recognisable list, and the bulk of them are inheritance-specific. Each has a documented fix, and the fixes converge on one move: audit the inherited records and rewrite them against the new sending, on a domain whose reputation was clean to begin with. The table below is the scannable reference.
The left column is the mistake, the centre column is why it breaks delivery, and the right column is the fix. Read top to bottom, the fixes describe a clean authentication reset on a screened domain.
| The mistake | Why it breaks delivery | The fix |
|---|---|---|
| Sending under an inherited p=reject | The prior owner’s strict DMARC refuses unaligned mail immediately | Drop DMARC to p=none, rebuild SPF and DKIM, then re-enforce |
| Stale SPF includes for the old owner’s tools | They fail to authorize the new servers and burn DNS lookups | Rewrite SPF to include only the active sending services |
| Crossing the ten-lookup SPF limit | RFC 7208 caps lookups at ten; over it, SPF returns a permanent error | Consolidate includes and keep the total under ten lookups |
| Orphaned DKIM selectors | Published keys with no private counterpart sign nothing and read as neglect | Publish a fresh selector and remove the inherited dead ones |
| DMARC rua at a dead mailbox | The aggregate reports that should guide the rollout go unread | Point rua at a controlled mailbox before tightening policy |
| No alignment despite SPF and DKIM passing | Both authenticate a domain that is not the visible From, so DMARC fails | Ensure SPF or DKIM authenticates the actual From domain |
| Jumping straight to enforcement | Strict policy before reports confirm alignment blocks legitimate mail | Phase the rollout none to quarantine to reject, watching reports |
| Inheriting a spam-flagged reputation | A poisoned sending history follows the name; records cannot rewrite it | Screen the domain’s mail history before purchase, not after |
One pattern runs down the fix column. Seven of the eight are records rewritten the day the domain transfers. The eighth, the inherited reputation, is the one a record edit cannot touch, which is why the source of the domain is the practical starting point of trustworthy email, not an afterthought to it.
SPF, DKIM, and DMARC FAQ
The questions buyers and operators raise when setting up authentication on an aged domain, answered against the RFCs, dmarc.org, and the records that transfer with a domain.
Q1What is the difference between SPF, DKIM, and DMARC?
SPF lists which servers are permitted to send for the domain, defined in RFC 7208. DKIM adds a cryptographic signature proving the message is intact and genuinely from the domain, defined in RFC 6376. DMARC, defined in RFC 7489, ties at least one of those passes to the visible From address through alignment, sets a policy for failures, and collects reports. SPF and DKIM authenticate; DMARC aligns, enforces, and reports.
Q2Are all three required on an aged domain?
For sending at any volume, yes. Since February 2024, Google and Yahoo require senders of more than 5,000 messages a day to publish SPF, DKIM, and a DMARC record of at least p=none, per the AWS Messaging blog. Beyond the requirement, each covers a gap the others leave, so all three together are what a receiver reads as a real, operated sender.
Q3What happens to the old owner’s SPF, DKIM, and DMARC records on a domain purchase?
They transfer with the domain and stay published in DNS until changed. A buyer commonly inherits a stale SPF record, orphaned DKIM selectors, and a DMARC record that can enforce rejection against a dead reporting mailbox. The fix is to audit and reset all three before sending. The inherited mail reputation, unlike the records, cannot be rewritten, which is why screening the domain’s history before purchase matters.
Q4What is DMARC alignment, and why does it matter?
Alignment requires the domain authenticated by SPF or DKIM to match the domain in the visible From header. Without it, a forger can pass SPF and DKIM against a domain they control while showing a victim’s address. dmarc.org documents two modes: relaxed, which matches at the organizational-domain level, and strict, which demands an exact match, set with the aspf and adkim tags. Alignment is the mechanic that makes DMARC meaningful.
Q5Why does mail still land in spam when SPF, DKIM, and DMARC all pass?
Authentication proves identity; it does not guarantee placement. Valimail notes that authenticated mail still lands in spam when complaint rates, engagement, and permission are poor, or when the sending domain’s reputation is weak. On an aged domain, an inherited spam-flagged reputation is a frequent cause, and it is why a clean, screened mail history is worth more than a perfect record set on a poisoned name.
The foundation of a trusted sender: a clean domain, properly screened
SPF, DKIM, and DMARC are configuration that can be written correctly on any domain. What cannot be configured is the mail reputation the domain already carries. A clean, screened aged domain lets a correct record set do its job from the first message; a poisoned one undermines a perfect configuration. Sourcing a domain whose history was read before purchase is the foundation of a trusted sender. SEO Domains operates that curated marketplace.
Why the domain decides the outcome
Everything in this guide converges on one variable. Flawless SPF, DKIM, and DMARC records still land in spam if the name behind them carries a damaged sending history. The records are the easy part. The reputation is the asset, and it is set before DNS is ever touched.
How to source a domain that sends clean
A domain that sends clean survives a history check before money changes hands. The signals that matter to email specifically sit alongside the link-profile signals documented across the domain authority and metrics hub:
- A mail-sending history free of prior spam or abuse, and absent from domain blocklists such as Spamhaus.
- A clean DNS record state, with no inherited junk that signals a neglected or burned name.
- Real prior use with topical continuity, instead of a name parked and churned for a metric.
- A backlink and authority profile that is earned, not spam-inflated, screened before listing.
A junk domain fails the first of these and undermines every record published afterward. A screened domain passes them and lets a correct authentication setup perform as designed.
| Check | Unvetted domain (liability) | Screened domain (asset) |
|---|---|---|
| Mail history | Possible prior spam, blocklist marks | Clean sending record, off the blocklists |
| Inherited records | Stale SPF, orphaned DKIM, strict DMARC | Readable, resettable, no enforcement traps |
| Reputation start point | A deficit no record edit removes | A clean slate a correct setup builds on |
| Screening | None; sold on a raw metric | Mail history and profile read before listing |
| Outcome of correct SPF/DKIM/DMARC | Still throttled by a poisoned name | Performs as designed from the first send |
Browse aged domains screened for a clean sending history
The demand behind setting up SPF, DKIM, and DMARC on an aged domain is a name that can be sent from with confidence. That is the product: a clean, screened domain, not a DMARC analyzer subscription, not a managed-authentication service, and not a done-for-the-buyer setup. SEO Domains operates the curated marketplace where aged and expired domains are screened across their mail history and authority profile before they are listed and priced.
