SPF DKIM DMARC Setup Checklist: Seven Steps That Stop Spoofing

An SPF, DKIM, and DMARC setup comes down to seven steps: publish SPF, publish DKIM, publish a DMARC policy in monitor mode, verify all three with a real message, raise the policy, add the reporting address, and check the reports weekly. The records are small. The order and the follow-through are where domains fail. This checklist is written for operators: every step has a test, and no step requires you to understand the RFCs.

We make SuperMailOS, a multi-domain email host, and our SPF, DKIM and DMARC explainer covers the concepts. This piece is the doing-it version, and it works with any provider.

The checklist at a glance

1. Collect what your provider actually needs you to publish
2. Publish SPF (one record, one include)
3. Publish DKIM (the selector and key from your provider)
4. Publish DMARC at p=none with a rua address
5. Send a real message and verify all three pass
6. Raise DMARC to quarantine, then reject
7. Read the aggregate reports weekly

Step 1: Take records from the live zone, not a doc

Every provider publishes DNS instructions, and they rot. The records you want come from the mail server's own zone: the SPF include, the DKIM selector with its actual public key, and the exact DMARC string. If your host cannot show you the live records, that is a finding, not a footnote. In SuperMailOS the records come straight from the server's zone with live verification while you watch, and an unverified domain never sends.

Step 2: SPF, one record, one include

SPF lists which servers may send for your domain. The whole record is one TXT entry at the root:

v=spf1 include:yourprovider.com ~all

Two mistakes dominate. First, multiple SPF records: if you already have one, merge the includes into a single record, because two records is an automatic fail. Second, +all or ?all, which quietly turns SPF off. Use ~all (softfail) while setting up and consider -all once DMARC is enforcing. SPF also has a ten-DNS-lookup limit, so each include should be doing real work.

Step 3: DKIM, the selector and the key

DKIM gives every message a cryptographic signature that survives forwarding. You publish the public key as a TXT record at selector._domainkey.yourdomain, where the selector name comes from your provider. Copy the key exactly: a mangled key fails quietly, and the only symptom is that DMARC reports show signatures not verifying. If you run multiple products, each domain gets its own key. There is no limit to worry about and nothing to tune; publish what the zone gives you.

Step 4: DMARC, start at monitor

DMARC tells receivers what to do when SPF or DKIM fail, and reports back. Always start in monitor mode:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

The rua address is where aggregate reports land, and it is the entire reason to run DMARC: every day, mail receivers send you a summary of what passed, what failed, and which sources pretended to be you. Set the address before anything else, because the reports are how you earn the right to enforce.

Step 5: Verify with a real message

Do not trust the DNS panel. Send a message to a Gmail or Outlook account, open "show original" on it, and read the three verdicts: SPF: PASS, DKIM: PASS, DMARC: PASS. Any fail at this stage is a copy-paste error in step 2 or 3, and fixing it now costs minutes. Tools that inspect raw headers work too; the point is to test a real message, not the DNS lookup alone.

Step 6: Raise the policy

With a week or two of clean reports, move p=none to p=quarantine (failures go to spam), and after another clean stretch, p=reject. If your reports show legitimate mail failing, stop and fix alignment first: DMARC requires the From: domain to match the domain in the passing SPF or DKIM record. Common survivors are newsletters sent from a vendor's domain and a billing system with its own ideas; each needs its own records or an aligned include.

Step 7: Read the reports

The weekly habit is the whole ballgame. Aggregate reports tell you the sources sending as you, the volume, and the pass rates. You are looking for two things: unknown senders (spoofing, or a forgotten tool) and dips in your own pass rate (a broken integration). This is the part providers usually hand to you as a raw XML attachment, which is why we built a DMARC report dashboard into SuperMailOS: parsed reports, per domain, on the Business plan.

A note on many domains

If you run several products, the checklist runs per domain, and the failure mode multiplies: one domain left at p=none for a year is the one that gets spoofed. Keep a simple table of domain, policy, and last-checked date. Operators running portfolios tend to prefer hosts where the loop is closed for them, which is the honest reason we built SuperMailOS the way we did: every domain gets the records, the verification, and the reporting without a checklist. For the conceptual background, the explainer and our guides to email hosting for multiple domains and one inbox for multiple domains go deeper.

Frequently asked questions

How long until DMARC enforcement is safe?

Two to four weeks of clean aggregate reports at p=none is the usual runway. If your mail is all going through one provider, it is closer to days; every extra sending tool adds a week of watching.

Can I skip SPF and just use DKIM?

No. DMARC considers either, but receivers and forwarding behave differently for each, and some mailbox providers still weight SPF heavily. Publish both; the marginal effort is one DNS record.

What does rua= actually give me?

A daily XML summary per receiver: messages seen, which passed SPF/DKIM/DMARC, and the sending IPs. It is the only way to know you are being spoofed before a customer tells you.

Does this stop spam I receive?

Not really. These records protect your domain from being used in spoofed mail to others. To receive less spam, see our piece on catch-all spam risk; to understand the alias side, catch-all vs aliases.