Set up SPF, DKIM and DMARC without breaking legitimate email

Email authentication helps receivers evaluate messages using your domain. A useful setup includes DNS records, working signatures from your sending service, and checks on real messages. Publishing three records alone does not prove that every legitimate sender works or prevent every form of phishing.

Use your email provider's exact values when following the examples below.

Understand what each record establishes

DMARC does not fail just because one authentication mechanism fails: one aligned passing mechanism can satisfy it. A p=none policy requests monitoring, not quarantine or rejection. Receiver policy still determines final handling. DMARC specification.

Inventory senders before changing DNS

List the mailbox provider, application mail, support system, invoicing system and any forwarding services. Save the current SPF, DKIM, DMARC and MX records. Include subdomains and old services that still send during a migration.

For automatic Postscale setup on an eligible DNScale zone, follow the automatic DNS setup walkthrough to review SPF merging, preserved DMARC and unchanged MX for application sending.

Publish SPF without creating a second policy

In the DNScale dashboard, open the zone and inspect TXT records at the exact sending hostname. Edit the existing SPF policy if one exists; do not add a second v=spf1 record beside it.

For a hostname that sends only through Google Workspace, Google's documented example is:

example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"

This example does not authorize other providers. Inventory them before merging their mechanisms, and check SPF's DNS-lookup limit. Follow Google's SPF setup instructions for a Google-specific configuration.

Publish the key and enable DKIM signing

Obtain the selector and full record from the email service. Providers may ask for a TXT key or one or more CNAMEs. In DNScale, create that exact type, hostname and value. Never publish a private key.

selector._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=PROVIDER_PUBLIC_KEY"

The placeholder above is not a valid key. After the record resolves, finish the provider's signing activation if required. A published key cannot sign messages by itself. Retain old selectors until the corresponding mail streams and queued messages no longer need them. See Google's DKIM instructions for one provider's activation sequence.

Start DMARC with visibility

If a DMARC policy already exists, preserve it while you review the new sender. Do not automatically downgrade an enforced policy. For a new deployment, a monitoring example is:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Create a working reporting destination before using it. External reporting destinations can need additional authorization. Collect reports across your legitimate mail streams and repair alignment problems before choosing p=quarantine or p=reject. There is no fixed number of days that proves a rarely used sender has been tested.

Verify DNS and actual messages separately

First query the zone's authoritative nameservers and a recursive resolver. An authoritative update does not remove older cached answers elsewhere. Observe the previous TTL and any negative caching; see DNS propagation.

Then send from each legitimate service to a controlled inbox and inspect the receiver's authentication results. Check the domain next to each SPF and DKIM result, the visible From domain, and DMARC. Passing authentication on one test does not establish inbox placement for all recipients.

For API-based changes, use the current records API reference and review existing records before creating or updating them. The DNS change review checklist covers validation and recovery. DNS automation reduces data entry; careful review and delivery checks establish whether the setup works.

Read the email authentication reference for more detail, or review the Postscale setup options when adding application sending or personal forwarding.