How to set up SPF, DKIM and DMARC for a sending domain

1. Choose a dedicated sending subdomain

Send from a subdomain, not from the domain you answer mail on. Something like send.example.com or mail.example.com, reserved for the mail your software sends, with example.com itself left for the messages you write to people by hand. The reason is recoverable damage. Reputation attaches to the domain that signs the mail, so a bad month on a sending subdomain can be retired and replaced in an afternoon, while the same month on your root domain follows your invoices, your password resets and your replies to customers, and cannot be replaced at all.

A subdomain also lets you separate kinds of mail later without starting over. One subdomain for course and campaign mail, another for transactional receipts, is the standard shape, and it means a complaint rate earned by marketing does not decide whether a receipt arrives.

Whatever you choose, write it down before you touch DNS, because the next three records all hang off it and a record published against the wrong host is the most common failure in this whole process.

2. Publish an SPF record for that subdomain

SPF, defined in RFC 7208, is one TXT record on the sending domain that names the servers allowed to send for it. In practice you do not list servers: your provider publishes an SPF domain of its own and you include it, which keeps working when they change infrastructure. One TXT record, one v=spf1 string, and no second SPF record on the same host, because two SPF records is a permanent error rather than a merge.

End the record with -all rather than ~all once you are sure the include list is complete. A hard fail tells receivers to reject mail from anywhere else; a soft fail tells them to accept it and note it. The soft version is the safer starting point and the worse resting place.

Remember that SPF is checked against the envelope sender, not the From line a reader sees, so this record alone proves nothing about your visible identity. That is what DMARC is for, three steps down.

3. Publish the DKIM keys your provider issues

DKIM, defined in RFC 6376, signs the message with a private key your provider holds and publishes the matching public key in your DNS under a selector, which is just a label allowing more than one key to exist at once. Most providers hand you one or two CNAME records to add; some hand you a long TXT record containing the key itself. Either is fine. What matters is that the signature names your sending domain rather than the provider’s.

Check that specifically, because it is the difference between building your own reputation and renting a share of somebody else’s. In the headers of a signed message the signature carries a d= value; it should read d=send.example.com. If it reads the provider’s domain, the domain setup is not finished, however green the dashboard looks.

Add both selectors if you are given two. Providers rotate keys, and a rotation into a selector you never published fails silently on the day it happens.

4. Publish DMARC at p=none with a reporting address

DMARC, defined in RFC 7489, is a TXT record at _dmarc on the domain in your visible From line. It says that the From domain must align with a domain that passed SPF or DKIM, tells receivers what to do when nothing aligns, and asks them to send you aggregate reports. Publish it with p=none first. At p=none nothing is quarantined or rejected, so the record cannot break anything, and the reports start arriving immediately.

Put a real address in rua= and make sure somebody can read it. The reports are XML, one per receiver per day, and they are the only place you will learn that some fraction of your mail is failing alignment. Set adkim=s and aspf=s if you want strict alignment, meaning the exact domain rather than any subdomain; relaxed is the default and is usually enough while you are starting out.

Publish a record for the root domain as well as the sending subdomain, even if the root never sends. A domain with no DMARC record is a domain anyone can put in a From line, and the root is the one worth impersonating.

5. Read the reports for about two weeks before changing anything

Two weeks is the usual window and the reason is coverage rather than statistics: it takes that long for every system that sends mail under your name to have sent some. The list is always longer than expected. A helpdesk tool, an invoicing service, a form notifier, a calendar, a colleague’s client configured years ago, and a forwarding rule at a university that breaks SPF on every message it touches.

What you are looking for in the reports is mail that failed alignment and is yours, which is a configuration you have not finished, as against mail that failed and is not yours, which is either spoofing or a forwarder. The first kind has to be fixed before you tighten the policy. The second kind is the reason to tighten it.

Aggregate reports are readable by hand for a small sender, and there are free parsers if the volume gets annoying. Either way, read them rather than filing them. A policy moved to reject on top of an unread report is how a month of invoices stops arriving.

6. Move the policy to quarantine, then to reject

Once the reports show only mail you recognise passing and nothing of yours failing, change p=none to p=quarantine. Quarantined mail goes to the spam folder rather than being refused, so a mistake at this stage is visible and recoverable. Leave it there for a week or two and read the reports again.

Then move to p=reject, which is the point of the exercise: mail that claims your domain and cannot prove it is refused at the door. You can step there gradually with pct=, which applies the policy to a percentage of failing mail, though for a small sender the ramp buys less than it costs in confusion.

Nothing about the bulk sender rules requires reject. Google and Yahoo ask only that a DMARC record exist, and p=none satisfies that. Reject is what stops other people sending as you, which is a separate benefit worth the two weeks it takes to get there safely.

7. Verify with a test message and read its headers

Send a real message from your real sending setup to a mailbox at one of the large consumer providers, open the original message source, and read the Authentication-Results header. You are looking for three passes: spf=pass, dkim=pass, and dmarc=pass. Two out of three is the state most people ship in, and the missing one is almost always alignment.

Check the d= value in the DKIM-Signature header while you are there, and check the Return-Path, which is the domain SPF was actually evaluated against. If the Return-Path is your provider’s domain and DKIM signs yours, you will pass DMARC on the DKIM side and fail it on the SPF side, which is fine but worth knowing.

Then send to a second provider, because filtering decisions differ and one provider passing is not evidence of the other. Two mailboxes at two operators, once, is the whole test.

8. Record what you published, and re-check it twice a year

Write the four records into a file in your repository, with the date and the reason for each. DNS is the piece of infrastructure with no history, no diff and no review, usually edited in a web console at speed by whoever had the login, and a record nobody can explain is a record nobody will dare to change.

Put a reminder in for every six months. Keys get rotated, providers change their SPF include, a service gets added that sends under your name, and a DMARC report nobody reads is the only place any of that is visible. Ten minutes twice a year is the entire maintenance cost of authentication once it is working.