SPF, DKIM, and DMARC Setup for Email

SPF, DKIM, and DMARC setup for email

Disclosure: SendNeo is built by Yorker Media, the team behind this blog.

Email authentication is a set of DNS records and alignment rules. It does not replace permission or good content, but it gives receiving providers evidence that your messages are authorized. SPF says which systems may use an envelope sender. DKIM signs a message. DMARC tells a receiver what to do when the visible From domain does not align with SPF or DKIM and where to send reports.

The practical goal is simple: publish the records, send a test, inspect alignment, and increase the DMARC policy only after you understand legitimate traffic.

Start with a mail subdomain

A sending subdomain such as mail.example.com keeps mail-specific records and reputation separate from the website at example.com. It also makes a future provider change easier to reason about. Your visible address can be news@mail.example.com or hello@mail.example.com.

In SendNeo, open Domains, add the subdomain, and copy the three DKIM CNAME records, custom MAIL FROM records, and recommended DMARC TXT value. Keep the dashboard values as the source of truth; do not type targets from memory.

Publish DKIM

Add all three CNAME records exactly as shown. The host names usually contain selectors, and the targets point to SendNeo’s signing service. DKIM records are DNS-only data. If you use Cloudflare, do not proxy these CNAMEs through the orange cloud.

A common mistake is adding the full domain twice because the DNS provider automatically appends the zone. If the provider’s host field is relative, enter only the selector and subdomain portion. After saving, inspect the resulting public name and compare it with the dashboard.

DKIM is a signature, not a permission list. It proves that a signed message was authorized by the signing domain and was not altered after signing. DMARC uses the result together with the visible From domain.

Configure the custom MAIL FROM

SendNeo’s custom MAIL FROM subdomain is a bounce host such as bounce.example.com. Publish these records:

The MX record points bounces to the Amazon SES endpoint. The TXT value authorizes the sending service for this envelope domain. If your dashboard gives a different exact hostname, use it; the table shows the SendNeo record described in the product brief.

Do not create several unrelated SPF records at the same hostname. SPF must be one valid TXT policy, and adding duplicate records can cause a receiver to treat SPF as a permanent error. If the parent domain already has SPF for another sender, merge the mechanisms according to your DNS provider and keep the resulting policy within DNS limits.

Add DMARC at p=none

Start with a TXT record at _dmarc.example.com:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Use a mailbox or reporting destination you control. p=none asks receivers to report authentication results without asking them to quarantine or reject failures. Leave it in place while you inventory every legitimate sender for the domain, including other applications and providers.

A DMARC report can show a source you did not know about. Treat it as an investigation lead, not proof that every source is malicious. Confirm whether a source belongs to your organization, then fix or remove it.

Move to quarantine, then reject

Once legitimate SendNeo mail and any other authorized streams align consistently, change the policy to p=quarantine. This asks receivers to treat failing messages as suspicious. Watch reports and support channels for false positives.

When you can explain the remaining failures and legitimate mail passes, change to p=reject. Roll out changes deliberately and keep the reporting address. A strict policy protects the domain from impersonation, but a premature policy can hide a real application that was never authenticated.

DMARC policy does not make a purchased list acceptable. It also does not make a message wanted just because it passes DKIM. Keep one-click unsubscribe, accurate sender identity, and consent in place.

Provider-specific tips

Cloudflare users should leave DKIM CNAMEs DNS-only and check that the final host has no duplicated zone. GoDaddy often expects the relative host such as _dmarc or bounce; its interface appends the domain. Namecheap’s Advanced DNS panel lets you add CNAME, MX, and TXT records; enter only the prefix when it appends the zone.

DNS changes can take time to appear at every resolver. SendNeo’s Verify action reads public DNS. If it fails, compare characters, remove duplicate records, check the MX priority, and wait before trying again.

Verify with a real workflow

After verification, send a test message to the deterministic addresses in Test mode, then send a small live message to an address you control. Check the message’s authentication results in the receiving mailbox. Register webhooks to record delivered, bounced, complained, and failed events.

New SendNeo accounts start in review. Live keys can send only to your verified team emails until a quick human review usually completed within one business day opens outside delivery. Use that window to finish DNS and test code. The review protects the shared reputation for everyone.

Authentication is a foundation. A permission-based list, steady volume, and clear unsubscribe complete the setup. Read Deliverability before a larger import or first broadcast.

Common mistakes to avoid

Do not publish a second SPF record because a setup guide gave you a new line to paste. SPF is evaluated as a policy at a hostname, so duplicate records can fail even when each line looks correct by itself. Do not put the visible From domain in the custom MAIL FROM field unless the provider specifically asks for it; the envelope domain is a separate part of the message.

Do not set DMARC to reject on the first day for a domain that has several unknown senders. A forgotten support tool or application can disappear from the inbox after the change. Start with reports, list the legitimate sources, and move the policy in steps. If you do not control the reporting mailbox, fix that before you depend on the reports.

When a DNS provider shows a value with quotation marks, follow that provider’s input rules rather than copying formatting blindly. What matters is the final public TXT value. Re-run verification after propagation, then send a real message and inspect the authentication results at the receiving mailbox.

Keep records with the team

Write down the domain owner, the DNS provider, the selectors, the custom MAIL FROM host, and the date of the last policy change. Store this runbook with the sending application. When someone changes a provider or a subdomain, they can see which records are deliberate and which need review.

Authentication is easier to maintain when it is treated as code-adjacent configuration. Review it during a provider migration, a domain transfer, and a new marketing stream. That small habit prevents an urgent campaign from becoming the first time anyone notices a missing DKIM record.

Keep one owner for DNS and one owner for the application, then share the runbook between them. Authentication failures often happen at the boundary between those teams. A short record of who changed a selector or policy makes the next incident faster to diagnose.

For the receiving-provider side of the same work, read Gmail and Yahoo bulk-sender rules.