Configure SPF, DKIM and DMARC with DNS queries and alignment checks

SPF, DKIM and DMARC solve related but different parts of email authentication. A domain can have all three DNS records and still fail DMARC for a particular message if the authenticated identity does not align with the visible From address. Start with the actual sending services, then verify both DNS and a delivered message.

Inventory every service that sends as the domain

Include employee mailboxes, website contact forms, invoicing, support tools, marketing platforms and transactional services. For each one, record the visible From domain, envelope sender or return-path domain, DKIM signing domain and administrator. A service that merely receives mail does not automatically belong in your SPF record.

Send a controlled test from each real path to an external mailbox you manage. Save its raw source and inspect the Authentication-Results supplied by the receiving service. Testing only a hand-written message from webmail misses the website or billing platform that may use a different identity.

Publish one SPF policy for each evaluated domain

example.com. 300 IN TXT "v=spf1 include:_spf.provider.example -all"
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

SPF evaluates the connecting sender against the envelope MAIL FROM domain, or the relevant HELO identity in specific cases. It does not directly authenticate the visible From header. The include value above is a placeholder and will not authorize your provider; obtain its documented value.

Do not add a second v=spf1 TXT record to accommodate a new sender. Merge authorized mechanisms into one reviewed policy and stay within SPF's DNS lookup limits, including nested dependencies. Moving immediately to -all before the inventory is complete can cause legitimate failures; choose the policy deliberately rather than copying this example unmodified.

dig example.com TXT +noall +answer
dig _dmarc.example.com TXT +noall +answer

Enable DKIM at each sending service

DKIM signs selected message headers and a representation of the body using a private key held by the sender. The receiver obtains the public key through a selector under the signing domain. DNS publishing alone does not make the service sign messages; both the signing configuration and the matching public record must be correct.

dig selector1._domainkey.example.com TXT +noall +answer
dig selector1._domainkey.example.com CNAME +noall +answer

Replace selector1 with the selector actually used in the message's DKIM-Signature s= field. Some providers delegate selectors through CNAME records, while others supply TXT keys. Follow the provider's exact instructions and never publish the private key. Multiple selectors can coexist for different services or key rotation.

A TXT value split into multiple quoted strings in DNS output can be one logical record; do not mistake it for multiple keys solely because the display wraps. Confirm the final public record and inspect a newly sent message after activation.

Understand alignment before interpreting a DMARC result

DMARC compares the visible RFC5322 From domain with successful SPF or DKIM identities under its alignment rules. One aligned passing mechanism is sufficient for a DMARC pass. SPF pass for an unrelated provider return-path, plus DKIM pass for that provider's unrelated signing domain, does not by itself authenticate your From domain.

Authentication-Results: mx.receiver.example;
    spf=pass smtp.mailfrom=bounce.example.com;
    dkim=pass header.d=example.com header.s=selector1;
    dmarc=pass header.from=example.com

Here the aligned DKIM identity can support DMARC. Relaxed alignment can permit appropriately related subdomains under the protocol's domain rules; strict alignment requires an exact domain match. Do not infer alignment merely from similar spelling or a brand name embedded in a different domain.

Only trust authentication results from the receiving infrastructure whose handling you understand. Attackers can insert their own Authentication-Results text. Forwarding can break SPF, and message modification can break DKIM, so interpret the actual delivered path rather than relying on the original sender's prediction.

Start reporting, then enforce from evidence

A p=none policy asks for monitoring without requesting quarantine or rejection on DMARC failure. Aggregate reports can identify sending sources and alignment gaps, but they are not a complete ledger of all mail, and not every receiver sends them. Use an access-controlled reporting mailbox or a vetted reporting service.

When reports go to a different domain, additional destination authorization can be required. Check the reporting service's instructions and the DMARC specification. Treat reports as potentially sensitive operational data and avoid enabling more detailed failure reporting without considering data exposure and organizational policy.

Fix each legitimate sender before moving to quarantine or reject. Current DMARC guidance should be based on the current specification; do not rely on an old percentage-sampling recipe as a substitute for a controlled rollout.

Verify cPanel and external DNS changes independently

cPanel Email Deliverability can show suggested records and local issues, but it cannot necessarily repair an externally hosted authoritative zone. Copy only the verified values into the correct provider, then query public DNS and send new test messages. DNS success does not prove the application actually used the intended SMTP service.

Keep the sender inventory with the domain's operational documentation. Review it before adding a marketing tool, moving a website or retiring a service. Remove obsolete authorization carefully and rotate DKIM keys according to the service's supported procedure.

Primary documentation

• SPF protocol specification, RFC 7208
• DKIM protocol specification, RFC 6376
• DMARC protocol specification, RFC 9989
• cPanel Email Deliverability
• Google sender authentication and alignment FAQ