Skip to content

Documentation

SPF, DKIM and DMARC.

Three DNS-based checks that let a receiving server confirm that your domain really sent a message. What each one does, and what you publish.

Why receivers check

Anyone can write any address in the From line of an email. Receiving servers therefore ask three questions before they trust a message that claims to come from your domain: is this server allowed to send for it (SPF), is the message signed by it (DKIM), and what should I do if the answers are wrong (DMARC). Mail that fails is more likely to be filtered or refused, so sending from an authenticated domain is the single most useful thing you can do for delivery.

SPF: which servers may send

SPF is a DNS text record that lists the servers allowed to send mail for a domain. A receiver looks at the domain in the message's return path (the address bounces go to, set during delivery and not shown to the reader), finds its SPF record, and checks that the connecting server is on the list. Mailtruss gives you an SPF record to publish on a return-path subdomain of your sending domain, together with an MX record that receives bounce notices. Two limits to know: an SPF record may trigger at most ten DNS lookups in total, and a domain should have only one SPF record.

DKIM: a signature on the message

With DKIM, the sending side signs each message with a private key, and the receiver checks the signature with a public key published in DNS. If the message was changed on the way, or was not signed by someone holding the key, the check fails. Mailtruss gives you three CNAME records that point at its signing keys under your domain, so messages are signed as your domain. A domain counts as verified only when all of its required records, these three included, have been found.

DMARC: the policy that ties them together

DMARC tells receivers what to do when a message fails, and it adds one rule: the domain that passed SPF or DKIM must align with the domain in the visible From address. It is published as a text record at _dmarc under your domain:

DNS TXT record
_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

The p value is the policy: none only reports, quarantine asks receivers to treat failures as suspicious, and reject asks them to refuse. The rua address receives daily summary reports of who is sending mail as your domain. Mailtruss does not publish a DMARC record for you, because only the domain's owner can set the policy; the domain's page shows whether one exists.

A safe way to start

  1. Add the sending domain and publish the records it shows: see Domains. Wait until it shows Verified.
  2. Send from an address on that domain. Mail from a different domain will not align.
  3. Publish a DMARC record with p=none and a report address, and read the reports for a few weeks to see everything that sends as your domain.
  4. Once everything legitimate passes, tighten the policy to quarantine, and later to reject if you want the strongest protection.

When it fails

A receiver that rejects mail for failed authentication returns a 5.7 status code, often with the words SPF, DKIM or DMARC in the reply. The guide to bounces for failed authentication lists the codes, the usual causes and the fixes. The most common causes are a missing record, a proxied DNS record, and sending from a domain other than the verified one.

Last updated

Something wrong or unclear on this page?

Report an issue