Client resources
How your email proves it is really you.
Three small records in your domain's DNS decide whether the mail you send reaches the inbox, and whether someone else can send mail pretending to be you. Here is what SPF, DKIM, and DMARC do, in plain language, and what we set up for the domains we look after.
DMARC is the part nobody sees, and the part that decides the inbox
The short version
Three records, three jobs.
They live in your domain's DNS, next to the records that point your website and email where they belong. Nobody sees them. Every mail server you send to checks them.
SPF
Who is allowed to send
Sender Policy Framework is a list of the servers allowed to send mail for your domain: your email provider, your newsletter tool, your website's contact form. A receiving server checks the list. A message from a server that is not on it looks suspicious.
DKIM
Proof it was not altered
DomainKeys Identified Mail adds an invisible signature to each message as it leaves. The receiving server checks the signature against a public key in your DNS. If the message was changed on the way, or sent by someone without the key, the check fails.
DMARC
What to do about failures
Domain-based Message Authentication, Reporting and Conformance ties the two together. It tells receiving servers what to do with mail that fails the checks (deliver, quarantine, or reject) and where to send a report about what they saw.
Every time you send
What happens in the two seconds after you hit send.
All of this is invisible and takes less time than reading this sentence. It is the reason a message from you looks different, to a mail server, from a message that merely says it is from you.
Step 1
You hit send
Your mail app hands the message to your email provider, which signs it with your DKIM key and passes it on.
Step 2
The receiving server looks you up
It reads your domain's SPF record and checks whether the server that delivered the message is on the list.
Step 3
It checks the signature
It fetches your DKIM public key from DNS and confirms the signature matches the message it received.
Step 4
DMARC decides
If both checks pass, the message is delivered normally. If they fail, your DMARC policy says what happens next, and the server sends a summary report back to the address in the record.
Why it matters
Three things it does for you.
Most people meet DMARC the first time a message quietly stops arriving, or the first time a customer asks why "you" emailed them an invoice you never sent. Getting the records right heads off both.
Think of it as your name on the envelope, and the post office actually checking
- Your mail arrives. Gmail, Yahoo, and Microsoft now expect every sender to have SPF or DKIM in place, and anyone sending in volume (newsletters, invoices, appointment reminders) to have both, plus DMARC. Without them, legitimate mail is more likely to land in spam or be refused.
- Nobody can pose as you. Scammers send mail that says it is from a real business because it works. With a DMARC policy in place, mail that fails the checks is quarantined or rejected instead of delivered to your customers.
- You find out what is happening. The reports show which services are sending as your domain and which are failing. That is how we spot a new tool that was never added, or someone trying your name on for size.
The policy
Three settings, from watching to blocking.
A DMARC record carries a policy that tells receiving servers how firm to be. The usual path is to start loose, read the reports, fix what they reveal, and then tighten.
p=none
Watch and report
Nothing is blocked yet. Receiving servers deliver as usual and send reports. This is where every domain starts, so the records can be checked against real traffic before anything is enforced.
p=quarantine
Failures go to spam
Mail that fails both checks is delivered to the junk folder rather than the inbox. A sensible middle step once the reports show that everything legitimate is passing.
p=reject
Failures are refused
Mail that fails is not delivered at all. The strongest protection for your name, and the goal for most business domains once the reports have been clean for a while.
What usually breaks it
The four things that trip most domains.
None of these are mistakes exactly. They are normal things a business does, with a side effect nobody mentioned.
A new tool that sends as you
A newsletter platform, a CRM, invoicing software, a booking system, or a website contact form. Each one has to be added to SPF, and where possible signed with DKIM, before it starts sending. This is the most common cause of mail suddenly going missing.
Forwarding
Mail forwarded through another mailbox can arrive from a server that is not on your list. Modern providers handle this well, but it is worth knowing when a forwarded message lands in spam.
Forms that send "from" the visitor
A contact form that puts the visitor's own address in the From line is sending mail for a domain you do not control, and it will fail their DMARC, not yours. Forms should send from your domain and reply to the visitor.
Too many entries
SPF allows a limited number of lookups. Domains that have accumulated years of tools can quietly go over the limit, at which point the whole record stops working. A tidy-up fixes it.
For the domains we look after
What we do, and what we need from you.
When we host your website or manage your domain, the records are part of the setup: SPF, DKIM for your email provider, and a DMARC record with reporting turned on. We read the reports, and we tighten the policy as they come back clean.
The one thing we cannot see coming is a new service. Before you connect anything that will send email as your business, a newsletter tool, a CRM, invoicing, a scheduling app, send us a note with the name of the service. Adding it takes a few minutes. Finding out afterwards takes a lot of missing email.
Quick check
Not sure whether your domain has these records? Email us the domain name and we will look, whether or not we host it. If something is missing or wrong, we will tell you what it is in plain terms.
Questions about your email?
Existing clients can email su*****@************on.com. Everyone else: tell us what is going on, and we will point you in the right direction.
