The problem these records solve
Email was designed without a strong way to prove who sent a message. Anyone can type any address into the “From” line, which makes it easy to forge mail that appears to come from a bank, a shop or your own business. Mailbox providers deal with enormous amounts of forged mail, so they look for technical evidence that a message is genuine.
SPF, DKIM and DMARC are three standards that supply this evidence. They are published as records in the domain’s DNS settings, which is the public directory that tells the internet how a domain is configured. Together they are usually called email authentication. They do not make mail good, and they do not guarantee the inbox, but without them a legitimate sender can look similar to a forger.
SPF: who may send
SPF stands for Sender Policy Framework. An SPF record is a list, published in your domain’s DNS, of the servers and services allowed to send mail for that domain. When a message arrives, the receiving server checks whether the sending server is on the list.
Think of it as a guest list at the door. If your email service is on it, the check passes.
Points to know:
- A domain should normally have a single SPF record. If you use several services, they are combined into that one record rather than adding separate records. Your email service’s documentation will show the right format.
- SPF checks the technical sending address used behind the scenes, not necessarily the address readers see.
- There are limits on how complicated a record can be. If you add many services over the years, review the record occasionally.
DKIM: was it tampered with
DKIM stands for DomainKeys Identified Mail. Your email service adds a digital signature to each outgoing message, created with a private key. The matching public key is published in your DNS. The receiving server uses it to check that the message was signed by the domain and was not altered on its way.
Think of it as a wax seal. A seal that is intact suggests the message came from the claimed sender and has not been changed.
Most email services give you a record to add, and some call the process “domain authentication” or “verifying your domain”. Follow the steps in their current documentation exactly, since small typing errors stop the check from working.
DMARC: what to do when checks fail
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It builds on SPF and DKIM in two ways.
First, it checks alignment: the domain that passes SPF or DKIM should match the domain the reader sees in the From address. Second, it lets you publish a policy telling receiving servers what to do with mail that fails, and where to send reports about it.
The usual policy choices are:
- none: Take no special action but send reports. This is a common starting point because it lets you watch what is happening without affecting delivery.
- quarantine: Treat failing mail with suspicion, typically by placing it in spam.
- reject: Ask receivers to refuse failing mail.
The reports show which servers are sending mail using your domain, including services you may have forgotten about and anyone attempting to impersonate you. Reading raw reports can be technical, and several tools and services exist to summarise them. Check any tool’s current features and its data handling before using it.
A cautious approach is to begin with a “none” policy, review reports for a period, fix any legitimate senders that fail, and only then consider stricter policies. Moving too quickly can cause real mail, such as invoices from a billing system, to be rejected.
Why mailbox providers care
Providers want to protect their users from forged mail and phishing. Authentication lets them connect messages to a domain and then judge that domain by its history, which is the basis of sender reputation. Without it, there is no reliable domain to attach a good record to. In recent years, several large providers have also set specific authentication requirements for senders who send in bulk, and these requirements change. Check the current guidelines of the providers your audience uses.
A simple setup checklist
- Find out which services send email as your domain: your newsletter tool, your online shop, your billing software, your support desk, and your normal mailboxes.
- For each service, follow its documentation to authenticate your domain. This usually means adding SPF and DKIM records.
- Publish a DMARC record with a “none” policy and a reporting address you can monitor.
- Send test messages to different providers and look at the message headers or your email service’s checker to see whether SPF, DKIM and DMARC pass.
- Review DMARC reports for a while, correct any problems, and decide whether a stricter policy suits you.
- Recheck after any change of email service, web host or domain settings.
If DNS settings feel unfamiliar, your domain registrar’s or hosting provider’s support pages usually explain how to add records. Take care with edits, since a wrong record can break your website or mail.
Common mistakes
- Creating two SPF records instead of one.
- Forgetting a service that sends mail on your behalf, so its mail fails.
- Copying a DKIM value with extra spaces or missing characters.
- Jumping straight to a reject policy.
- Setting up records once and never checking them again.
What authentication does not do
Passing all three checks shows that a message is properly identified. It does not prove the content is wanted. Your standing still depends on complaints, bounces and engagement, and on what the wider article on email deliverability describes. Treat authentication as the foundation and keep the rest of your habits healthy too.
Standards and provider requirements change, so check current documentation. Outcomes vary, and this article is general education rather than technical or legal advice.