How to set up SPF, DKIM and DMARC for Spam Protection with Mautic

Email deliverability is key when it comes to email marketing. Helping to fight spam can increase your sending reputation drastically.

There are three spam protection features that an email sever can and should implement:

• SPF (Sender Policy Framework)
• DKIM (DomainKeys Identified Mail)
• DMARC (Domain-based Message Authentication, Reporting & Conformance)

SPF, DKIM and DMARC each fulfill a specific role for fighting spam:

• SPF checks if the email sending server is allowed to send emails for your domain.
• DKIM verifies the integrity of the email content.
• DMARC uses SPF and DKIM to a) enforce rules and b) report back to you on email authenticity.

Together, they improve email security, combat spam, and enhance the deliverability of legitimate emails, including your marketing campaigns.

This is a two layered process:

• Emails have to originate from servers you authenticate via SPF.
• DKIM ensures that emails are untampered.

How does this work in detail, and how do you set it up?

SPF (Sender Policy Framework)

SPF is a DNS TEXT entry that specifies which mail servers are permitted to send emails on behalf of your domain.

SPF is basically like a whitelist list for your domain. When an email is sent, the receiving email server checks this list to see if the sender's server is on it. If it's on the list, the email is more likely to be genuine.

How it works

1. You publish a SPF whitelist in your DNS settings.
2. Every email that is sent comes from a server this server has an IP address.
3. The receiving server retrieves the SPF record from the sender's DNS and checks it against the IP address the email was sent from.
4. If the IP addresses match, the email is likely to be authentic. If not it is most likely spam.

How to set it up

Setting SPF up is easy: You as domain owner publish an SPF record in the DNS.

1. Add a TXT entry to your DNS
2. Lists the IP addresses or domains that are authorized to send emails on behalf of your domain.

How do I configure the SPF DNS TXT entry? An example might look like this:

v=spf1 ip4:123.456.789.123 include:amazonses.com ~all

Let's break this down.

• v=spf1⁣—the version of SPF used. There is just V1.
• ip:123.456.789.123⁣—emails originating from this IP are legitimate.
• include:amazonses.com⁣—means emails sent from Amazon's SES servers are allowed, too. You will most likely use this setting.
• ~all—defines the policy.
  • Use ~all (soft fail) to start with. Emails that don't match your SPF get delivered but will land in your recipient's spam folder.
  • -all (hard fail) can be used once you're confident in your SPF record. This tells email service providers to reject emails that don't match your SPF.
• You can add up to 10 ip or include lookups. (or a or mx—they basically say: Look up an A or AAA or MX DNS record)

DKIM (DomainKeys Identified Mail)

DKIM adds a digital signature to the headers of your emails. Email service provider like Gmail or Yahoo and email clients like Thunderbird can use this signature to verify it against a public cryptographic key in your domain's DNS records.

DKIM is like a secret handshake for your emails. When you send an email, it gets a unique digital signature. The receiving server can check this signature against a public key in your domain's DNS records to ensure the email hasn't been tampered with.

It's hard (i.e., impossible) for spammers to forge this signature, so it's a powerful tool against email spoofing.

How it works

1. You or your email transport provider (Amazon SES, Mailgun, etc.) create a pair of (most likely SHA/RSA 2048 bit) private and public encryption keys.
2. You publish the public key in a DNS TXT entry.
3. Your mail server signs outgoing emails by adding a DKIM-Signature email header. Your email contents and other headers are used to compute the signature.
4. The recipient's email service provider fetches the DKIM public key via your DNS entry. It uses this key, the email body and specified headers to compute a signature for the email.
5. If this signature matches the DKIM-Signature header then the email is authentic and was not tampered with.

How to set it up

Setting DKIM takes more steps than setting up SPF. But this is usually done through your email service provider.

1. You (or your ESP) creates the encryption keys.
2. You (or your ESP) configures the email server to use the private key to create the DKIM-Signature, and sign all emails.
3. You publish a TXT (or CNAME) record in your DNS. There are two options:
   1. A TXT record that includes the public key right away.
   2. A CNAME record that holds a lookup for the public key. This method is probably used by your email service provider.

How do I configure the DKIM DNS TXT entry? An example might look like this:

k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQD...

Let's break this down.

• k=rsa⁣—the encryption algorithm used.
• p=MIGf...⁣—the published public key.

And the CNAME DKIM DNS entry might look like this:

• Name: lookupdescriptor._domainkey.yourdomain.com
• Data: lookupdescriptor.dkim.emailserviceprovider.com

DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC fulfills two jobs:

1. DMARC builds on SPF and DKIM. It uses SPF and DKIM to make a rule book for your emails. It tells email receivers what to do if an email doesn’t pass SPF or DKIM checks (like reject the email or put it in spam).
2. DMARC also asks receivers to report back on emails they get from your domain.

How it works

1. By itself DMARC doesn't do much.
2. Having a DMARC DNS record tells receivers that you use SPF and DKIM. Receivers know now to check for them.
3. DMARC tells the receivers how emails that SPF/DKIM checks are to be treated.
4. DMARC gives the receivers a way to report back to you.

How to set it up

Setting DMARC up is easy: You as domain owner publish an DMARC record in the DNS.

1. Create a TXT record with the name _dmarc.
2. Add the following as data into the record:

v=DMARC1; p=none; rua=mailto:info@mydomain.com

Let's break this down.

• v=DMARC1—the DMARC protocol version.
• p=none—the DMARC policy you want receivers to enforce.
  • none—start with this entry level policy. It tells recipients that no special treatment is required. But this enables you to receive deliverability feedback reports.
• quarantine—receivers should treat DMARC-failed emails as suspicious. This can be done by delivering them into the spam folder or flag them. Use with caution.
• reject—most strict. This tells receivers to outright reject messages that fail DMARC checks. Use with caution.
• rua=mailto:info@mydomain.com—an address to send aggregate reports to.
• By default aggregate reports are sent once a day. ri=time in seconds let you define another reporting interval.

There are more options. Consult the documentation.

Enforcing a quarantine or reject policy, should be done cautiously. You want to avoid legitimate emails being mistakenly blocked or marked as spam.

Therefore, you should do monitoring with a none policy over a period of time and adjust SPF/DKIM if need be.

To recap, SPF checks if the sender's server is allowed to send emails for your domain, DKIM verifies the integrity of an email's content, and DMARC controls policy enforcement rules and adds reporting on email authenticity. Together, they improve email security, combat spam, and enhance the deliverability of your legitimate emails.