SPF, DKIM and DMARC explained, with the records you will actually publish

Three DNS-based checks let a receiving server decide whether a message claiming to be from your domain is genuine. They answer different questions.

| | Question it answers | Where it is published | What it checks | |---|---|---|---| | SPF | Is this server allowed to send for this domain? | TXT record on the domain | The connecting server's IP against a list | | DKIM | Was this message signed by the domain and left unmodified? | CNAME or TXT at selector._domainkey.domain | A cryptographic signature in the headers | | DMARC | Do SPF or DKIM pass for the domain in the From header, and what should happen if not? | TXT record at _dmarc.domain | Alignment, plus your policy |

SPF

SPF lists the servers allowed to send mail using your domain in the SMTP envelope sender (the return path). A record looks like:

v=spf1 include:amazonses.com ~all

include: pulls in another sender's list, and ~all means "soft-fail anything else". Rules that catch people out:

• One record per domain. Two SPF TXT records make both invalid. Merge them.
• Ten DNS lookups at most. Each include, a, mx counts, and nested ones count too. Past ten, SPF returns a permanent error.
• SPF breaks on forwarding, because the forwarder's IP is not in your list. That is one reason DKIM matters.

DKIM

The sending system signs selected headers and the body with a private key. Receivers fetch the public key from DNS and verify. If a signature verifies, the message was not altered in transit and the signing domain approved it.

With Inboxili, DKIM uses three CNAME records of this form, which you add in your DNS:

<token1>._domainkey.yourdomain.com  CNAME  <token1>.dkim.amazonses.com
<token2>._domainkey.yourdomain.com  CNAME  <token2>.dkim.amazonses.com
<token3>._domainkey.yourdomain.com  CNAME  <token3>.dkim.amazonses.com

The tokens are specific to your domain and are shown in the Deliverability Center when you add it. Because they are CNAMEs, key rotation is handled on the provider side.

DMARC

DMARC adds two things. First, alignment: a pass only counts if the domain that passed SPF or DKIM matches the domain in the visible From address. Second, a policy for failures and an address for reports.

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

p=none only monitors. p=quarantine asks receivers to treat failures as suspicious, and p=reject asks them to refuse. Inboxili suggests the monitoring record by default so you do not block your own legitimate mail by accident.

Why alignment is the part people miss

If SPF passes for mail.provider.net but your From says you@yourdomain.com, SPF passes but does not align. DKIM signed with d=yourdomain.com aligns. This is why a verified sending domain with its own DKIM keys matters more than a shared sender address.

Inboxili also provides records for a custom MAIL FROM subdomain (mail.yourdomain.com) with its own MX and SPF entries, so the SPF check happens on a subdomain of your domain rather than the provider's.

Rollout order that works

1. Publish SPF and DKIM through your provider's setup screen. Wait for the verified status.
2. Publish DMARC at p=none with a reporting address.
3. Read reports for a few weeks. Find every system that sends as your domain: CRM, helpdesk, billing.
4. Fix or authenticate each legitimate sender.
5. Move to p=quarantine, then p=reject once reports are clean.

Checking your setup

• Look up each record with dig TXT yourdomain.com, dig TXT _dmarc.yourdomain.com and dig CNAME <token>._domainkey.yourdomain.com.
• Send yourself a message and read the Authentication-Results header in Gmail's "Show original" view. You want spf=pass, dkim=pass and dmarc=pass.

What these do not do

Passing all three does not guarantee inbox placement. It proves identity. Reputation, content and recipient behaviour still decide the folder. See transactional email deliverability.