SPF, DKIM and DMARC explained, without the acronyms

If someone sends an invoice that appears to come from your company, nothing in the email itself stops them. The From address in an email is just text. Anyone can type anything into it, in the same way anyone can write any return address on an envelope.

SPF, DKIM and DMARC are the three published records that let a receiving mail server work out whether a message claiming to be from you really is. They only work as a set, and the order you set them in decides whether the process is uneventful or takes your email down for a morning.

The short version

• SPF publishes the list of servers allowed to send email for your domain.
• DKIM adds a cryptographic signature to your outgoing mail, proving it was not tampered with and came from an authorised sender.
• DMARC ties the two together, tells receivers what to do when a message fails, and sends you reports about who is sending mail as you.

Without DMARC, the first two are advisory. Receivers can check them and then deliver the message anyway, because nothing told them not to.

SPF: who is allowed to send

SPF is a single line of text published in your DNS. It says, in effect, “mail for this domain comes from these servers, and you should treat anything else as suspicious.”

v=spf1 include:_spf.google.com include:sendgrid.net -all

Two things quietly break SPF, and neither produces a warning.

The ten-lookup limit

Every include:, a, mx, ptr, exists: and redirect= in your record costs a DNS lookup, and so does every one of those inside the records you include. The specification caps this at ten. Go over it and conforming receivers stop evaluating the record entirely, which is the same outcome as having no SPF at all.

Nothing tells you when this happens. You add a new invoicing tool, it adds its own include, and your record silently stops counting. This is one of the most common failures we find, and it is invisible from the outside unless you go looking. The free domain security checker counts it for you.

The difference between ~all and -all

The mechanism at the end tells receivers what to do with mail from a server not on your list.

• -all (hard fail) says reject it.
• ~all (soft fail) says accept it, but mark it as suspicious.
• ?all (neutral) says do nothing, which makes the record almost pointless.

Most domains end in ~all, and most receivers deliver soft-failed mail anyway, usually straight to the inbox. Ending in -all is the setting that actually refuses forged mail, and it is perfectly safe once every legitimate sender is accounted for. Getting to that point safely is the work.

One record only

The standard allows exactly one SPF record per domain. If two exist, because two providers were set up months apart and each added its own, the result is a permanent error and both are ignored. Two SPF records is not twice the protection. It is none.

DKIM: proving the message is genuine

SPF checks where a message came from. DKIM checks that the message itself is authentic.

Your mail provider signs each outgoing message with a private key. The matching public key is published in your DNS under a selector, a label that lets you run several keys at once:

google._domainkey.yourcompany.com

The receiving server fetches the public key, checks the signature, and knows both that an authorised system sent the message and that nobody altered it in transit.

DKIM matters for a reason SPF cannot cover: it survives forwarding. When someone forwards your email, the forwarding server becomes the sender, so SPF fails. The DKIM signature travels with the message and still validates.

The catch is that every service sending mail on your behalf needs its own key. Your mail platform, your invoicing tool, your CRM, your marketing platform, your helpdesk. After a migration, the one everybody sets up is the mail platform, and the other four are quietly unsigned.

Because selectors are arbitrary names that are not published anywhere, DKIM cannot be reliably audited from outside a domain. That is why our checker reports DKIM for information but leaves it out of the grade: a “not found” would be a guess, not evidence.

DMARC: the instruction, and the reporting

SPF and DKIM produce a result. DMARC is what makes that result mean something.

v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com; pct=100

DMARC does three jobs:

1. It sets the policy. p=none, p=quarantine or p=reject, which is the instruction receivers follow when a message fails.
2. It requires alignment. The domain that passed SPF or DKIM has to match the domain in the From address the human actually reads. Without this, an attacker could pass SPF for their own domain while showing yours.
3. It turns on reporting. The rua= address receives daily aggregate reports naming every source sending mail as your domain. This is usually the first time a business discovers which tools send mail in its name.

A DMARC record at p=none blocks nothing. It watches impersonation happen and files a report about it. That is the correct place to start and the wrong place to stay, and it is where the majority of domains that have DMARC at all are stuck today. We have written about moving from none to quarantine to reject separately, because that is the step most providers never take.

The order matters more than the speed

This is the part that gets businesses into trouble. Publishing p=reject before your real mail authenticates cleanly does not stop attackers first. It stops you first, because your own invoices are the mail flowing through the systems you forgot about.

The sequence that does not break anything:

1. Inventory every sender. Every domain you own, and every service that sends mail as you. This list is always longer than expected.
2. Fix SPF and DKIM. Get every legitimate sender authenticating properly. DMARC cannot enforce anything until your real mail has something valid to pass against.
3. Publish DMARC at p=none. Collect reports for two to four weeks. Watch until every legitimate stream authenticates cleanly.
4. Move to p=quarantine. Optionally with pct= to ramp gradually.
5. Move to p=reject. Once the reports are clean and stay clean.

Steps three and four are where the time goes, and skipping them is the single most common way an email authentication project goes wrong.

What “done” looks like

Forged email claiming to be your business is refused by receiving servers rather than delivered. Your legitimate email stops being treated as suspicious, which usually improves deliverability. Somebody reads the reports, so you know who sends mail as your domain. And when a client sends you a security questionnaire asking about email authentication, you can answer it truthfully and in writing.

You can see where your domain stands right now with the free domain security checker. It runs in your browser, takes about twenty seconds, and if your domain comes back clean we will tell you so. If it does not, here is how we fix it.