A mail server is configured. Postfix is set up, TLS is enabled, user accounts are created. A test email is sent to a Gmail account. It arrives in spam. The logs show everything is fine. The email was sent, the connection was successful. SPF, DKIM, and DMARC records are added to DNS. A day passes. Another test email is sent. Still spam. The headers show “SPF: pass,” “DKIM: pass,” “DMARC: pass.” But Gmail still does not trust the domain.

This is the reality of email deliverability. DNS records are necessary but not sufficient. Email providers do not trust DNS records; they trust reputation. DNS records are signals that contribute to reputation, but they are not reputation itself. A domain with perfect DNS records but no sending history is still untrusted. A domain with years of legitimate sending history is trusted even if its DNS records are imperfect.

SPF (Sender Policy Framework) tells the receiver which IP addresses are authorized to send email for a domain. When an email arrives, the receiver checks the SPF record to see if the sending IP is listed. If it is, SPF passes. If it is not, SPF fails. SPF is a basic identity check: “Is this sender who they claim to be?” But SPF does not prove the email is legitimate; it only proves the sending IP is authorized. A compromised server with a valid SPF record can still send spam.

DKIM (DomainKeys Identified Mail) adds cryptographic verification. The sending server signs each email with a private key. The receiver verifies the signature using the public key published in DNS. If the signature is valid, DKIM passes. DKIM proves the email was not tampered with in transit and that the sender has control of the domain’s private key. But DKIM does not prove the content is legitimate; it only proves the email is authentic.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together. It tells the receiver what to do when SPF or DKIM fails: reject the email, quarantine it in spam, or accept it anyway (none). DMARC also provides reporting: receivers send aggregate reports showing how many emails passed or failed authentication. DMARC is a policy layer: “Here is what to do when authentication fails.” But DMARC does not prevent spam; it only tells receivers how to handle unauthenticated email.

The practical implication is that DNS records are necessary but not sufficient. SPF, DKIM, and DMARC must be configured correctly, but correct configuration does not guarantee deliverability. Reputation is built over time through consistent, legitimate sending. Email providers track sending patterns: volume, complaint rates, bounce rates, engagement rates. A new domain with perfect DNS records but no reputation will be treated as suspicious. An established domain with years of good sending history will be trusted even if it has minor DNS misconfigurations.

This is why warm-up matters. When sending starts from a new domain or IP, full volume cannot be sent immediately. Sending must start small and gradually increase over weeks. Email providers watch for sudden spikes in sending volume from new sources. A domain that sends 10 emails on day one and 10,000 emails on day two looks like a spam operation. A domain that sends 10 emails on day one, 20 on day two, 40 on day three, and gradually ramps up looks legitimate. The warm-up process builds reputation by demonstrating consistent, gradual growth.

This is also why IP reputation matters as much as domain reputation. Email providers track the reputation of IP addresses, not just domains. If email is sent from an IP address that was previously used for spam, the emails will be rejected even if the domain has perfect DNS records. This is why shared email services (like Gmail, Outlook, or transactional email providers) have built-in reputation. When sending through their infrastructure, their established reputation is leveraged. When running a private mail server, the starting point is zero reputation, and it must be built from scratch.

The trade-off is that building reputation takes time and consistency. The process cannot be shortcut by configuring DNS records perfectly. Legitimate email must be sent, consistently, over time. Bounce rates, complaint rates, and engagement rates must be monitored. Feedback loops must be responded to and sending patterns adjusted. The trade-off is between control and convenience. Running a private mail server gives full control, but it requires the work of building reputation. Using a third-party email service gives convenience, but it costs money and limits flexibility.

DNS records are signals, not guarantees. They contribute to reputation, but they are not reputation itself. Reputation is earned through consistent behavior over time, not configured through DNS. Perfect DNS records without consistent sending will not suffice.