Anticode Open builder

SPF, DKIM, DMARC explained for small businesses

SPF lists which servers may send mail for your domain. DKIM signs each message so receivers can check it wasn't forged or altered. DMARC ties both to the address people see in the From line and tells receivers what to do when checks fail. Set them up in that order, start DMARC in monitoring mode, and tighten it once every service that sends as you passes.

Updated · By the Anticode team

Why receivers care

Anyone can type your address into the From line of an email. Authentication lets the receiving server tell real mail from forgeries. Gmail's email sender guidelines require every sender to personal Gmail accounts to use SPF or DKIM, and bulk senders (more than 5,000 messages a day) to use SPF, DKIM and DMARC with alignment. Small businesses are rarely bulk senders, but mail without authentication is more likely to be filtered, and your domain is easier to impersonate.

What each record does

SPF
A TXT record on your domain starting v=spf1, listing the servers allowed to send for it, for example v=spf1 include:_spf.yourmailprovider.example ~all. RFC 7208 says a domain may have only one SPF record, and evaluation is capped at ten DNS lookups; going over either limit makes SPF fail with a permanent error.
DKIM
Your mail provider signs each message with a private key and adds a DKIM-Signature header naming your domain (d=) and a selector (s=). Receivers fetch the public key from a TXT record at selector._domainkey.yourdomain, as defined in RFC 6376. A valid signature proves the message came from someone holding the key and wasn't changed on the way.
DMARC
A TXT record at _dmarc.yourdomain with a policy: none (monitor only), quarantine (treat as suspicious) or reject. It passes only if SPF or DKIM passes and the domain they checked matches the domain in the visible From address. The current standard is RFC 9989, which replaced RFC 7489 and drops the old pct tag in favour of a t=y test mode.

Set them up in this order

  1. List everything that sends as your domain. Your mailbox provider, a newsletter tool, an invoicing app, a booking system, your website's contact form if it sends from your address. Missing one is the usual cause of failures later.
  2. Publish one SPF record that includes each sender's SPF value. Merge them into a single line; don't add a second record. End with ~all while you're testing.
  3. Turn on DKIM in each sending service. Most give you one or two CNAME or TXT records to add. Mail sent before this step won't be signed.
  4. Publish DMARC in monitoring mode: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain. The rua address receives daily aggregate reports from large mailbox providers.
  5. Read the reports for two to four weeks. They list every source that sent as your domain and whether it passed. Fix any legitimate sender that fails, usually by enabling DKIM with your domain in it.
  6. Tighten the policy to quarantine, then reject, once only forgeries fail.

Alignment, the part that trips people up

A newsletter tool might pass SPF for its own bounce domain and DKIM for its own domain, while your address sits in the From line. Both checks pass, but neither is about your domain, so DMARC fails. The fix is to set up the tool's "authenticate your domain" option, which signs with DKIM as your domain or uses a return-path on your domain. Alignment is why DMARC actually stops spoofing: a forger can pass SPF for their own domain, but not for yours.

Check them

  • dig yourdomain TXT +short shows the SPF record. There should be exactly one line starting v=spf1.
  • dig _dmarc.yourdomain TXT +short shows the DMARC policy.
  • dig selector._domainkey.yourdomain TXT +short shows a DKIM key; the selector is in your provider's settings or in a sent message's DKIM-Signature header.
  • Send a message to a personal webmail account and view the original. Look for spf=pass, dkim=pass and dmarc=pass in the Authentication-Results header.

Common mistakes

  • Two SPF records, one per provider. Merge them.
  • Too many include: entries, pushing SPF over ten lookups. Remove services you no longer use.
  • -all or p=reject on day one, before every sender is set up, so your own invoices bounce.
  • A DKIM record pasted with line breaks or quotes in the wrong place.
  • Forgetting a domain you don't send from. Publish v=spf1 -all and a p=reject DMARC record on parked domains, so nobody can send as them.

Where your website fits

These records belong to whoever sends mail as your domain, so they're set at your DNS host with your mail provider's values. Anticode isn't an email provider and these records aren't part of connecting a domain to an Anticode site, which uses a CNAME and sometimes a TXT record for ownership. If your form notifications are being filtered, the form emails going to spam guide covers the other causes, and setting up email with a custom domain covers the mailbox side.

Questions people ask

Do I need all three?

For reliable delivery and protection from spoofing, yes. SPF and DKIM prove where mail came from; DMARC links them to the visible sender and tells receivers what to do with failures.

What does p=none do?

Nothing to delivery. It asks receivers to send you reports, so you can see who sends as your domain before enforcing a policy.

Can I have two SPF records?

No. Two records cause a permanent error and SPF fails. Combine every sender into one record.

Sources

  1. Gmail Help: Email sender guidelines, checked
  2. RFC 7208: Sender Policy Framework (SPF), checked
  3. RFC 6376: DomainKeys Identified Mail (DKIM) Signatures, checked
  4. RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC), checked