How to Set Up SPF, DKIM and DMARC on Your Domain

To set up SPF, DKIM and DMARC you publish three sets of DNS records on the domain that appears in your envelope sender and your message headers: a TXT record listing the hosts allowed to send for you, a public key that receivers use to verify a cryptographic signature, and a policy record that tells receivers what to do when neither of those checks passes. Everything else is bookkeeping. The records are just text in DNS, and the receiver does all the work at delivery time.

The reason to bother is that mailbox providers decide placement largely on whether the message authenticates. A message that fails or has no authentication has no reputation to inherit, so it starts from nothing every time. If you are asking how to set up SPF, DKIM and DMARC on a domain you already control, the work is done in that order, because DMARC depends on the other two being aligned.

Start with SPF, the list of permitted senders

SPF is a TXT record at the domain apex, and it is a list of mechanisms, not a list of addresses. The receiver takes the envelope sender (the MAIL FROM in the SMTP transaction, which is often not the visible From: header), extracts the domain, looks up that domain's TXT record, and walks the mechanisms left to right until one matches the connecting IP.

example.com.  TXT  "v=spf1 include:_spf.provider.example -all"

The v=spf1 token must come first. The include: mechanism triggers a second lookup of another domain's SPF record and matches if that record would pass. a matches the host's own address records, mx matches the domain's mail exchangers, ip4 and ip6 match literal addresses or ranges, and all matches everything. The qualifier in front of a mechanism, + for pass, - for fail, ~ for softfail, controls what happens on a match. Most domains want -all at the end once they are confident the list is complete, and ~all while they are still finding stray senders.

Two limits matter. The lookup budget is ten DNS lookups per SPF evaluation, and include, a, mx, ptr, exists and redirect each consume one, with includes nesting. Go over and the receiver returns permerror, which is worse than no record at all. Keep the chain flat. And a record over 255 characters has to be split into multiple quoted strings in the same TXT record; the receiver concatenates them, so the split is invisible to the parser.

Add DKIM so the message carries a verifiable signature

DKIM is different in kind. SPF checks the path the message took; DKIM signs the content, so it survives forwarding as long as nothing rewrites the signed headers. Your mail system generates a key pair, signs outgoing messages with the private half, and you publish the public half in DNS at a selector you choose.

mail._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G..."

The selector (mail above) is arbitrary; you pick it and configure your signer to match. That lets you rotate keys by publishing a new selector, switching the signer, and retiring the old record later. The p= value is the base64 public key, and it is long. Some DNS providers split long values automatically and some do not, so check the published record after you save it rather than trusting the control panel.

The signer adds a DKIM-Signature header to each message. It names the selector, the signing domain, the headers it covered, and the body hash. The receiver fetches the public key from selector._domainkey.domain, canonicalizes the headers and body the same way, and compares. Because the signature covers only the headers listed in h=, a header added in transit does not break it, but a header that gets rewritten does. Mailing lists and forwarders that modify the subject line or append a footer are the usual cause of DKIM failure on otherwise clean mail.

Publish a DMARC policy once SPF and DKIM align

DMARC ties the two together and adds a reporting channel. It asks a single question: did SPF or DKIM pass for the domain in the visible From: header? That alignment requirement is what makes DMARC more than a sum of its parts. SPF can pass on a bounce domain that has nothing to do with the From: domain, and DKIM can pass on a signature from a third party; neither counts unless the authenticated domain aligns with From:, either exactly or, with relaxed alignment, on the organizational domain.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r"

The p= tag is the requested policy: none means monitor only, quarantine asks for spam placement, reject asks for refusal. rua is where aggregate reports go, one XML file per reporting domain per day, and ruf is for forensic reports, which most large receivers no longer send because of privacy concerns. The adkim and aspf tags set strict (s) or relaxed (r) alignment; relaxed is the sensible default.

Start at p=none with a rua address you actually read. The aggregate reports tell you which IPs are sending as your domain and whether they pass. When the reports show only known senders passing, move to quarantine, then to reject. Skipping the monitoring step is how people discover, after the fact, that a billing system or a helpdesk tool was sending from an unlisted host.

Verify the records and the path

Query DNS directly rather than trusting the control panel, because the panel shows what you typed and DNS shows what was published.

dig +short TXT example.com
dig +short TXT mail._domainkey.example.com
dig +short TXT _dmarc.example.com

Then send a real message to a mailbox you control and read the Authentication-Results header the receiving system adds. It looks like this:

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

Each line is the receiver's verdict, and each one should say pass along with the domain it authenticated. If SPF fails, compare the connecting IP in the header against your record. If DKIM fails, check that the selector in the signature matches a published record and that no intermediary rewrote a signed header. If DMARC fails while both others pass, the problem is alignment: the authenticated domain does not match the From: domain, which usually means mail is leaving through a provider whose own domain is being authenticated instead of yours.

After that, the routine is maintenance. Keep the SPF lookup count low as you add senders, rotate DKIM selectors on a schedule and remove retired ones, and read the aggregate reports often enough to notice a new sender before your policy rejects it. If you are not yet at p=reject, the next step is to open the most recent aggregate report, list every source IP you do not recognize, and either add it to SPF or stop it from sending as your domain. That single exercise resolves most delivery problems people attribute to spam filtering.