SPF, DKIM and DMARC: set up and verify email authentication in DNS

1. Give every sending service a place in the map

MX records tell sending servers where incoming mail for a domain should be delivered. Outgoing mail has its own set of roles. A business might receive through its mailbox provider while sending receipts, support replies and newsletters through specialist services.

Create a sender inventory with one row per service. Record the visible From address, envelope-sender domain, DKIM signing domain, owner and an example message. These roles can legitimately use different names; keeping them together makes the configuration understandable. Identify the precise email domain alongside the website hostname. The inventory becomes especially useful when a team adds a new service or transfers responsibility to another colleague.

2. Understand the contribution of each mechanism

Each mechanism contributes a different piece of the identity story. DKIM addresses signed content, and TLS handles encrypted transport. DMARC relates authenticated domains to the name the recipient sees. Following these roles makes a delivered message’s technical headers much easier to interpret.

3. Keep SPF aligned with real sending paths

SPF evaluates a connecting mail server against the policy for the envelope-sender domain. A policy can include a provider’s published configuration, which may itself refer to other records. The SPF specification permits up to ten DNS-lookup-causing terms during evaluation. Reviewing nested lookups is therefore part of maintaining the complete policy.

Use one SPF policy per name and incorporate new services into that record according to their documentation. A record beginning with v=spf1 should reflect the services your organization actually uses. When a service changes, review its dependencies and update the inventory and DNS together. This creates a clear relationship between published authorization and the people responsible for each sending system. Be careful with -all: RFC 9989 notes that some receivers reject an SPF fail before DMARC is evaluated, so a message that aligned DKIM would have passed can be lost without ever appearing in DMARC reports.

To look up the SPF and DMARC records your domain publishes today with dig or nslookup and read them term by term, follow the SPF and DMARC check.

4. Connect signatures, alignment and useful reports

DKIM uses a domain signature to verify the signed parts of a message. Enable the sending provider’s signing feature and publish its specified selector records. Then send a real message and inspect the recipient’s Authentication-Results information. This shows how the receiving system evaluated the message as delivered.

The current DMARC specification connects authentication with the visible From domain. Aligned, passing SPF or aligned, passing DKIM can satisfy DMARC. A monitoring policy such as p=none provides a useful observation stage while receivers continue applying their own filtering. Aggregate reports summarize sending sources and authentication outcomes. Use them to understand ordinary traffic, confirm legitimate services and choose subsequent policy steps deliberately. RFC 9989 also advises domains whose users post to mailing lists not to publish p=reject; a domain that still wants it should spend at least a month at p=none, then an equal period at p=quarantine, and compare the reports at each stage.

5. Coordinate certificate and transport policies

CAA records specify which certificate authorities may issue for a domain. Start from the providers used by the website, CDN and other services, including their renewal arrangements. Keep the permitted issuers and the certificate register consistent. The CAA specification explains how certificate-authority authorization is expressed in DNS.

MTA-STS supports encrypted connections from participating senders to receiving mail servers. Its setup brings together a DNS TXT marker, an HTTPS-hosted policy, the intended MX names and their TLS configuration. Review these as one coordinated service. The MTA-STS specification describes the policy lifecycle. Documenting both certificate and mail-transport arrangements helps teams maintain a consistent domain identity across services.

6. Use real messages to review the finished setup

Before a planned DNS update, save the existing records, identify the authoritative provider and note the TTL. After publishing, inspect both the authoritative response and an external resolver. Account for the record’s cache lifetime when scheduling the next observation.

1. Send a representative message from each service in the inventory.
2. Check receipt and the message’s Authentication-Results headers.
3. Record the relevant SPF, DKIM and DMARC alignment values.
4. Compare the observations with aggregate reports and update ownership notes.

Include the types of messages your business actually sends, such as invoices, support replies and account notifications. Representative recipient providers add useful variety to the review. Store a dated example for each sending path so the next colleague can see the intended configuration in action. This turns DNS maintenance into a repeatable communication routine.

To look up the SPF, DMARC, MTA-STS and CAA records of one domain now, use the free SPF and DMARC checker.

7. Keep one clear record of your domain’s identity

Bring the sender inventory, DNS records, certificate issuers and sample messages together. Sitelemetry can help organize public DNS and email-policy observations for this work.

The free Launch Readiness Snapshot runs eight passive checks on one public origin without signup. One of them looks up the SPF, DMARC, CAA and MTA-STS records of the exact hostname you enter: www.example.com is checked as entered, not as its parent domain, and missing SPF, DMARC or MTA-STS records are flagged only when that hostname has MX records. It does not check DKIM, and for MTA-STS it looks for the DNS record without fetching the policy file. The result is one score with up to three signals, not a record-by-record report. It is not a pentest, and it does not replace the review with real messages described above.

Continue with the guide to SSL/TLS and HTTP security headers for website connections, or the website integrations audit guide for connected business services.