SPF

This is basically a list of the servers allowed to send email in your name. This is not the same as sending email from your phone, laptop, or webmail. These all connect to the same email server. An SPF records typically refers the following examples of email servers:

• Your primary email server (e.g., your mail provider’s SMTP server).
  • The website hosting company
  • Microsoft
  • Google etc.
• The platform you use for mailing lists
  • Mailchimp
  • Kajabi
  • Sender etc.

Examples

v=spf1 include:sendersrv.com include:relay.k.io ~all

We can see here, for instance, that email is allowed to be sent in my name by servers with the addresses sendersrv.com and a relay.k.io, and that for ‘all’ the email a ‘soft-fail’ (indicated by the ~ symbol) policy is applied; meaning that email which fail the SPF test will be tagged as failed, but allowed proceed to the recipient’s mailbox. A hard fail ( – ) would run the risk of rejecting emails which are valid, but which have been forwarded from someone.

sendersrv.com is the platform used to send newsletters, and relay.k.io refers to the email server of the hosting company for the website in question.

For instance, if a spammer sends an email from their own server in your name, their email server won’t be listed in the SPF record. If an email is sent from a server not listed in your SPF record, the recipient’s email system can flag it as suspicious or reject it based on the DMARC policy (see below).

SPF hardfail example

v=spf1 ip4:192.168.0.1 -all

In the provided example, the minus symbol (in front of all at the end of the record) indicates that any senders not listed in this SPF record should be treated as a hardfail. This means they are unauthorised, and emails from them should be discarded. In this case, only the IP address 192.168.0.1 is authorised to send emails, and nothing else.

This means that there is a strong risk that legitimate emails which are forwarded or auto-redirected will fail, since the forwarding server won’t match the sending server.

SPF softfail example

v=spf1 include:spf.protection.outlook.com ~all

In the example above, the tilde symbol (in front of all at the end of the record) means that any senders not listed in this SPF record should be treated as a softfail. This means that the mail can be allowed through, but it’ll be tagged as spam or suspicious. In this case, the include:spf.protection.outook.com mechanism gave Microsoft 365 the green light to send emails. Any emails coming from different servers will be marked as spam by the receivers.

DKIM

This TXT record contains a digital signature that is added to the headers of an email. This signature is generated using a private key and can be verified by recipients using a public key published in the sender’s DNS records. This ensures that the email was indeed sent by the domain it claims to be from and that its content has not been altered in transit.

The contents of a DKIM record could, in part, look like this:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3YBSWpiwQtktDgdZOxoB/LwBHOsafxXTqMV9TFgkNo2gkfiHznZKGBOlXIyqE9bALvyaLARUWOTYHyG4dWKLdPTOy2MLnD48h3F7OQmzCYRJkJ/a+xvWqeXu5UjqWvilSopUVkXHNE1Wl1F+oHbjr+jUvu0iZE7637Jx ........

DMARC

The DMARC record tells the recipient’s mail server how to handle emails that fail SPF or DKIM checks.

The laziest response it can have is, “meh .. 🤷🏼”.

v=DMARC1; p=none;

The “p” tag stands for Policy, and here there isn’t any. This basically just tells the recipient server, “Let the email go through. If it’s phishy ( 😉 ), just use your best judgement.”

A much wiser use of the DMARC record could be something like:

v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@example.com;

Source: https://www.emailtooltester.com/en/blog/dmarc-record-example/

This tells the recipient server to apply the policy to 50% of emails that fail SPF and DKIM checks: Quarantine them, and send failure reports to dmarc-reports@example.com.

An ideal record would be something like:

v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fails@example.com;

When applying policy other than “none”, important to be sending the reports. Without reporting (and actually reading those reports), you will have no way to know how effective your settings are, and if legitimate emails are getting blocked by accident.

🔗 My DMARC monitoring service handles this for you.

How strict you make things is up to you, and also depends on how much energy you personally have to wade through the reports, which from my experience need a tools decider. You can use tools at MXToolbox.com for this.

One this is done, the next step is to monitor your emails using DMARC reports to make sure that all the settings are correct, and that the emails are arriving properly. If they are aren’t then the results of the monitoring will help you correct the situation.

🔗 Read more about this here: Email threats – Response and monitoring

Check your domains email security stance

Quickly check your email security stance with the free tool below.