Identity first. Reputation always. Get the setup right, send mail people expect, and pay attention to the response.
Chapter 01 / Start here
Email authentication, without the alphabet soup.
SPF, DKIM, and DMARC work together to help receiving servers assess whether email is authorized to use your domain.
SPF checks the sending server against the domain used for the envelope sender. DKIM adds a cryptographic signature tied to a signing domain. DMARC checks whether a passing SPF or DKIM result aligns with the domain in the visible From address. A message needs at least one aligned pass to pass DMARC.
Start with the exact records from your sending provider. Publish them in your DNS host, allow for propagation, and send a test message to a mailbox you control. Inspect its Authentication-Results headers rather than assuming a green DNS check means every message is correctly signed.
An SPF TXT record describes the servers and services permitted to send using a domain’s envelope sender identity.
Inventory every service that sends on your behalf before editing an SPF record: your mailbox provider, product email service, marketing platform, and any support system. Maintain a single SPF policy per hostname. Adding a second independent SPF record can produce a permanent error.
Use the provider’s documented include mechanism and check the total DNS lookup count. SPF has a limit of ten DNS-querying mechanisms and modifiers during evaluation. Do not copy a generic record or remove an existing service without verifying what relies on it.
DKIM lets a receiver verify a signature on selected message headers and the body using a public key in DNS.
Your provider supplies a selector and the records to publish, usually a TXT record or CNAME delegation. Use those exact hostnames and values. The selector in a message’s DKIM-Signature header tells a receiver where to find the public key.
Confirm signing is enabled after DNS verification. Send a test and check the signing domain, selector, and pass result. For DMARC, a valid signature also needs domain alignment. Follow your provider’s key rotation process and keep an old public key available long enough for messages already in transit.
DMARC connects authentication to your visible From domain and publishes a requested policy for messages that fail.
Publish the TXT record at _dmarc.yourdomain with settings appropriate to your organization. A monitoring policy, p=none, allows you to gather aggregate reports before asking receivers to quarantine or reject failures. Use a reporting destination you control and are prepared to monitor.
Inventory legitimate senders using those reports. Fix SPF or DKIM alignment for each service before tightening policy. External report destinations can require additional DNS authorization. Receivers retain their own filtering decisions, even when a domain publishes a policy.
Sending and receiving depend on different records. Treat your DNS configuration as an inventory, not a collection of fixes.
MX records route inbound mail. TXT records can publish SPF policies, DKIM keys, and DMARC policy. CNAME records delegate a hostname to another name and are often used for DKIM or tracking configuration. A custom MAIL FROM domain may require its own MX and TXT records, as documented by the sender.
Copy the hostname and value carefully. Some DNS hosts append your domain automatically, which can accidentally double it. Save the previous records, avoid replacing the main mailbox MX records with sending-service records, and recheck after the TTL and provider verification process allow changes to propagate.
A new sending domain or IP has little history. Consistent, permission-based volume gives receivers more useful evidence than a sudden spike.
Start with engaged recipients who expect your mail. Keep volume consistent, authenticate the domain, and make unsubscribing straightforward. Review complaints, bounces, and deferrals as you increase volume. There is no universal schedule that makes every domain ready for a particular daily volume.
Artificial warmup traffic is not a substitute for recipient interest and can conflict with provider rules. If you use a third-party warmup service, evaluate its methods and your provider’s terms. Pause an increase when delivery signals deteriorate and investigate the cause before adding volume.
A failed delivery needs context. A permanent failure, temporary deferral, and unknown transport outcome should not all trigger the same retry.
Use your provider’s delivery events and documented error categories. Suppress addresses that permanently fail, complain, or unsubscribe. Temporary failures may be retried according to the provider’s backoff policy; repeating a send immediately can make throttling worse.
Preserve suppression data when changing platforms. Keep source and consent records with your contacts, and remove addresses you cannot justify contacting. Validation tools can flag likely problems, but no pre-send check guarantees that a mailbox will accept your message.
An API success confirms a submission was accepted. A delivery event and an inbox placement result answer different questions.
Follow the message through its lifecycle: accepted by your email service, delivered to the receiving server, then placed by that mailbox’s filters. Delivery events normally cannot tell you which folder the message reached. Seed tests provide a useful sample, not a guarantee for every recipient.
Watch trends across domain reputation, authentication, complaints, bounces, deferrals, and engagement. Google Postmaster Tools and other provider dashboards can help where you have enough eligible traffic. Open tracking has privacy-related limitations, so combine signals rather than optimizing around one number.