Email authentication

Configure SPF, DKIM, and DMARC so receiving providers can verify that Smailor is
authorized to send for your domain. This guide explains what each record proves,
how they work together, and how to roll out changes safely.

Authentication improves trust and protects against spoofing, but it does not
guarantee inbox placement. Recipient consent, list quality, content, sending
patterns, and reputation still matter.

The four DNS controls

SPF and DKIM are authentication mechanisms. DMARC connects their results to the
domain the recipient actually sees in the From header.

How a receiver evaluates a message

Message arrives
      |
      +--> SPF checks the sending path --------+
      |                                         |
      +--> DKIM verifies the signature ---------+--> DMARC checks alignment
                                                        |
                                                        +--> pass and report
                                                        `--> apply domain policy

DMARC can pass when either aligned SPF or aligned DKIM passes. In practice,
configure both: forwarding can break SPF, while DKIM can survive forwarding when
the signed content remains unchanged.

Before changing DNS

1. Inventory every legitimate sender: Smailor, your mailbox provider, billing,
   newsletters, CRM, support tools, and any application or device that sends
   directly.
2. Record the current public SPF, DKIM, DMARC, and MX values.
3. Lower TTL in advance only when you understand the impact; changing TTL at the
   same time as the record does not remove existing caches.
4. Copy the Smailor-generated values from Settings → Domains → Deliverability.

The dashboard is the source of truth for Smailor hostnames and values. The
examples below explain syntax only.

Configure SPF

SPF is a TXT record beginning with v=spf1. A domain must have no more than one
SPF policy at a given hostname.

Illustrative example:

example.com.  TXT  "v=spf1 include:EXAMPLE-SMAILOR-VALUE include:OTHER-PROVIDER ~all"

SPF rules that prevent failures

• Merge all legitimate senders into one record; two SPF records produce a
  permanent error rather than combining permissions.
• Keep the complete policy within SPF's DNS-lookup limit. Too many nested
  include mechanisms can make a syntactically valid record fail evaluation.
• Use the exact include or IP mechanism shown by each provider.
• Use ~all during a controlled transition. Move to -all only after the
  sending inventory is complete and tests pass.
• Do not add Smailor to SPF when the Smailor dashboard does not instruct you to.

SPF checks the envelope sender, which may be different from the visible From
address. DMARC is what requires alignment with the visible domain.

Configure DKIM

DKIM signs selected message headers and body content. The receiving provider
retrieves the public key from a selector under _domainkey.

Illustrative shape:

smailor._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=PUBLIC_KEY_MATERIAL"

• Publish only the public key shown by Smailor.
• Never paste a private key into DNS, a support ticket, or a screenshot.
• Preserve the full p= value. DNS tools may display a long TXT record as
  multiple quoted chunks; receivers concatenate those chunks automatically.
• Keep an old selector during a planned key rotation until previously sent mail
  no longer needs it and Smailor marks it safe to remove.

Follow Publish your DKIM record for the exact workflow.

Configure DMARC

DMARC is a TXT record at _dmarc.<domain>.

Start with monitoring:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

Use a reporting mailbox that can process aggregate reports. These reports can
contain sending infrastructure information and should be retained securely.

Roll out enforcement gradually

1. Publish p=none and collect reports across normal sending cycles.
2. Identify every legitimate source and correct SPF or DKIM alignment.
3. Move to p=quarantine when unexpected sources are understood.
4. Move to p=reject only when legitimate mail consistently aligns.
5. Apply an intentional subdomain policy with sp= when subdomains send mail.

A strict policy deployed before the sender inventory is complete can reject
legitimate mail. A permanent p=none policy reports abuse but does not instruct
receivers to quarantine or reject it.

Configure MX only for the receiving model

MX does not affect Smailor's authorization to send. It changes where incoming
mail is delivered.

• If Smailor is the primary receiver, publish the MX targets shown in the domain
  setup screen.
• If another provider remains primary, keep its MX records and configure the
  supported forwarding or coexistence flow.
• Avoid mixing unrelated MX providers as a fallback strategy. Senders use MX
  priority for availability, not for address-based routing.

See Add a custom domain before changing existing MX.

Verify the result

1. Select Verify DNS in the domain's Deliverability section.
2. Wait for DNS propagation when a public lookup still returns the old value.
3. Send a message to an external mailbox you control.
4. Inspect the original message or authentication details.
5. Confirm SPF, DKIM, and DMARC report pass for the expected domains.

Test from every real sending path. A Smailor test does not prove that a separate
newsletter or billing platform is aligned.

Troubleshooting matrix

Production checklist

• Every legitimate sender is inventoried.
• There is exactly one SPF record per sending hostname.
• Smailor DKIM is verified.
• DMARC reports go to a monitored mailbox.
• Enforcement follows observed report data.
• Incoming MX matches the intended provider model.
• Authentication passes on real messages from every sending path.
• Bounce and complaint rates are monitored after the change.

Related guides

• Add a custom domain
• Publish your DKIM record
• Read delivery statistics
• Display a BIMI logo