Set up SPF, DKIM, and DMARC.

Mailbox providers do not take a From address on faith. They look up SPF, DKIM, and DMARC, and they use MX to decide where inbound mail should go. This lesson walks each record, then shows the two CNAMEs PostShiba asks you to publish.

Try a domain below. Findings link to the matching section.

SPF lists who may send. DKIM signs the message. DMARC ties both back to the From address the recipient sees. Get those three right, then move on to warm-up and pools.

SPF

SPF is a TXT record that lists who may send mail for a domain. The receiving server looks at the envelope sender, also called MAIL FROM or the return-path, and asks that domain's SPF record whether the connecting IP is allowed.

It does not look at the From header. Adding every vendor to the root SPF, or skipping SPF on the return-path host, both miss the check that actually runs.

Two details cause most of the pain.

The first is the 10-lookup limit. SPF counts a DNS query each time the record uses include, a, mx, ptr, exists, or redirect. Nested includes count too. Cross 10 and the result is a permanent error. The mail fails SPF even if the IP would have matched. Keep the record short. Do not stack every historical vendor on the same domain.

The second is the trailing mechanism. ~all is a soft fail. Receivers usually accept the message and mark it. -all is a hard fail. Receivers that honor SPF should refuse it. Start with ~all while you still have more than one sender. Move to -all once the list is complete and you have watched DMARC reports for a while. Never use +all. That tells the world anyone may send as you.

Build a record below and watch the lookup count as you add includes.

You do not add a PostShiba include to your root SPF. SPF is checked against the return-path domain, and PostShiba answers that check through the rp. CNAME. Leave the root SPF for your mailbox host. See Return-path and How PostShiba sets this up.

DKIM

DKIM attaches a cryptographic signature to the message. The sending server signs selected headers and the body with a private key. The receiving server fetches the matching public key from DNS and verifies the signature.

The public key lives at {selector}._domainkey.{domain}. If that lookup succeeds and the signature matches, DKIM passes. If someone alters the subject or the body in transit, the signature fails.

DMARC also needs alignment. The domain in the DKIM d= tag must match the From domain, or be a subdomain of it under relaxed alignment. Signing as mail.example.com while the From is hello@mail.example.com aligns. Signing as an unrelated zone does not.

PostShiba publishes the public key for you. You add a CNAME from {selector}._domainkey.{domain} to the target on the domain page. You can import an existing DKIM private key and keep your current TXT record instead. An imported key can send before the return-path verifies.

DMARC

DMARC sits above SPF and DKIM. It asks two questions. Did SPF or DKIM pass. Did the passing domain align with the From address the recipient sees.

A pass on SPF that authenticates rp.mail.example.com aligns with hello@mail.example.com under relaxed alignment. A DKIM pass for mail.example.com aligns the same way. Either aligned pass is enough.

The policy says what the receiver should do with a fail.

Climb that ladder. Publish p=none first. Read the reports. Then quarantine. Then reject. Jumping to reject on day one will hide mail from anyone still sending through an old vendor.

pct is the share of failing mail the policy applies to. pct=10 on quarantine means only one in ten failing messages is quarantined. Use it when you tighten the policy, then raise it.

rua is a mailbox that receives aggregate reports, usually once a day, as XML. Those reports show which IPs sent as you and which checks passed. They are how you find a forgotten form still sending as the root domain. ruf is a forensic report on individual failures. Many providers do not send it. Publish rua.

Turn the dial below to see how policy and pct change what a receiver is asked to do.

A _dmarc record on the organizational domain, such as _dmarc.example.com, also covers mail.example.com unless the subdomain publishes its own. PostShiba treats DMARC as optional. The suggested value is v=DMARC1; p=none;. Add rua when you have a mailbox that can receive the reports.

MX

MX tells the world where to deliver mail for a host. It is an inbound record. It is not part of SPF, DKIM, or DMARC.

Your root domain almost certainly already has MX at Google, Microsoft, or another mailbox host. People write to you@example.com and that host answers. PostShiba never asks you to change those records.

If you point root MX at a sending platform, inbound company mail stops arriving. That is the usual reason to send from a subdomain such as mail.example.com. The root MX stays with the mailbox host. The sending host can have no MX at all. A sending subdomain keeps root MX free.

If you also want to receive on PostShiba, the default inbound host is inbound.mail.example.com.

Return-path

The return-path is the envelope sender. Bounces and spam reports go there, not to the From address. Recipients never see it in a normal mail app.

Every PostShiba sending domain has a return-path host at rp.{name}. For mail.example.com that is rp.mail.example.com. You publish it as a CNAME to the target on the domain page. The CNAME can pass through a zone you control first, up to 8 hops.

When the CNAME verifies, MAIL FROM uses rp.mail.example.com. That is the domain SPF is checked against. PostShiba answers SPF for that host. You cannot set a Return-Path header on a send. PostShiba owns MAIL FROM.

With the default DKIM CNAME, the domain cannot send until the return-path verifies. With an imported DKIM key, it can send once the DKIM TXT verifies. MAIL FROM then uses PostShiba's return-path zone until rp. is up. See the return-path guide.

How PostShiba sets this up

PostShiba sends only from verified domains. Add the domain, publish two records, and send from any address on it once they verify.

Most DNS hosts want the host without the zone. For mail.example.com in the example.com zone, enter rp.mail and {selector}._domainkey.mail, not rp on its own.

PostShiba leaves your root SPF and MX alone. SPF is checked against the return-path domain. The rp. CNAME is how PostShiba answers that check. You do not add a PostShiba include to your SPF.

The domain page can download a BIND file with the two CNAMEs. It adds DMARC unless a record is already there. In Cloudflare, leave proxy off.

Click Check DNS after you publish. PostShiba retries at 30 seconds, 2 minutes, and 5 minutes, then every 5 minutes until the domain verifies. A send from a pending domain also runs a check first.

Once DKIM and the return-path verify, you can send. Tighten DMARC when the reports look clean. Then set the rest of the account up.