Why Email Authentication Records Still Confuse Website Owners

A surprising number of website owners discover their contact form emails are landing in spam only after a customer mentions it in passing. The hosting account is paid up, the domain renews on schedule, and the mail server has never gone down, yet somewhere between sending and delivery a message quietly gets filed away where nobody reads it. The usual culprit is a trio of DNS records that most people set up once during launch week and never think about again: SPF, DKIM and DMARC.

What SPF Is Actually Checking

SPF, short for Sender Policy Framework, is a plain text record published in DNS that lists which mail servers are allowed to send on behalf of a domain. When a receiving server gets a message claiming to be from yourdomain.com, it looks up that record and checks whether the server that actually delivered the message is on the approved list. If it is not, the message gets marked as suspicious, sometimes quietly, sometimes with a visible warning in the recipient's inbox.

The record itself is short, often a single line, but the mistakes around it are common. A business that switches from one email provider to another and forgets to update the SPF record will keep sending mail that technically fails the check, because the old record still only lists the previous provider. SPF also has a hard limit on the number of DNS lookups it can perform, which trips up domains that have accumulated includes from several marketing tools, payment processors and transactional email services over the years without anyone pruning the list.

Why DKIM Catches Problems SPF Misses

DKIM, DomainKeys Identified Mail, works differently and solves a different problem. Instead of checking where a message came from, it checks whether the message was altered in transit. The sending server attaches a cryptographic signature to the message headers, and a matching public key published in DNS lets the receiving server verify that signature. If even a small part of the message changes after it leaves the sender, the signature no longer matches and the check fails.

This matters because mail does not always travel in a straight line. Mailing list software, forwarding rules and some corporate gateways rewrite parts of a message along the way, which is exactly the kind of change DKIM is built to catch, for better or worse. A site that migrates to a self hosted mail setup after relying on a third party sender for years often finds this is where things quietly break, because the new server needs its own key pair generated and published before outgoing mail will pass DKIM checks anywhere.

DMARC Is the Policy Layer, Not a New Check

It helps to think of DMARC as a set of instructions rather than a third test. DMARC tells a receiving server what to do when a message fails SPF or DKIM, or fails to align the domain used in those checks with the visible sender address. Without a DMARC record, receiving servers are left guessing, and most default to quietly routing questionable mail to spam rather than rejecting it outright, which is exactly the slow, invisible failure mode that confuses site owners the most.

A DMARC record can request one of three outcomes: do nothing but report, quarantine suspicious mail, or reject it outright. Publishing a DMARC policy at the reject level before SPF and DKIM are both solid is a common way for a domain's legitimate mail to start disappearing overnight, so most guides recommend starting with a monitoring only policy and reading the aggregate reports for a few weeks before tightening anything.

Where Website Owners Usually Go Wrong

The most common failure is not a misconfigured record but an abandoned one. A domain that changes email providers, adds a new transactional sending service for order confirmations, or moves its newsletter to a different platform needs its SPF record updated every single time. Skip one update and that one channel starts failing silently while everything else keeps working, which makes the problem very hard to notice until someone complains about a missing receipt.

The second common mistake is copying a record from a tutorial without understanding what each part does, then never revisiting it again. SPF records in particular tend to accumulate cruft over the years as services come and go, and nobody wants to be the one to delete a line in case it breaks something they cannot see. The result is a record that technically works but is far longer and harder to audit than it needs to be.

A Record Changing Hosts Quietly Breaks

Hosting migrations are where these records go to die. A site owner moves their website to a new host, remembers to update the A record so the site keeps loading, and forgets that the old host was also handling outbound mail for contact forms and password resets. The new host either has no outbound mail configured at all or routes it through a completely different server that is not listed anywhere in the SPF record, and every automated email the site sends starts failing checks the moment the migration finishes.

This is one of several reasons mail deliverability problems tend to cluster around infrastructure changes rather than appearing at random. Anyone planning a migration is better off treating the mail configuration as its own checklist item, separate from the website itself, rather than assuming it will carry over automatically.

How to Verify Your Setup Without Guessing

Checking all of this does not require specialized tools. Sending a test message to one of the several free services that return a detailed SPF, DKIM and DMARC report takes a couple of minutes and shows exactly which part, if any, is failing. DNS lookup tools that show the raw text of a domain's records are just as useful for spotting an SPF record that has quietly grown past its lookup limit or a DKIM key that was never published after a provider change.

For anyone running their own mail infrastructure rather than outsourcing it entirely, it is worth checking these records every time a new sending service gets added and at least once a year even if nothing has obviously changed, since a record can go stale without any error message ever appearing. The topics covered under email infrastructure on this site go into more detail on specific providers and edge cases, but the three checks above cover the vast majority of delivery problems that get reported as mysterious.

None of this is particularly difficult once it is understood, which is part of why it gets neglected. The records are set once during a busy launch period, they work, and nobody looks at them again until a customer mentions that an invoice never arrived. Building a habit of checking SPF, DKIM and DMARC whenever a sending service changes removes most of the mystery from email deliverability for good.