Three DNS records decide whether the internet believes a message genuinely came from your domain. They are widely published, frequently misconfigured, and often treated as a one-time setup task rather than something to operate. Publishing them is the easy part. Understanding what each one proves, monitoring what they report, and tightening policy without breaking legitimate mail is where most organizations run into trouble.
This article explains how each standard works, the errors that quietly undermine them, and a practical way to move from monitoring to enforcement at a pace your business can absorb.
What Each Standard Actually Proves
It helps to separate the three by the question each answers. The sender policy framework record answers which servers are permitted to send mail for your domain. The signing standard answers whether a specific message was authorised by the domain it claims to come from and whether it was modified after signing. The policy record tells receiving systems what to do when those checks fail, and asks them to send you reports about what they see. None of them encrypts anything, and none of them inspects the content of a message. They verify origin and integrity only, which is still the foundation almost every other protection builds on.
The Sender Policy Framework in Practice
An SPF record is a list of authorised sending sources, published as DNS text and evaluated against the envelope sender rather than the address visible in the message header. That distinction causes more confusion than any other part of the standard. When a message is forwarded, the envelope often changes while the visible address does not, so mail that was perfectly legitimate at the origin can fail downstream. A further limitation is the lookup limit: each record may reference a bounded number of other domains and addresses, and exceeding that limit causes a failure rather than a pass. Organizations that add sending services over time tend to hit this ceiling without noticing, which is why an audit of every legitimate sender, including billing platforms, ticketing systems, and marketing tools, should happen before the record is rewritten.
The Signing Standard in Practice
Signing uses a cryptographic key pair. The private key stays with the sending service and is used to attach a signature to each message; the public key is published in DNS so receivers can verify it. The practical risk is not the mathematics but key custody. Lose the private key and you cannot sign. Expose it and someone else can sign as you. Rotate it carelessly and messages in flight fail validation. If a third-party service sends on your behalf, it usually signs with its own key and its own domain, which is acceptable as long as the policy record allows that alignment. Understanding who actually signs your mail is the step most organizations skip.
Policy, Alignment, and Reporting
The policy record is where the three standards become an instruction rather than a suggestion. It defines how strict receivers should be, ranging from taking no action while still collecting data, through quarantining failing messages, to rejecting them outright. Enforcement also depends on alignment: the domain in the visible address must match the domain that passed authentication, which is why a message can pass both earlier checks and still fail policy. Reporting is the other half of the record. Aggregate reports summarize volumes by sending source, while forensic reports describe individual failures in more detail. Both are essential, and both are ignored far more often than they are read. Most domains are, in practice, operating a strict policy based on assumptions rather than on any evidence about who sends their mail.
Common Implementation Mistakes
A short list covers most of the problems seen in the field:
- Publishing an incomplete sender list, then jumping straight to a strict policy.
- Exceeding the lookup limit and treating the resulting failure as a pass.
- Forgetting internal relays, ticketing systems, and monitoring tools that send notifications as your domain.
- Leaving report mailboxes unread, so unknown senders remain unknown indefinitely.
- Applying enforcement to the top-level domain while subdomains remain unprotected.
- Never rotating keys, or rotating them without coordinating with the sending service.
Most of these are visible in report data before they cause a delivery problem, which is exactly why monitoring comes first.
Rolling Out Policy Gradually
A staged approach avoids both broken mail and false confidence:
- Inventory every system that sends mail using your domain, including third-party platforms.
- Publish authentication records for all of them and confirm they pass.
- Start with no enforcement while collecting reports, and review the data for several weeks.
- Move to quarantine for failing messages, watching for legitimate mail caught by mistake.
- Apply rejection once the reports show only unwanted sources failing.
- Extend coverage to subdomains, then schedule a review of keys, records, and reports at least yearly.
The timeline varies with complexity, but the order should not. Skipping straight to rejection is the fastest way to discover an unlisted sending platform through a customer complaint.
Frequently Asked Questions
Do these records stop phishing completely?
No. They prevent forged mail from appearing to come from your domain, which reduces impersonation and improves deliverability. Attackers still use lookalike domains and compromised accounts that pass every check.
Can we enforce policy without third-party reporting tools?
Yes, reports can be delivered to a monitored mailbox and parsed manually at small volume. As the domain grows, automation becomes necessary because the data volume quickly exceeds what anyone will read by hand.
What happens to legitimate mail during a strict rollout?
Messages that fail are quarantined or rejected according to your policy. This is why the monitoring stage matters, since it reveals legitimate senders that still need to be authorised or reconfigured.
How often should records be reviewed?
At least annually, and whenever a new sending platform, subsidiary, or domain is introduced. Authentication records age badly when the systems behind them change.
Authentication works when it is treated as an operational process rather than a checkbox: know who sends your mail, verify them, watch the reports, and tighten policy in steps. The content above is general information rather than professional advice, so consider qualified guidance for your own environment before changing production records.