SPF, DKIM and DMARC: why your business email lands in spam

You sent a proposal and the client says it never arrived. Order confirmations pile up in customers’ spam folders. Most of these complaints are not about the email’s content but about your domain’s DNS records.

Short answer: before accepting an email, a receiving server asks one question: “Does this mail really come from this domain?” Three DNS records answer it: SPF, DKIM and DMARC. If they are not set up correctly, your email looks suspicious.

SPF: who may send?

SPF (Sender Policy Framework) is the list of servers allowed to send email for your domain. It is a single TXT record on the domain:

venus.tr.  TXT  "v=spf1 mx include:_spf.provider.com -all"

This record allows the domain’s MX servers and the named provider and rejects everything else. Common mistakes:

• More than one SPF record. A domain can have only one v=spf1 record. A second provider is added to the same record with include:.
• Forgotten senders. Your website’s form, your invoicing software and your newsletter tool all send mail in your name. If they are not in the list, their mail fails SPF.
• The 10-lookup limit. Every include is a DNS lookup, and an SPF record that needs more than 10 is invalid.

DKIM: did the email change on the way?

DKIM (DomainKeys Identified Mail) means the sending server signs every message with a private key. The public key that verifies the signature is published in DNS:

mail._domainkey.venus.tr.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

The receiving server checks the signature with that key. If it matches, the message was not altered in transit and really came from the key’s owner. Every sending service (business mail, newsletter tool, application SMTP) needs its own DKIM key, published under its own selector.

DMARC: what happens to mail that fails?

DMARC is the policy on top of SPF and DKIM. It tells the receiving server what to do with mail that fails authentication, and has reports sent to you:

_dmarc.venus.tr.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

p=none only monitors, p=quarantine sends failing mail to spam, p=reject refuses it. Starting straight at reject can silence a forgotten sender overnight, so we follow this order:

1. Start with p=none and collect reports for a few weeks.
2. Add the legitimate senders the reports reveal to SPF and DKIM.
3. Raise the policy to quarantine, then to reject.

How to check

You can see whether the records are live from the command line:

dig +short TXT venus.tr
dig +short TXT mail._domainkey.venus.tr
dig +short TXT _dmarc.venus.tr

To see whether a message actually passed, look at its headers on the receiving side (Authentication-Results): we want spf=pass, dkim=pass and dmarc=pass.

Summary

The spam folder problem is usually an identity problem, not a content problem. SPF says who may send, DKIM proves the message was not changed, and DMARC says what happens to mail that breaks the rules. Together they let receivers verify that the mail comes from you.

If you want your domain and email setup put in order, see our domains and business email service.