One says which servers may send as you, one proves a message was not altered and came from you, and the third tells receivers what to do when the first two fail.

Three records, three jobs

They are usually described together, which makes them sound like three parts of one thing.

They are three separate mechanisms solving three different problems, added at different times over twenty years, and each works without the others.

Understanding which does what turns a support conversation from following instructions into a discussion you can follow.

It also explains why fixing one does not always solve the problem, which is the usual source of frustration.

The first: which servers may send as you

A published list of the servers permitted to send mail using your domain.

When a message arrives claiming to be from you, the receiving system looks up that list and checks whether the sending server is on it.

What it stops is somebody sending from an unauthorised server while claiming your domain, which is the crude form of forgery.

What it does not do is prove anything about the message contents, or cover the address shown to the reader, which is a different field from the one it checks.

The common failure is incompleteness: a business sends through its mail provider, a mailing tool, a booking system, and an invoicing platform, and the list names only the first.

Everything else then fails the check, which is why adding a new tool frequently breaks delivery from it.

The second: proving it came from you unaltered

A signature added to each message, checked against a key published in your domain settings.

If the signature verifies, the receiving system knows the message genuinely originated from a system holding your key and that the signed parts were not altered on the way.

What it stops is tampering in transit and forgery that would pass the first check.

What it does not do is say anything about whether the content is legitimate or wanted. A signed message can still be spam.

The common failure is a service sending on your behalf without being set up to sign, or a key that was rotated at one end and not updated at the other.

The third: what to do when the others fail

An instruction to receiving systems, plus a reporting mechanism.

It says what you want done with mail claiming to be from your domain that fails the first two checks: nothing, treat it as suspicious, or reject it outright.

It also asks receivers to send you reports about what they saw, which is the part people ignore and the part that is genuinely useful.

What it stops is not forgery directly, but the acceptance of forged mail, once you set it to something stronger than nothing.

What it does not do is protect you if you set it to take no action, which is where a great many domains sit permanently after somebody added the record and never revisited it.

Why all three are needed

Which is why the advice is always to have all three rather than to choose, and why fixing one when two are wrong changes nothing visible.

A worked example

A business found that quotes sent from their invoicing system were landing in spam while ordinary email from their mailbox arrived normally.

Their authentication was described as configured, and it was, for their mail provider only.

The invoicing system was sending as their domain from its own servers, which appeared on no permitted list and signed nothing.

So every message from it failed both checks, and their policy record was set to take no action, which meant receivers made their own judgement and mostly filtered them.

Adding the invoicing system to the permitted list and enabling signing in that system took about twenty minutes.

Delivery of quotes returned to normal within a day, and the useful realisation was that they had three other services sending as their domain that nobody had thought about.

List everything that sends as you

The practical exercise behind all three, and it is more work than the records themselves.

Write down every system that sends email showing your domain: the mail provider, the website's contact form, a mailing tool, a booking system, an invoicing platform, a CRM, a review request service.

Most small businesses find between three and six, and most have configured one.

Each needs to be authorised in the first record and, where it supports it, set up to sign.

Every provider documents how, and the instructions are usually a short page.

Do this list first, since configuring records without it produces a setup that is correct for the systems you remembered.

Read the reports before tightening

The sequencing that avoids blocking your own mail.

Set the policy to take no action initially, with reporting enabled, and leave it for a few weeks.

The reports will show every source sending as your domain, including the ones you forgot and any genuine forgery.

Fix everything legitimate that is failing, then tighten the policy to quarantine, then later to reject.

Tightening before reading the reports is how a business stops its own booking confirmations from being delivered, which is a worse outcome than the forgery it was preventing.

The reports are technical and there are free services that turn them into something readable, which is worth using for the few weeks you need them.

The counter-case

This can be more than a very small business needs.

A sole trader sending from one mailbox, through one provider, with no other systems, gets most of the benefit from whatever their provider configured by default.

Tightening the policy also carries real risk, since a mistake blocks your own mail silently, and for a business with several sending systems it is worth doing carefully or with help.

There is also little value in perfect configuration if the underlying practice is poor, since authentication proves a message is genuinely from you and says nothing about whether anybody wanted it.

List your senders, authorise them, enable signing, read the reports, and tighten slowly.

The order to do it in

  1. List every system sending as your domain.
  2. Authorise each in the first record.
  3. Enable signing wherever it is supported.
  4. Add the policy record set to take no action.
  5. Enable reporting and read it for a few weeks.
  6. Fix anything legitimate that is failing.
  7. Tighten the policy gradually, not at once.

Step one is the part that determines whether the rest works, since records configured from memory are correct for the systems you happened to remember.

Getting mail on your own domain in the first place is covered in sending from your own domain.

Frequently asked questions

What does the first record do?

It publishes which servers are permitted to send mail using your domain, so receivers can check whether an arriving message came from one of them.

What does the signature do?

It proves a message genuinely originated from a system holding your key and that the signed parts were not altered in transit. It says nothing about whether the content is wanted.

What does the policy record do?

It tells receivers what to do with mail claiming to be from you that fails the other two checks, and asks them to send you reports about what they saw.

Why do I need all three?

The first can be bypassed in the address shown to the reader, the second gives receivers no instruction, and the third has nothing to enforce on its own.

Why does adding a new tool break delivery?

Because it sends as your domain from servers that are not on your permitted list and signs nothing, so every message from it fails both checks.

What is the safe order?

List every sending system, authorise and sign each, set the policy to take no action with reporting on, read the reports for weeks, then tighten gradually.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Quotes from your invoicing system going to spam?

List everything that sends as your domain. Most businesses find five and have configured one.

Start a Conversation