14 Jan DNS and Email Records, Explained
Six small text records decide whether your website loads, whether your email is believed, and whether somebody else can pretend to be you. Most businesses have never seen them. Here is what each one does and what breaks without it.
The three records that decide whether your email is trusted
Mail servers no longer take your word for it. Before a message reaches an inbox it is checked against records published in your domain, and a business with none of them set is treated as a business that might not be real.
SPF: which servers may send as you
SPF is a list of the servers allowed to send email using your domain name. Your mail provider is on it. So is your booking system, your newsletter tool, your invoicing platform, and anything else that sends on your behalf. Anything not on the list is a stranger claiming to be you.
What goes wrong: the record is set up once when the site is built, then a new tool starts sending invoices and nobody adds it. Those invoices fail. There is also a hard limit of ten DNS lookups in an SPF record, and a business that has accumulated five services usually blows through it without knowing, at which point the whole record stops being evaluated.
DKIM: proof the message was not altered
DKIM adds a cryptographic signature to every message you send. The receiving server checks it against a public key published in your DNS. If the message was altered in transit, or was never signed by you at all, the check fails.
What goes wrong: DKIM is often left off because it needs a key generated at the mail provider and a record added at the DNS provider, and those are frequently two different companies with nobody owning the join.
DMARC: the one that makes the other two mean something
SPF and DKIM only report a pass or a fail. DMARC decides what happens next, and sends you reports naming every source sending as your domain.
| Policy | What receivers do | When to use it |
|---|---|---|
| p=none | Deliver as normal, but report | Start here. It tells you who is sending as you. |
| p=quarantine | Send failures to junk | Once the reports show every legitimate sender is passing |
| p=reject | Refuse failures outright | The destination. Forged mail in your name stops being delivered. |
The mistake almost everyone makes is going straight to reject. Enforcement blocks anything unaccounted for, and that reliably includes a system nobody mentioned. Start at none, read the reports for a few weeks, then tighten. That is the whole job.
The records that decide where your site lives
TTL: the setting that makes migrations safe
Every DNS answer carries a TTL, which is how long the rest of the internet may cache it before asking again. A typical default is a day.
That means if you change something and got it wrong, the wrong answer is cached everywhere for a day. It also means a planned move is not really planned, because different visitors see the old and new site for hours.
The fix takes one minute and almost nobody does it: lower the TTL to five minutes the day before the change. Then the cutover is minutes wide, and a mistake is five minutes long instead of a day. Raise it again afterwards.
The records that stop somebody being you
Putting an edge in front
Running a domain behind a filtered edge network moves the first point of contact away from your server. Junk traffic and denial-of-service floods are absorbed before they reach you, certificates are issued and renewed automatically, pages are served from wherever is nearest the visitor, and your real server address stops being public information.
The speed improvement is the part search engines measure directly, which makes it one of the few security decisions that also helps you rank.
Who should hold the domain
The registration should be in your company’s name, on an account your company controls, with renewal notices going to an address somebody actually reads.
The most common quiet failure we find is a domain registered by whoever built the site years ago. It works perfectly until the day it does not: a dispute, a rebuild, a person who has moved on and stopped answering. An expired domain takes the website and the email down together, and recovery is measured in days.
We register in your name, watch the renewals, and document the records. Detail on domains and DNS, the mail side on secure email, and how it fits together on managed services.
Questions people actually ask
What is DMARC in plain English?
DMARC is a line of text in your domain settings that tells other mail servers what to do with email that claims to come from you but cannot prove it. Set to none it only reports. Set to quarantine it sends failures to junk. Set to reject it refuses them outright. Without DMARC, forged mail in your name is delivered normally.
Do I need SPF, DKIM and DMARC, or just one?
All three, and in that order. SPF lists which servers may send as you. DKIM signs each message so it can be proved unaltered. DMARC is what makes the first two enforceable and reports who is failing. Any one on its own leaves an obvious gap.
Why does my email go to junk when I have SPF set up?
Usually because SPF alone is not enough, the record has more than ten DNS lookups in it, or a service you use sends on your behalf without being listed. DKIM signing and a DMARC policy are what move a domain from tolerated to trusted.
What is TTL and why lower it before a migration?
TTL is how long the rest of the internet may cache an answer about your domain. If it is set to 24 hours, a mistake lasts a day. Lower it to five minutes the day before a move and a cutover takes minutes, and a mistake is five minutes long.
What does DNSSEC actually protect against?
It signs your DNS answers so they cannot be forged in transit. Without it, someone positioned between a visitor and your domain can answer on your behalf and send that visitor somewhere else, with nothing in the browser looking wrong.
What is a CAA record?
A CAA record names which certificate authorities are allowed to issue an HTTPS certificate for your domain. Without one, any authority can, which means anyone who convinces one of them can hold a valid certificate for your name.
Should my domain be registered to me or my web developer?
To your company, always. A domain registered to whoever built the site is the most common quiet failure we find. It works fine right up until a dispute, a rebuild, or somebody moving on and not answering, which is exactly when you need it.
Not sure which of these you have?
We can look at your domain and tell you what is set, what is missing, and what it is costing you.
Sorry, the comment form is closed at this time.