An email can be perfectly written, legitimately requested and sent from a real company — and still end up in spam. The reason is that modern email delivery is no longer determined only by what a message says. Before Gmail, Yahoo or another provider decides where to place it, their systems examine an invisible technical identity built from DNS records, cryptographic signatures, sending infrastructure and the sender's reputation.
Three acronyms sit at the center of that identity: SPF, DKIM and DMARC. They are frequently described as anti-spam technologies, but that shorthand misses their real purpose. They do not prove that a message is good or wanted. They help a receiving server answer a more fundamental question: is this sender actually authorized to use the domain appearing on the email?
That question has become much more consequential. Since 2024, major mailbox providers have tightened authentication requirements, particularly for high-volume senders. Gmail has since increased enforcement against non-compliant traffic, while Yahoo maintains similar requirements for bulk mail. DNS configuration has moved from obscure mail-server housekeeping to a basic condition of reliable email delivery.
Why DNS is involved in email at all
The Domain Name System is best known for translating domain names into the addresses computers use to locate servers, but DNS can publish many other kinds of information. Email authentication makes extensive use of TXT records: pieces of text associated with a domain that receiving mail systems can query publicly.
This creates a useful trust mechanism. Imagine receiving a message claiming to be from example.com. Anyone can type that domain into the visible From field, just as anyone can write a false return address on an envelope. The receiving server therefore asks DNS for information published by the actual domain owner.
SPF can say which systems are authorized to send mail. DKIM can provide the public key needed to verify a cryptographic signature. DMARC can tell receivers how these authentication results must relate to the domain visible to the user and what policy the domain owner wants applied when authentication fails.
Together, the three protocols form layers rather than interchangeable alternatives.
SPF: who is allowed to send?
Sender Policy Framework, or SPF, allows a domain owner to publish which servers are authorized to send email on behalf of a domain. A typical SPF record is stored in DNS as TXT data and begins with v=spf1. It can contain IP addresses and references to the infrastructure of third-party email providers.
When a receiving server gets a message, it can compare the sending IP address with the SPF policy of the relevant envelope-sender domain. If the sender is authorized, SPF passes. If not, it fails or produces another result depending on the policy and circumstances.
The concept is straightforward, but real configurations become complicated quickly. A company may send ordinary employee mail through one provider, newsletters through another, transactional receipts through an ecommerce platform and support messages through a customer-service system. Each legitimate sender must be accounted for appropriately.
A common mistake is to create several separate SPF TXT records for the same domain. SPF is designed around a single policy record; multiple competing SPF records can produce a permanent error instead of strengthening authentication. Another frequent problem is forgetting an old or newly added third-party service.
SPF also has an important architectural limitation: it authenticates the SMTP envelope identity rather than automatically proving that the domain a human sees in the From header is the same one. That gap is one reason DMARC exists.
DKIM: did the authorized sender sign this message?
DomainKeys Identified Mail approaches authentication differently. Instead of primarily checking the source IP, DKIM attaches a cryptographic signature to the email.
The sending system holds a private key and uses it to sign selected parts of the message. The corresponding public key is published in DNS under a special name containing a selector and _domainkey. The receiving server retrieves that key and verifies the signature.
If verification succeeds, the receiver gains evidence that the message was signed by an entity controlling the signing domain and that the signed portions were not altered in a way that invalidates the signature after signing.
Selectors make DKIM especially flexible. A domain can maintain several keys at once — for example, one for a corporate mail provider and another for a marketing platform — and rotate keys without changing the visible email domain.
Key management matters. Google's current sender guidelines require DKIM keys of at least 1024 bits for mail sent to personal Gmail accounts and recommend 2048-bit keys when the domain provider supports them.
SPF and DKIM therefore answer related but different questions. SPF asks whether the connecting infrastructure is authorized. DKIM verifies a domain-associated signature attached to the message. A robust sending setup generally uses both.
DMARC: the missing link is alignment
DMARC — Domain-based Message Authentication, Reporting and Conformance — ties authentication to the identity users actually see.
This is where the concept of alignment becomes essential. An email can technically pass SPF using one domain while displaying a different domain in its From header. It can also carry a valid DKIM signature belonging to an unrelated domain. DMARC checks whether a successful SPF or DKIM identity aligns with the organizational domain presented in the visible From address.
For DMARC to pass, at least one qualifying authentication path must both pass and align under the applicable policy. This makes impersonation harder: an attacker cannot simply obtain a valid SPF or DKIM result for a domain they control while pretending in the visible From field to represent another company.
A DMARC policy is published in DNS under _dmarc. The familiar policy values describe increasingly consequential handling instructions: p=none is primarily monitoring, p=quarantine asks receivers to treat failing mail suspiciously, and p=reject requests rejection of failing messages.
Moving directly to p=reject without understanding every legitimate sender can cause self-inflicted delivery failures. Organizations commonly begin by collecting DMARC reports, identifying their real sending ecosystem, fixing authentication and alignment problems, and only then increasing enforcement.
Why “SPF pass” is not the same as “DMARC pass”
This distinction causes a surprising amount of troubleshooting confusion. An administrator opens an email header, sees spf=pass, and assumes authentication is solved. DMARC can still fail.
Suppose a marketing service sends a message that visibly comes from news@example.com, but its SPF-authenticated envelope uses the provider's own domain. SPF can pass perfectly for that provider while failing DMARC alignment with example.com. If the DKIM signature is also from the provider's unrelated domain, there may be no aligned authentication path at all.
The reverse can also happen. SPF may fail or become unreliable because a message was forwarded, while an aligned DKIM signature survives and allows DMARC to pass. This is one reason DKIM is so valuable in modern mail architecture.
Troubleshooting deliverability therefore requires reading the entire authentication chain rather than checking three independent green lights.
Gmail and Yahoo changed the baseline
Authentication used to be treated by some organizations as a deliverability optimization. Major mailbox providers increasingly treat it as expected infrastructure.
Google's current rules require all senders to personal Gmail accounts to use SPF or DKIM, maintain valid forward and reverse DNS for sending infrastructure, use TLS and keep reported spam rates below 0.3 percent. Senders delivering more than 5,000 messages per day to Gmail accounts face additional requirements: both SPF and DKIM, a DMARC record, and alignment of the visible From domain with either the SPF or DKIM domain for direct mail. Marketing and subscribed messages at that scale must also support one-click unsubscribe and contain a visible unsubscribe mechanism. citeturn0search1turn0search4
Google says it began ramping up enforcement against non-compliant traffic in November 2025, including temporary and permanent rejection of messages that fail sender requirements. It also says that while only one of SPF or DKIM currently needs to align for bulk-sender DMARC requirements, full alignment with both is recommended and may eventually become required. citeturn0search2turn0search3
Yahoo's sender requirements follow a similar philosophy. All senders must authenticate with at least SPF or DKIM, while bulk senders are expected to implement both, publish a valid DMARC policy of at least p=none, support easy unsubscribe and maintain spam complaint rates below 0.3 percent. Yahoo also requires valid forward and reverse DNS for sending IPs. citeturn0search0
The important change is cultural as much as technical. Authentication is no longer something only banks and large mailing platforms need to understand. A small business using several SaaS tools can accidentally create a complex sending architecture, because every invoicing platform, CRM, help desk and newsletter service may send email using its domain.
Authentication cannot buy a good reputation
Perfect SPF, DKIM and DMARC records do not guarantee inbox placement. They establish identity, not desirability.
A fully authenticated sender can still send unwanted mail. Providers observe user complaints, engagement patterns, sending volume, sudden spikes, list quality and other reputation signals. Google and Yahoo both explicitly tell senders to keep complaint rates below 0.3 percent, and Google recommends increasing sending volume gradually rather than suddenly flooding recipients from a new or previously quiet identity. citeturn0search0turn0search4
This is why deliverability problems cannot always be fixed by editing DNS. If authentication passes but messages still land in spam, the investigation has to widen: Was the mailing list genuinely opted in? Has volume increased abruptly? Are inactive addresses being mailed repeatedly? Are marketing and transactional traffic being mixed? Are recipients frequently deleting messages or reporting them?
Yahoo specifically recommends separating bulk or marketing email from user and transactional mail at the infrastructure or DKIM-domain level. Google similarly advises keeping message categories consistent and, where multiple IP addresses are used, separating traffic types. citeturn0search0turn0search4
DNS optimization is mostly about correctness
The phrase “DNS optimization” can suggest that there is a secret record capable of persuading spam filters. There is not. For email, optimization mostly means publishing a clean, accurate description of the systems that legitimately represent the domain and removing obsolete configuration.
A useful audit starts by inventorying every service that sends mail: employee accounts, website forms, ecommerce systems, password resets, billing platforms, CRMs, newsletters, support tools and automated scripts. Each must authenticate correctly. DKIM should be enabled wherever available. SPF should authorize legitimate infrastructure without accumulating unnecessary mechanisms. DMARC reporting can then expose unexpected senders and alignment failures.
Infrastructure matters too. Gmail requires valid forward and reverse DNS for sending IPs: the public sending IP should have a PTR record pointing to a hostname, and that hostname should resolve back appropriately through A or AAAA records. This is particularly relevant to organizations operating their own SMTP infrastructure rather than relying entirely on a major email service. citeturn0search1
The final test should happen in real message headers, not merely in a DNS control panel. A TXT record can exist and still be wrong. Send representative messages through every platform and inspect the receiver's authentication results. SPF, DKIM and DMARC should be evaluated in the same environment in which recipients actually receive the mail.
Email has become a domain identity system
What began as an open, relatively trusting communications protocol has accumulated layers of verification because its original assumptions no longer fit an internet full of phishing, spoofing and industrial-scale spam. SPF, DKIM and DMARC are part of that adaptation.
Their logic is easier to remember without the acronyms. SPF asks whether the sending infrastructure is authorized. DKIM asks whether a domain cryptographically signed the message. DMARC asks whether authenticated identity matches the domain being presented to the recipient and publishes a policy for failures.
None of them can determine whether an email deserves to be read. That judgment increasingly belongs to reputation systems — and ultimately to recipients themselves. But without a coherent technical identity, even wanted mail begins the journey at a disadvantage.
The modern inbox is therefore not merely filtering messages. It is evaluating domains. For anyone responsible for a website, newsletter, application or business email system, DNS is now part of the conversation with every recipient before the subject line is ever opened.