5 · DNS email records

TL;DR

Objective — make transactional email deliverable by authenticating the sending domain: verify the provider, add SPF/DKIM/DMARC (plus MX), defer CAA to Phase 7, and confirm with dig — so password resets, receipts, and notifications don’t land in spam or get rejected.

User part + done-when

👤 User part — the TXT/MX records are added in your DNS provider’s dashboard, and the sending domain is verified in the email provider’s console (Postmark/SES/Mailgun/SendGrid). An agent can run every dig check, but a person publishes the records and verifies the domain.

Done when SPF (single record), the DKIM selector, and DMARC (p=none to start) all resolve via dig, MX is correct if the domain receives mail, CAA is deliberately deferred, and a test email shows spf=pass, dkim=pass, dmarc=pass.  ·  ⏱ ~20–30 min (+ propagation)  ·  🔀 mixed (👤 DNS records + provider, 🤖 verification).

Background

SHOULD — deliverability

A CodeCanyon app sends password resets, receipts, and notifications. Without SPF/DKIM/DMARC those land in spam — or get rejected. This page authenticates your sending domain.

flowchart LR
  App[Laravel mailer] --> ESP[Email provider]
  ESP --> DNS[SPF + DKIM + DMARC DNS]
  DNS --> Inbox[Recipient inbox]
  DNS --> Reject[Reject / spam folder]

Steps

1. Verify the email provider and record credentials

Confirm which service sends mail (Postmark, SES, Mailgun, SendGrid, your host’s SMTP) and that the domain is verified there.

Who does this

👤 User verifies the sending domain in the email provider’s console — a dashboard/login action an agent can’t perform.

Record the SMTP/API credentials into the production .env (MAIL_*) from 3 · Production .env — double-quoted, never committed.

2. Add the three records and understand what each does

Record	Type	Answers	Without it
SPF	TXT	Which servers may send for this domain	Mail flagged as spoofed
DKIM	TXT	Cryptographic signature proving integrity	Tampering undetectable; spam scoring
DMARC	TXT	Policy when SPF/DKIM fail + where to report	No alignment policy; inconsistent delivery

Who does this

👤 User publishes each TXT record at your DNS provider — an agent can’t add DNS records.

1. Publish the SPF record — one TXT at the root, listing every sender. Merge into a single record — multiple SPF records is itself a failure.

   DNS records

   example.com.  TXT  "v=spf1 include:_spf.provider.com ~all"

   • ✅ A single SPF TXT record exists at the root, listing every sender.

2. Publish the DKIM record — your provider gives a selector and key; publish it at the selector host they specify.

   DNS records

   selector._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=<public-key>"

   • ✅ The DKIM key is published at the provider’s selector host.

   CNAME-based DKIM — Hostinger Titan and similar

   Some providers publish DKIM as CNAME records pointing at the provider’s key host, rather than a TXT key. Hostinger Titan, for example, uses three CNAME selectors:

   DNS records

   hostingermail-a._domainkey.example.com.  CNAME  hostingermail-a.dkim.mail.hostinger.com.
   hostingermail-b._domainkey.example.com.  CNAME  hostingermail-b.dkim.mail.hostinger.com.
   hostingermail-c._domainkey.example.com.  CNAME  hostingermail-c.dkim.mail.hostinger.com.

   Verify CNAME-based selectors with dig CNAME, not dig TXT:

   for sel in hostingermail-a hostingermail-b hostingermail-c; do
     dig +short CNAME "${sel}._domainkey.example.com"
   done
   # Expected: each resolves to its hostingermail-*.dkim.mail.hostinger.com target

   Publish exactly the selectors your provider specifies — for Hostinger Titan all three must resolve, or DKIM signing fails.

3. Publish the DMARC record — start at p=none (monitor only), collect reports, then tighten to quarantine/reject.

   DNS records

   _dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"

   • ✅ A DMARC TXT record at _dmarc.<domain> starts at p=none.

3. Add MX records (if the domain receives mail)

If the domain also receives mail, add the provider’s MX records at the documented priorities. If it only sends (transactional-only), MX may point elsewhere or be omitted — match your provider’s guidance.

1. Publish the MX records at the provider’s priorities.

   DNS records

   example.com.  MX  10 mx1.provider.com.
   example.com.  MX  20 mx2.provider.com.

   • ✅ MX records are present if the domain receives mail (or correctly omitted if send-only).

4. Defer CAA to Phase 7

Do not add CAA records here

CAA records restrict which certificate authorities may issue for the domain. Adding them now — before the Cloudflare/CDN and final cert strategy are locked — risks blocking a legitimate issuer mid-setup and breaking SSL renewal. CAA is intentionally deferred to Phase 7 · Security & monitoring → Headers & packages, step 7, once the issuing CA is final.

Why the risk is real — a concrete renewal example

The danger with CAA is that the failure is silent and delayed. A stale CAA record does not break anything today — it breaks renewal weeks later, long after the change that caused it.

Worked example: Cloudflare switched issuing CAs in 2024 for many zones. A domain that had previously added CAA 0 issue "letsencrypt.org" could keep working until its existing cert expired, then fail renewal when Cloudflare tried to issue through Google Trust Services. Without renewal monitoring, you find out only when a user reports the HTTPS error.

dig +short CAA example.com
# Expected in Phase 4: empty (no CAA records yet)

This is why CAA is bundled with renewal-failure monitoring in Phase 7. If you add CAA before then, scope it to both the current and likely successor issuer rather than a single CA.

5. Verify with dig

Read the resolver output directly, then send a real test message and inspect the headers.

1. Confirm all records resolve.

   dig +short TXT example.com            | grep spf1     # SPF present, single record
   dig +short TXT selector._domainkey.example.com         # DKIM key resolves
   dig +short TXT _dmarc.example.com     | grep DMARC1    # DMARC policy present
   dig +short MX  example.com                              # MX (if receiving mail)
   # Expected: one SPF line, the DKIM key, a DMARC1 policy, and MX records (if receiving mail)

   dig quoting pitfall

   Pass the record type and domain as separate arguments: dig +short MX example.com. Do not quote them as one string (dig +short "MX example.com"), which makes dig treat the whole string as the query name and return empty even when the MX record exists.

   • ✅ SPF (single), DKIM, DMARC, and MX (if receiving) all resolve.

2. Send a real test email and inspect the headers (or use a deliverability checker) — confirm spf=pass, dkim=pass, and dmarc=pass.

   • ✅ A test email shows spf=pass, dkim=pass, and dmarc=pass.

Troubleshooting

Symptom	Cause	Fix
spf=softfail/fail	Sender not in SPF include	Add the provider’s include; keep one SPF record
dkim=none	Selector record missing/typo’d	Re-publish exactly as the provider specifies
dmarc ignored	Record at wrong host	Must be _dmarc.<domain>, not the root
Multiple SPF records	Two TXT v=spf1 entries	Merge into one

Checklist

Do not mark this step done until every box below is checked.

• 👤 Provider verified — email provider verified; MAIL_* recorded in production .env.
• 🔀 Records resolve — SPF (single record), DKIM selector, and DMARC (p=none to start) all resolve via dig.
• 👤 MX correct — MX records correct if the domain receives mail.
• 🤖 CAA deferred — CAA deliberately not added — deferred to Phase 7.
• 🔀 Test passes — test email shows spf=pass, dkim=pass, dmarc=pass.

→Next step

Cloudflare CDN