SPF, DKIM and DMARC in plain words

Anyone can type your address into the From line of an email. The sending system does not check. That is why receiving servers look for proof, and why mail from a domain with no proof is more likely to land in spam, or to be refused.

The proof comes in three parts, called SPF, DKIM and DMARC. You do not need to configure them yourself, but you should know what they are, because a few questions to the right person can fix a lot of missing mail.

SPF: who may send

SPF is a list, published in your domain's DNS records, of the servers allowed to send mail with your domain in the sending address. A receiving server looks the list up and compares it with the server that actually delivered the message.

Think of it as a guest list at the door. If the server is not on it, that is a mark against the message. If a service sends for you and is missing from the list, its mail starts to fail, even though it is yours.

DKIM: not changed, and vouched for

DKIM is a signature. The sending server signs each message with a private key, and your domain publishes the matching public key in DNS. The receiving server uses that key to check two things: the message was signed for your domain, and nothing in it changed on the way.

SPF checks the server. DKIM checks the message, which is why DKIM survives forwarding better. A forwarded message comes from a new server, so SPF no longer fits, but the signature still does.

DMARC: the rule that ties them together

DMARC does two jobs.

1. 1

   It insists that the domain the reader sees in the From line is the one that passed SPF or DKIM. Without it, a message could pass SPF for some unrelated domain while showing yours.

2. 2

   It tells receivers what you want done with mail that fails: nothing special (none), put it in spam (quarantine), or refuse it (reject).

It can also ask receivers to send you reports, which is how you find the services that send as you without being listed.

What to ask whoever runs your domain

Your domain's DNS is usually managed by your web host, your IT supplier or one person on the team. These questions are enough to start.

1. 1

   Is SPF published for our domain, and does it include every service that sends as us, such as our mail provider, our invoicing tool and our newsletter tool?

2. 2

   Is there exactly one SPF record? A domain should have only one, because with two the SPF check fails.

3. 3

   Is DKIM switched on at our mail provider and at each other service that sends as us?

4. 4

   Do we have a DMARC record? If it is new, start with none and read the reports. When they show only mail you recognise, move to quarantine, and later to reject.

5. 5

   Who gets the DMARC reports, and will someone actually read them?

If you send from an address on a domain that is not yours, such as a free mail address, there is nothing for you to set up. The provider already does it.

Where DMU Mail uses the checks

DMU Mail does not ask you to configure anything here. It reads the result that your mailbox's own provider recorded when the mail arrived, and uses it in three places.

• The spam filter: it weighs SPF, DKIM and DMARC results, along with your provider's spam flag and display names that copy another address. How strict it is, Light, Standard or Strict, is set in Settings › Spam & senders. See Team spam filter.

• Company logos: a company's logo shows beside its mail only when DKIM or DMARC passed for the sender's domain. A forged address keeps its plain initials. See Company logos.

• The notice for mail from outside: it stays on a message that cannot prove it came from its domain.

A message that failed its sender check can never get a real sender blocked by mistake: Block is not offered on it.